BeaconProxy Storage Implementation

From reading https://blog.openzeppelin.com/the-state-of-smart-contract-upgrades/#metamorphic-contracts its clear that proxy contracts run into many limitations around storage layouts.

These issues revolve around Ethereum smart contracts storage models.

Question: how do BeaconProxy implementation allow for additional storage modifications? e.g. you can append variables without any issues - is it using an eternal storage under the hood? If not what is it doing?

" Beacon Proxies have no “proxy-specific” storage or logic (apart from the primary fallback itself)*, and so are immune to function clashing or storage corruption of any kind."

From: https://medium.com/dharma-blog/why-smart-wallets-should-catch-your-interest-c85e4401b89a

How does this work?

"In this pattern, each proxy holds the address not to its implementation contract, but to a beacon which, in turn, holds the address of the implementation. Whenever the proxy receives a call, it asks the beacon for the current implementation to use" (from https://blog.openzeppelin.com/the-state-of-smart-contract-upgrades/#metamorphic-contracts)

  • How is the storage on these proxies / beacon taken care of? E.g. if I have 3 beacon proxies - I upgrade the implementation contract to append more variables to contract storage then how is this reflected upon my 3 beacon proxies?

This is not accurate. I think the author referred to the proxy-specific storage, such as the implementation address.

Beacon proxies are just as vulnerable as transparent or UUPS proxies to storage layout corruption, so the same measures need to be taken.