ethereum
Update EIP-7702: add delegation designation
This is an idea originally proposed by @vbuterin.
One aspect of 7702 that hasn't sat right with many involved is the fact that some types of 7702 authorizations do not expire. For delegations that are ephemeral, it's important to have a type of authorization that is replayable (which often means irrevocable), because it allows users to distance their activity from the master key of the account, e.g. delegate control to a smart wallet which can have subkeys with different privileges.
Because previous attempts at account delegation have relied on just-in-time provision of authorizations, the only way to make the authorizations replayable has been to make them irrevocable (or revocation impractical, see maxNonce mechanism). If we took a step back and thought about what we really want to have, regardless of the technical implications, the mechanism we are trying to create should allow an EOA to list on-chain that it has delegated control of it's account to a smart contract.
We've shied away from making changes to the account structure in the trie many times, thus the design of many of these "make EOAs better" proposals. An alternative route is to use an already existing member of the account structure to designate the code the EOA wants to delegate to. With EIP-3541, we now have a rich sequence of code prefixes that cannot be deployed on-chain and can be used to denote other meanings.
This is the core of the proposal: keep the 7702 auth message similar to how it is (although require nonce in sig) and actually set a designator in the EOA's account. The delegation designation would be of the form 0xef01 || address where address is the account whose code should be used in place of the designation.
This mechanism should simplify how we reason about authorizations and revocations. Other than it being more complicated than many of the current proposals, I don't see many downsides to this approach.
If an EOA were to have an active authorization with this approach and then the EOA sends a regular, non-7702 transaction after, will that invalidate the active authorization when the EOA then wants to execute a 7702 transaction?
If an EOA were to have an active authorization with this approach and then the EOA sends a regular, non-7702 transaction after, will that invalidate the active authorization when the EOA then wants to execute a 7702 transaction?
@Jrachman no, the authorization would persist in the account. As spec'd it is currently impossible to "invalidate" a delegation, it is only possible to delegate to something else.
@lightclient then there should be an "undelegate" option. Such as delegating to yourself or keeping the address portion of the message empty and just signing two bytes.
@shemnon what purpose would an undelegation mechanism serve vs. simply delegating to zero address like I mentioned?
@lightclient, if you delegate to zero address, wouldn't any CALL to your account go to zero address, including ones with value?
Delegating to self also would be problematic as first opcode (ef) would result in an abort. Maybe we should mention how we should deal with this? Maybe disallow it?
It would be trapped out to delete the ef code. In some L2s there may be code at zeros, which is why I didn't recommend that. Removal would be to restore "pure EOA" behavior, where calling the EOA only deposits value.
@shemnon then we can trap out delegating to self as removing and delete the code. But this needs to be specified in the spec then
Last call on this, will merge later today unless there is more feedback.
See https://github.com/ethereum/EIPs/pull/8677#discussion_r1647794701. IMO this part makes no sense in the new design and should be removed:
In the case of multiple tuples for the same authority, set the code specified by the address in the first occurrence.
@lightclient , The spec still doesn't specify the cost of the operation. it references "PER_CONTRACT_CODE_BASE_COST", which is not defined. "PER_AUTH_BASE_COST" is defined but if that constant should be used, it is too cheap: being only 2500 gas, it is half of the SSTORE "modify" cost and 1/8th of the cost of SSTORE to empty cell
@drortirosh sorry I though I updated to remove the ref to PER_CONTRACT_CODE_BASE_COST. It's fixed now.
The cost is not finalized and should definitely be updated now that code is deployed to the account. In particular, we need to update it to deal with creating new accounts (usually 25k gas). I'll leave that for another PR. If you have a suggestion for gas schedule, please post it on FEM.