Introduce a new instruction that allows smart contracts to create (and update) delegation accounts that match EIP-7702's design. These accounts can be used similarly to ERC-1167 clones, with significant advantages.
Many on-chain applications involve creating multiple instances of the same code at different locations. These applications often rely on clones, or proxies, to reduce deployment costs.
Clones, such as the one described in ERC-1167 are minimal pieces of code that contain the target address directly in the code. That makes them extremely light but prevents any form of reconfiguration (upgradability).
Upgradeable proxies differ from clones in that they read the implementation's address from storage. This makes them more versatile but also more expensive to use.
In both cases delegating the received calls to an implementation using EVM code comes with some downsides:
EIP-7702 introduces a new type of object that has the expected behavior: delegation indicator. These objects are designed to be instantiated at the address of EOA's, but the same behavior could be re-used to implement clones at the protocol level. Using delegation indicators for this use-case provides upgradeability without the need for storage lookups if the contract calling the SETDELEGATE allows it. It also removes any issue related to code version incompatibilities.
Smart accounts, as in contracts that are "owned" by one or multiple keys and are intended to replace EOAs, are often deployed using clones or proxies that point to a singleton implementation. This forces a choice between having an upgradeable or a non-upgradeable design. Both designs come with downsides. Non-upgradeable design can leave you stranded with a buggy (or limited) account code. Upgradeable design comes with costs associated with fetching the implementation address.
The SETDELEGATE instruction would enable new factories to implement an upgradeable design without the added cost of the lookup. Factories could also deploy non-upgradeable variants, or even selectively disable the upgradeability of some accounts. Both the upgrade mechanism and the selective locking would be handled at the factory level, which removes the burden of implementing the upgrade logic into the account itself.
Additionally, using EIP-7702 delegations instead of clones/proxies moves the call redirection logic from the userspace to the protocol. This means fewer EVM operations, and thus a reduced gas consumption of every operation that calls these contracts. This includes the verification of signatures and the execution of user operations, but also transfers of assets that include a callback, such as ERC-721 and ERC-1155 tokens.
Clones and proxy contracts are present in large numbers in the blockchain state. OpenZeppelin's ERC-1967 proxies are ~708 bytes. Using EIP-7702 delegations that are only 23 bytes would reduce blockchain state usage.
Additionally, clones and proxy contracts have to handle the redirection of the call in the userspace, which includes execution cost. Using EIP-7702 delegations, which would move the redirection to the protocol level, would reduce the gas cost of all operations that target. This means more gas / blockspace is available for the actual execution of the contracts.
A new instruction (SETDELEGATE) is added at 0xf6.
Executing this instruction does the following:
EMPTY_ACCOUNT_COST gasstatic-modesalt, target from the operand stacklocation as keccak256(DESIGNATOR ++ address ++ salt)[12:]location to accessed_addresses, as defined in EIP-2929location is not empty and does not start with 0xEF0100 (no empty and not a delegation indicator)EMPTY_ACCOUNT_COST - BASE_COST gas to the global refund counter if location exists in the trielocation to be DESIGNATOR ++ target, matching the delegation process defined in EIP-7702
target is 0x0 do not write the designation. Clear the code at location and reset the location's code hash to the empty hash 0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470.location is 0, increment it to 1location onto the stackOn step 8, target MUST be exactly 20 bytes. If the value retrieved from the stack is smaller than 20 bytes, it MUST be left fill (big-endian notation) with zeros. If it is bigger than 20 bytes, it must be trimmed of the highest bytes. The code placed at location MUST be exactly 23 bytes long, following EIP-7702.
The delegation indicator created at location behaves identically to those created by EIP-7702.
Note: The delegation is effective immediately upon the completion of the operation. Calls to the address as soon as the next operation will execute the newly delegated code.
The delegation indicators created by the SETDELEGATE opcode are the same objects as the one created using EIP-7702. Therefore, all the behavior specificities documented in EIP-7702 (CODESIZE, CODECOPY, targeting precompile, or chaining delegation indicator) also apply here. Any future EIP that modify the behavior of EIP-7702 delegation indicators should also apply to the delegation indicators created using SETDELEGATE. They are not contracts, and cannot be deleted using SELFDESTRUCT, even if the SELFDESTRUCT appens in the same transaction that created the account at location. Destruction of the delegations SHOULD only be possible by the same caller (that created them) doing a new SETDELEGATE call with the same salt and a zero target.
Step 9 ensures that an account that was created using SETDELEGATE never returns to an empty state (forbiden by EIP-7523). Even if the balance is zero, no state was ever set, and the code is removed by a SETDELEGATE operation (with zero target), then the nonce being (at least) one would guarantee the account is not empty.
These parameters are the same ones as used in EIP-7702.
| Constant | Value |
|---|---|
DESIGNATOR | 0xef0100 |
EMPTY_ACCOUNT_COST | 25000 |
BASE_COST | 12500 |
The execution of the SETDELEGATE instruction involves fewer moving pieces than what EIP-7702 gas costs account for:
Therefore, the cost of executing this instruction could be lower than EIP-7702. Numbers from EIP-7702 are reused for simplicity. They are lower than CREATE or CREATE2 operations, making the use of this instruction competitive for the intended use-cases.
The derivation of the location is designed not to conflict with contracts created using the CREATE or CREATE2 opcodes. In particular, the pre-images used to hash the produced address have different lengths, preventing any collision:
Contracts deployed using CREATE2 have an address that is derived from a 85 bytes long pre-image, as opposed to 55 bytes for SET_DELEGATE. This observation alone remove the risk of pre-image collision.
Contracts deployed using CREATE have an address that is derived from the RLP([address, nonce]). For this pre-image to have a length 55 (like SET_DELEGATE), nonce must be 32 bytes long. In that case, the RLP([address, nonce]) would be 0xf694<address>a0<nonce> and would thus not start with the magic value used by SETDELEGATE. A smaller nonce could lead to the pre-image starting with 0xef, but in that case the pre-image would be smaller than 55 bytes. Even in that case, the pre-image would start with 0xef94, 0x94 encoding the address object (that is 20 bytes long).
Reusing EIP-7702 behavior, including clearing the code if the target is 0, results in the ability to upgrade or even "remove" the created designator. This process is controlled (and can be restricted) by the factory (the contract that calls SETDELEGATE). Some factories will add checks that prevent re-executing SETDELEGATE with a salt that was already used, making the create designator immutable. Others may allow access-restricted upgrades, but prevent deletion. In any case, guarantees about the lifecycle of the designator created using SETDELEGATE are provided by the contracts that call it and not by the protocol.
As documented in EIP-7702, designator chains or loops are not resolved. This means that, unlike clones, chaining is an issue. This is however something developers are used to, as chaining proxy can result in strange behaviors, including infinite delegation loops.
Factories may want to protect against this risk by verifying that the target doesn't contain a designator. This can be achieved using a legacy contract helper that has access to EXTCODEHASH. It could also be done using other forms of introspection such as an ACCOUNT_TYPE instruction.
Unlike EIP-7702 signature, which can be included in any transaction, and can thus lead to initialization front-running if the implementation doesn't check the authenticity of the initialization parameters, CREATE_DELEGATE is executed by a smart contract that can execute the initialization logic atomically, just after the delegation is created. This process is well-known to developers that initialize clones and proxies just after creation.
If a contract performs multiple SETDELEGATE operations with the same salt but different targets within the same transaction, while doing calls corresponding address, this would have, in the same transaction without reverts, an address that has multiple different codes associated with it, two or more of which are executed. This include the delegation being removed/reset any number of time during the transaction.
This behavior, is already possible with more traditional upgradeable contracts, where change of target are caused by a specific storage slot being modified.
Copyright and related rights waived via CC0.