Skip to content

Commit

Permalink
Merge 725ed31 into ced7e8f
Browse files Browse the repository at this point in the history
  • Loading branch information
g11tech authored Jul 30, 2024
2 parents ced7e8f + 725ed31 commit e55449f
Showing 1 changed file with 14 additions and 1 deletion.
15 changes: 14 additions & 1 deletion EIPS/eip-7702.md
Original file line number Diff line number Diff line change
Expand Up @@ -121,9 +121,22 @@ One consideration when signing a code pointer is what code might that address po

An alternative to adding chain ID could be to sign over the code the address points to. This seems to have the benefit of both minimizing the on-chain size of auth tuples while retaining specificity of the actual code running in the account. One unfortunate issue of this format though is that it imposes a database lookup to determine the signer of each auth tuple. This imposition itself seems to create enough complexity in transaction propagation that it is decided to avoid and simply sign over address directly.

#### Delegation Storage

Considering that the delegation from one contract to another contract may cause conflicts and corrupt the storage with a broken contract at the least and a compromised contract at the worst, it is prudent to separate the storage of each delegation in deterministic way.

To this effect, the delegated EOA's storage keys should be proxied (accessed or written) at `keccak256(key[0:30]||address)[0:30] || key[31:31]`. So essentially we use this key modification for `SLOAD` and `SSTORE` operations for the delegated EOA's orignal key but still writing into EOA storage.

With this method:

* if EOA is delegated to a new address, it (essentially) starts with clean storage
* if the contract is delegated back to a previous `address`, the EVM will be able to _re-attach_ its old storage.
* chunks of `256` consecutive keys are mapped again to consecutive keys which is nice for debuggings and more importantly state trie optimizations (à la verkle)
* it will be very expensive for a malicious delegation to find storage conflicts and corrupt them

#### In-protocol revocation

Unlike previous versions of this EIP and EIPs similar, the delegation designation can be revoked at anytime signing and sending a EIP-7702 authorization to a new target with the account's current nonce. Without such action, a delegation will remain valid in perpetuity.
Unlike previous versions of this EIP, the delegation designation can be revoked at anytime by signing and sending an EIP-7702 authorization to a new target with the account's current nonce. Without such action, a delegation will remain valid in perpetuity.

### Self-sponsoring: allowing `tx.origin` to set code

Expand Down

0 comments on commit e55449f

Please sign in to comment.