Delegating proxy contracts are widely used for both upgradeability and gas savings. These proxies rely on a logic contract (also known as implementation contract or master copy) that is called using delegatecall. This allows proxies to keep a persistent state (storage and balance) while the code is delegated to the logic contract.
To avoid clashes in storage usage between the proxy and logic contract, the address of the logic contract is typically saved in a specific storage slot (for example 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc in OpenZeppelin contracts) guaranteed to be never allocated by a compiler. This EIP proposes a set of standard slots to store proxy information. This allows clients like block explorers to properly extract and show this information to end users, and logic contracts to optionally act upon it.
Motivation
Delegating proxies are widely in use, as a means to both support upgrades and reduce gas costs of deployments. Examples of these proxies are found in OpenZeppelin Contracts, Gnosis, AragonOS, Melonport, Limechain, WindingTree, Decentraland, and many others.
However, the lack of a common interface for obtaining the logic address for a proxy makes it impossible to build common tools that act upon this information.
A classic example of this is a block explorer. Here, the end user wants to interact with the underlying logic contract and not the proxy itself. Having a common way to retrieve the logic contract address from a proxy allows a block explorer to show the ABI of the logic contract and not that of the proxy. The explorer checks the storage of the contract at the distinguished slots to determine if it is indeed a proxy, in which case it shows information on both the proxy and the logic contract. As an example, this is how 0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48 is shown on Etherscan:
Another example is logic contracts that explicitly act upon the fact that they are being proxied. This allows them to potentially trigger a code update as part of their logic. A common storage slot allows these use cases independently of the specific proxy implementation being used.
Specification
Monitoring of proxies is essential to the security of many applications. It is thus essential to have the ability to track changes to the implementation and admin slots. Unfortunately, tracking changes to storage slots is not easy. Consequently, it is recommended that any function that changes any of these slots SHOULD also emit the corresponding event. This includes initialization, from 0x0 to the first non-zero value.
The proposed storage slots for proxy-specific information are the following. More slots for additional information can be added in subsequent ERCs as needed.
Logic contract address
Storage slot 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc
(obtained as bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1)).
Holds the address of the logic contract that this proxy delegates to. SHOULD be empty if a beacon is used instead. Changes to this slot SHOULD be notified by the event:
eventUpgraded(addressindexedimplementation);
Beacon contract address
Storage slot 0xa3f0ad74e5423aebfd80d3ef4346578335a9a72aeaee59ff6cb3582b35133d50 (obtained as bytes32(uint256(keccak256('eip1967.proxy.beacon')) - 1)).
Holds the address of the beacon contract this proxy relies on (fallback). SHOULD be empty if a logic address is used directly instead, and should only be considered if the logic contract slot is empty. Changes to this slot SHOULD be notified by the event:
eventBeaconUpgraded(addressindexedbeacon);
Beacons are used for keeping the logic address for multiple proxies in a single location, allowing the upgrade of multiple proxies by modifying a single storage slot. A beacon contract MUST implement the function:
function implementation() returns (address)
Beacon based proxy contracts do not use the logic contract slot. Instead, they use the beacon contract slot to store the address of the beacon they are attached to. In order to know the logic contract used by a beacon proxy, a client SHOULD:
Read the address of the beacon for the beacon logic storage slot;
Call the implementation() function on the beacon contract.
The result of the implementation() function on the beacon contract SHOULD NOT depend on the caller (msg.sender).
Admin address
Storage slot 0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103
(obtained as bytes32(uint256(keccak256('eip1967.proxy.admin')) - 1)).
Holds the address that is allowed to upgrade the logic contract address for this proxy (optional). Changes to this slot SHOULD be notified by the event:
This EIP standardises the storage slot for the logic contract address, instead of a public method on the proxy contract. The rationale for this is that proxies should never expose functions to end users that could potentially clash with those of the logic contract.
Note that a clash may occur even among functions with different names, since the ABI relies on just four bytes for the function selector. This can lead to unexpected errors, or even exploits, where a call to a proxied contract returns a different value than expected, since the proxy intercepts the call and answers with a value of its own.
From Malicious backdoors in Ethereum proxies by Nomic Labs:
Any function in the Proxy contract whose selector matches with one in the implementation contract will be called directly, completely skipping the implementation code.
Because the function selectors use a fixed amount of bytes, there will always be the possibility of a clash. This isn’t an issue for day to day development, given that the Solidity compiler will detect a selector clash within a contract, but this becomes exploitable when selectors are used for cross-contract interaction. Clashes can be abused to create a seemingly well-behaved contract that’s actually concealing a backdoor.
The fact that proxy public functions are potentially exploitable makes it necessary to standardise the logic contract address in a different way.
The main requirement for the storage slots chosen is that they must never be picked by the compiler to store any contract state variable. Otherwise, a logic contract could inadvertently overwrite this information on the proxy when writing to a variable of its own.
Solidity maps variables to storage based on the order in which they were declared, after the contract inheritance chain is linearized: the first variable is assigned the first slot, and so on. The exception is values in dynamic arrays and mappings, which are stored in the hash of the concatenation of the key and the storage slot. The Solidity development team has confirmed that the storage layout is to be preserved among new versions:
The layout of state variables in storage is considered to be part of the external interface of Solidity due to the fact that storage pointers can be passed to libraries. This means that any change to the rules outlined in this section is considered a breaking change of the language and due to its critical nature should be considered very carefully before being executed. In the event of such a breaking change, we would want to release a compatibility mode in which the compiler would generate bytecode supporting the old layout.
Vyper seems to follow the same strategy as Solidity. Note that contracts written in other languages, or directly in assembly, may incur in clashes.
They are chosen in such a way so they are guaranteed to not clash with state variables allocated by the compiler, since they depend on the hash of a string that does not start with a storage index. Furthermore, a -1 offset is added so the preimage of the hash cannot be known, further reducing the chances of a possible attack.
Reference Implementation
/**
* @dev This contract implements an upgradeable proxy. It is upgradeable because calls are delegated to an
* implementation address that can be changed. This address is stored in storage in the location specified by
* https://eips.ethereum.org/EIPS/eip-1967[EIP1967], so that it doesn't conflict with the storage layout of the
* implementation behind the proxy.
*/contractERC1967ProxyisProxy,ERC1967Upgrade{/**
* @dev Initializes the upgradeable proxy with an initial implementation specified by `_logic`.
*
* If `_data` is nonempty, it's used as data in a delegate call to `_logic`. This will typically be an encoded
* function call, and allows initializing the storage of the proxy like a Solidity constructor.
*/constructor(address_logic,bytesmemory_data)payable{assert(_IMPLEMENTATION_SLOT==bytes32(uint256(keccak256("eip1967.proxy.implementation"))-1));_upgradeToAndCall(_logic,_data,false);}/**
* @dev Returns the current implementation address.
*/function_implementation()internalviewvirtualoverridereturns(addressimpl){returnERC1967Upgrade._getImplementation();}}/**
* @dev This abstract contract provides getters and event emitting update functions for
* https://eips.ethereum.org/EIPS/eip-1967[EIP1967] slots.
*/abstractcontractERC1967Upgrade{// This is the keccak-256 hash of "eip1967.proxy.rollback" subtracted by 1
bytes32privateconstant_ROLLBACK_SLOT=0x4910fdfa16fed3260ed0e7147f7cc6da11a60208b5b9406d12a635614ffd9143;/**
* @dev Storage slot with the address of the current implementation.
* This is the keccak-256 hash of "eip1967.proxy.implementation" subtracted by 1, and is
* validated in the constructor.
*/bytes32internalconstant_IMPLEMENTATION_SLOT=0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc;/**
* @dev Emitted when the implementation is upgraded.
*/eventUpgraded(addressindexedimplementation);/**
* @dev Returns the current implementation address.
*/function_getImplementation()internalviewreturns(address){returnStorageSlot.getAddressSlot(_IMPLEMENTATION_SLOT).value;}/**
* @dev Stores a new address in the EIP1967 implementation slot.
*/function_setImplementation(addressnewImplementation)private{require(Address.isContract(newImplementation),"ERC1967: new implementation is not a contract");StorageSlot.getAddressSlot(_IMPLEMENTATION_SLOT).value=newImplementation;}/**
* @dev Perform implementation upgrade
*
* Emits an {Upgraded} event.
*/function_upgradeTo(addressnewImplementation)internal{_setImplementation(newImplementation);emitUpgraded(newImplementation);}/**
* @dev Perform implementation upgrade with additional setup call.
*
* Emits an {Upgraded} event.
*/function_upgradeToAndCall(addressnewImplementation,bytesmemorydata,boolforceCall)internal{_upgradeTo(newImplementation);if(data.length>0||forceCall){Address.functionDelegateCall(newImplementation,data);}}/**
* @dev Perform implementation upgrade with security checks for UUPS proxies, and additional setup call.
*
* Emits an {Upgraded} event.
*/function_upgradeToAndCallSecure(addressnewImplementation,bytesmemorydata,boolforceCall)internal{addressoldImplementation=_getImplementation();// Initial upgrade and setup call
_setImplementation(newImplementation);if(data.length>0||forceCall){Address.functionDelegateCall(newImplementation,data);}// Perform rollback test if not already in progress
StorageSlot.BooleanSlotstoragerollbackTesting=StorageSlot.getBooleanSlot(_ROLLBACK_SLOT);if(!rollbackTesting.value){// Trigger rollback using upgradeTo from the new implementation
rollbackTesting.value=true;Address.functionDelegateCall(newImplementation,abi.encodeWithSignature("upgradeTo(address)",oldImplementation));rollbackTesting.value=false;// Check rollback was effective
require(oldImplementation==_getImplementation(),"ERC1967Upgrade: upgrade breaks further upgrades");// Finally reset to the new implementation and log the upgrade
_upgradeTo(newImplementation);}}/**
* @dev Storage slot with the admin of the contract.
* This is the keccak-256 hash of "eip1967.proxy.admin" subtracted by 1, and is
* validated in the constructor.
*/bytes32internalconstant_ADMIN_SLOT=0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103;/**
* @dev Emitted when the admin account has changed.
*/eventAdminChanged(addresspreviousAdmin,addressnewAdmin);/**
* @dev Returns the current admin.
*/function_getAdmin()internalviewreturns(address){returnStorageSlot.getAddressSlot(_ADMIN_SLOT).value;}/**
* @dev Stores a new address in the EIP1967 admin slot.
*/function_setAdmin(addressnewAdmin)private{require(newAdmin!=address(0),"ERC1967: new admin is the zero address");StorageSlot.getAddressSlot(_ADMIN_SLOT).value=newAdmin;}/**
* @dev Changes the admin of the proxy.
*
* Emits an {AdminChanged} event.
*/function_changeAdmin(addressnewAdmin)internal{emitAdminChanged(_getAdmin(),newAdmin);_setAdmin(newAdmin);}/**
* @dev The storage slot of the UpgradeableBeacon contract which defines the implementation for this proxy.
* This is bytes32(uint256(keccak256('eip1967.proxy.beacon')) - 1)) and is validated in the constructor.
*/bytes32internalconstant_BEACON_SLOT=0xa3f0ad74e5423aebfd80d3ef4346578335a9a72aeaee59ff6cb3582b35133d50;/**
* @dev Emitted when the beacon is upgraded.
*/eventBeaconUpgraded(addressindexedbeacon);/**
* @dev Returns the current beacon.
*/function_getBeacon()internalviewreturns(address){returnStorageSlot.getAddressSlot(_BEACON_SLOT).value;}/**
* @dev Stores a new beacon in the EIP1967 beacon slot.
*/function_setBeacon(addressnewBeacon)private{require(Address.isContract(newBeacon),"ERC1967: new beacon is not a contract");require(Address.isContract(IBeacon(newBeacon).implementation()),"ERC1967: beacon implementation is not a contract");StorageSlot.getAddressSlot(_BEACON_SLOT).value=newBeacon;}/**
* @dev Perform beacon upgrade with additional setup call. Note: This upgrades the address of the beacon, it does
* not upgrade the implementation contained in the beacon (see {UpgradeableBeacon-_setImplementation} for that).
*
* Emits a {BeaconUpgraded} event.
*/function_upgradeBeaconToAndCall(addressnewBeacon,bytesmemorydata,boolforceCall)internal{_setBeacon(newBeacon);emitBeaconUpgraded(newBeacon);if(data.length>0||forceCall){Address.functionDelegateCall(IBeacon(newBeacon).implementation(),data);}}}/**
* @dev This abstract contract provides a fallback function that delegates all calls to another contract using the EVM
* instruction `delegatecall`. We refer to the second contract as the _implementation_ behind the proxy, and it has to
* be specified by overriding the virtual {_implementation} function.
*
* Additionally, delegation to the implementation can be triggered manually through the {_fallback} function, or to a
* different contract through the {_delegate} function.
*
* The success and return data of the delegated call will be returned back to the caller of the proxy.
*/abstractcontractProxy{/**
* @dev Delegates the current call to `implementation`.
*
* This function does not return to its internal call site, it will return directly to the external caller.
*/function_delegate(addressimplementation)internalvirtual{assembly{// Copy msg.data. We take full control of memory in this inline assembly
// block because it will not return to Solidity code. We overwrite the
// Solidity scratch pad at memory position 0.
calldatacopy(0,0,calldatasize())// Call the implementation.
// out and outsize are 0 because we don't know the size yet.
letresult:=delegatecall(gas(),implementation,0,calldatasize(),0,0)// Copy the returned data.
returndatacopy(0,0,returndatasize())switchresult// delegatecall returns 0 on error.
case0{revert(0,returndatasize())}default{return(0,returndatasize())}}}/**
* @dev This is a virtual function that should be overridden so it returns the address to which the fallback function
* and {_fallback} should delegate.
*/function_implementation()internalviewvirtualreturns(address);/**
* @dev Delegates the current call to the address returned by `_implementation()`.
*
* This function does not return to its internal call site, it will return directly to the external caller.
*/function_fallback()internalvirtual{_beforeFallback();_delegate(_implementation());}/**
* @dev Fallback function that delegates calls to the address returned by `_implementation()`. Will run if no other
* function in the contract matches the call data.
*/fallback()externalpayablevirtual{_fallback();}/**
* @dev Fallback function that delegates calls to the address returned by `_implementation()`. Will run if call data
* is empty.
*/receive()externalpayablevirtual{_fallback();}/**
* @dev Hook that is called before falling back to the implementation. Can happen as part of a manual `_fallback`
* call, or as part of the Solidity `fallback` or `receive` functions.
*
* If overridden should call `super._beforeFallback()`.
*/function_beforeFallback()internalvirtual{}}/**
* @dev Library for reading and writing primitive types to specific storage slots.
*
* Storage slots are often used to avoid storage conflict when dealing with upgradeable contracts.
* This library helps with reading and writing to such slots without the need for inline assembly.
*
* The functions in this library return Slot structs that contain a `value` member that can be used to read or write.
*/libraryStorageSlot{structAddressSlot{addressvalue;}structBooleanSlot{boolvalue;}structBytes32Slot{bytes32value;}structUint256Slot{uint256value;}/**
* @dev Returns an `AddressSlot` with member `value` located at `slot`.
*/functiongetAddressSlot(bytes32slot)internalpurereturns(AddressSlotstorager){assembly{r.slot:=slot}}/**
* @dev Returns an `BooleanSlot` with member `value` located at `slot`.
*/functiongetBooleanSlot(bytes32slot)internalpurereturns(BooleanSlotstorager){assembly{r.slot:=slot}}/**
* @dev Returns an `Bytes32Slot` with member `value` located at `slot`.
*/functiongetBytes32Slot(bytes32slot)internalpurereturns(Bytes32Slotstorager){assembly{r.slot:=slot}}/**
* @dev Returns an `Uint256Slot` with member `value` located at `slot`.
*/functiongetUint256Slot(bytes32slot)internalpurereturns(Uint256Slotstorager){assembly{r.slot:=slot}}}
Security Considerations
This ERC relies on the fact that the chosen storage slots are not to be allocated by the solidity compiler. This guarantees that an implementation contract will not accidentally overwrite any of the information required for the proxy to operate. As such, locations with a high slot number were chosen to avoid clashes with the slots allocated by the compiler. Also, locations with no known preimage were picked, to ensure that a write to mapping with a maliciously crafted key could not overwrite it.
Logic contracts that intend to modify proxy-specific information must do so deliberately (as is the case with UUPS) by writing to the specific storage slot.