Removing trust from upgradeability proxy is necessary for anonymous developers. In order to accomplish this, instant and potentially malicious upgrades must be prevented. This EIP introduces additional storage slots for upgradeability proxy which are assumed to decrease trust in interaction with upgradeable smart contracts. Defined by the admin implementation logic can be made an active implementation logic only after Zero Trust Period allows.
Anonymous developers who utilize upgradeability proxies typically struggle to earn the trust of the community.
Fairer, better future for humanity absolutely requires some developers to stay anonymous while still attract vital attention to solutions they propose and at the same time leverage the benefits of possible upgradeability.
The specification is an addition to the standard EIP-1967 transparent proxy design.
The specification focuses on the slots it adds. All admin interactions with trust minimized proxy must emit an event to make admin actions trackable, and all admin actions must be guarded with onlyAdmin() modifier.
Storage slot 0x19e3fabe07b65998b604369d85524946766191ac9434b39e27c424c976493685 (obtained as bytes32(uint256(keccak256('eip3561.proxy.next.logic')) - 1)).
Desirable implementation logic address must be first defined as next logic, before it can function as actual logic implementation stored in EIP-1967 IMPLEMENTATION_SLOT.
Admin interactions with next logic contract address correspond with these methods and events:
Storage slot 0xe3228ec3416340815a9ca41bfee1103c47feb764b4f0f4412f5d92df539fe0ee (obtained as bytes32(uint256(keccak256('eip3561.proxy.next.logic.block')) - 1)).
On/after this block next logic contract address can be set to EIP-1967 IMPLEMENTATION_SLOT or, in other words, upgrade() can be called. Updated automatically according to Zero Trust Period, shown as earliestArrivalBlock in the event NextLogicDefined.
Storage slot 0x4b50776e56454fad8a52805daac1d9fd77ef59e4f1a053c342aaae5568af1388 (obtained as bytes32(uint256(keccak256('eip3561.proxy.propose.block')) - 1)).
Defines after/on which block proposing next logic is possible. Required for convenience, for example can be manually set to a year from given time. Can be set to maximum number to completely seal the code.
Admin interactions with this slot correspond with this method and event:
Storage slot 0x7913203adedf5aca5386654362047f05edbd30729ae4b0351441c46289146720 (obtained as bytes32(uint256(keccak256('eip3561.proxy.zero.trust.period')) - 1)).
Zero Trust Period in amount of blocks, can only be set higher than previous value. While it is at default value(0), the proxy operates exactly as standard EIP-1967 transparent proxy. After zero trust period is set, all above specification is enforced.
Admin interactions with this slot should correspond with this method and event:
An argument "just don't make such contracts upgadeable at all" fails when it comes to complex systems which do or do not heavily rely on human factor, which might manifest itself in unprecedented ways. It might be impossible to model some systems right on first try. Using decentralized governance for upgrade management coupled with EIP-1967 proxy might become a serious bottleneck for certain protocols before they mature and data is at hand.
A proxy without a time delay before an actual upgrade is obviously abusable. A time delay is probably unavoidable, even if it means that inexperienced developers might not have confidence using it. Albeit this is a downside of this EIP, it's a critically important option to have in smart contract development today.
Users must ensure that a trust-minimized proxy they interact with does not allow overflows, ideally represents the exact copy of the code in implementation example above, and also they must ensure that Zero Trust Period length is reasonable(at the very least two weeks if upgrades are usually being revealed beforehand, and in most cases at least a month).
Copyright and related rights waived via CC0.