Proxy
| This document is better viewed at https://docs.openzeppelin.com/community-contracts/proxy |
Variants of proxy patterns, which are contracts that allow to forward a call to an implementation contract by using delegatecall. This contracts include:
-
HybridProxy: An ERC-1967 proxy that uses the implementation slot as a beacon in a way that a user can upgrade to an implementation of their choice.
General
HybridProxy
import "@openzeppelin/contracts/proxy/HybridProxy.sol";A version of an ERC-1967 proxy that uses the address stored in the implementation slot as a beacon.
The design allows to set an initial beacon that the contract may quit by upgrading to its own implementation afterwards.
| The fallback mechanism relies on the implementation not to define the {IBeacon-implementation} function. Consider that if your implementation has this function, it’ll be assumed as the beacon address, meaning that the returned address will be used as this proxy’s implementation. |
-
constructor(implementation, data) -
_implementation()
-
_delegate(implementation) -
_fallback() -
fallback()
constructor(address implementation, bytes data) public
Initializes the proxy with an initial implementation. If data is present, it will be used to initialize the implementation using a delegate call.
_implementation() → address internal
Returns the current implementation address according to ERC-1967’s implementation slot.
| The way this function identifies whether the implementation is a beacon, is by checking if it implements the {IBeacon-implementation} function. Consider that an actual implementation could define this function, mistakenly identifying it as a beacon. |