Skip to content

Commit

Permalink
add optimizattion
Browse files Browse the repository at this point in the history
  • Loading branch information
g11tech committed Jul 26, 2024
1 parent 0a88b03 commit 99617f2
Showing 1 changed file with 2 additions and 1 deletion.
3 changes: 2 additions & 1 deletion EIPS/eip-7702.md
Original file line number Diff line number Diff line change
Expand Up @@ -121,12 +121,13 @@ An alternative to adding chain ID could be to sign over the code the address poi

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||address)`. 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.
To this effect, the delegated EOA's storage keys should be proxied (accessed or written) at `keccak256(key||address)[0:30] || key[30:32]`. 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 as well as state trie optimizations (a la verkle)

#### In-protocol revocation

Expand Down

0 comments on commit 99617f2

Please sign in to comment.