EIP-1967 Standard Proxy Storage Slots¶
This EIP standardizes how proxies store the logic contract address. Having this makes it easier for outside services, such as block explorers, to show the correct information to the end-user. Etherscan added support for this end of 2019. The EIP-1967 also adds a few more gimmicks to the overall pattern!
What's the main function? The storage slot, obviously. While in EIP-1822 it was somewhat keccak256("PROXYABLE") - or anything of your choice really - in EIP-1967 it is well defined:
Storage slot 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc(obtained as bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1)) is reserved for the logic contract.
But EIP-1967 also adds beacon contracts and storage for the actual admin functionality.
The Beacon Contract¶
The idea behind the beacon contract is re-usability. If you have several proxies pointing to the same logic contract address then, every time you want to update the logic contract, you'd have to update all proxies. As this can become gas intensive, it would make more sense to have a beacon contract that returns the address of the logic contract for all proxies.
So, if you use beacons, you are having another layer of Smart Contract in between that returns the address of the actual logic contract.
A really good sample implementation is used by OpenZeppelin in their Repository.
As this is basically the same functionality as EIP-1822, just with a clear defined namespace, I'll refer at this point to the examples we did in the previous explanation.
Instead of repeating the same experiment as before, I want to talk about another pattern: The diamond storage pattern.