From 9dda35f89f508627ab15103a731932c98d15f0ed Mon Sep 17 00:00:00 2001 From: gajinder Date: Fri, 26 Jul 2024 18:20:00 +0530 Subject: [PATCH] Update EIP-7702: Proxy the storage of a delegation to its unique deleterminstic address --- EIPS/eip-7702.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/EIPS/eip-7702.md b/EIPS/eip-7702.md index 179290d99c8fd..47b76c84823dd 100644 --- a/EIPS/eip-7702.md +++ b/EIPS/eip-7702.md @@ -117,6 +117,12 @@ 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 can cause conflict and corruption of the storage with broken contract in the least and a compromized 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 should be proixed and accessed/written at `keccak256(authority||address)[0:20]`. This way, if the contract is delegated back to a previous `address`, EVM will be able to _re-attach_ its old storage. + #### 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.