From 9dda35f89f508627ab15103a731932c98d15f0ed Mon Sep 17 00:00:00 2001 From: gajinder Date: Fri, 26 Jul 2024 18:20:00 +0530 Subject: [PATCH 01/14] 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 179290d99c8fd9..47b76c84823ddc 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. From 8ae332b897fcc057412e49afbc1b214487c683b3 Mon Sep 17 00:00:00 2001 From: g11tech Date: Fri, 26 Jul 2024 18:45:33 +0530 Subject: [PATCH 02/14] Update EIPS/eip-7702.md Co-authored-by: Phil Ngo <58080811+philknows@users.noreply.github.com> --- EIPS/eip-7702.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7702.md b/EIPS/eip-7702.md index 47b76c84823ddc..6695342f4cacc7 100644 --- a/EIPS/eip-7702.md +++ b/EIPS/eip-7702.md @@ -119,7 +119,7 @@ An alternative to adding chain ID could be to sign over the code the address poi #### 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. +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 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. From 1eba4339ed8e0bfad32cab80bbca7fc0143f25b3 Mon Sep 17 00:00:00 2001 From: gajinder Date: Fri, 26 Jul 2024 18:46:58 +0530 Subject: [PATCH 03/14] fix typo --- EIPS/eip-7702.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7702.md b/EIPS/eip-7702.md index 6695342f4cacc7..59b4bb7dfcc5d3 100644 --- a/EIPS/eip-7702.md +++ b/EIPS/eip-7702.md @@ -121,7 +121,7 @@ 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 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. +To this effect, the delegated EOA's storage should be proxied 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 From 988b0a0d7dc10b2913a47d1f8c5a91c16496f496 Mon Sep 17 00:00:00 2001 From: gajinder Date: Fri, 26 Jul 2024 18:49:01 +0530 Subject: [PATCH 04/14] apply feedback --- EIPS/eip-7702.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7702.md b/EIPS/eip-7702.md index 59b4bb7dfcc5d3..1c2f04cd05adeb 100644 --- a/EIPS/eip-7702.md +++ b/EIPS/eip-7702.md @@ -121,7 +121,7 @@ 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 should be proxied 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. +To this effect, the delegated EOA's storage should be proxied and accessed or written at `keccak256(authority||address)[0:20]`. With this method, if the contract is delegated back to a previous `address`, the EVM will be able to _re-attach_ its old storage. #### In-protocol revocation From 5fa6848ca72d11d42096dbdbf3ed29a41cbc02f0 Mon Sep 17 00:00:00 2001 From: g11tech Date: Fri, 26 Jul 2024 18:50:12 +0530 Subject: [PATCH 05/14] Update EIPS/eip-7702.md Co-authored-by: Phil Ngo <58080811+philknows@users.noreply.github.com> --- EIPS/eip-7702.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7702.md b/EIPS/eip-7702.md index 1c2f04cd05adeb..560ec7e6344b0d 100644 --- a/EIPS/eip-7702.md +++ b/EIPS/eip-7702.md @@ -125,7 +125,7 @@ To this effect, the delegated EOA's storage should be proxied and accessed or wr #### 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 From 26c1a704400fc6aa0439473013e2feb28a23f0c0 Mon Sep 17 00:00:00 2001 From: gajinder Date: Fri, 26 Jul 2024 19:54:42 +0530 Subject: [PATCH 06/14] apply feedback and clarifications --- EIPS/eip-7702.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/EIPS/eip-7702.md b/EIPS/eip-7702.md index 560ec7e6344b0d..bed6081d5ef207 100644 --- a/EIPS/eip-7702.md +++ b/EIPS/eip-7702.md @@ -121,7 +121,14 @@ 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 should be proxied and accessed or written at `keccak256(authority||address)[0:20]`. With this method, if the contract is delegated back to a previous `address`, the EVM will be able to _re-attach_ its old storage. +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. + +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. + +Again for the purpose of [EIP-158](../eip-158.md) cleanup, this storage should be considered attached to the EOA address. #### In-protocol revocation From 0a88b03c338ddd85fa6a4c2a2b5176fede59cd38 Mon Sep 17 00:00:00 2001 From: gajinder Date: Fri, 26 Jul 2024 19:57:01 +0530 Subject: [PATCH 07/14] cleanup --- EIPS/eip-7702.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/EIPS/eip-7702.md b/EIPS/eip-7702.md index bed6081d5ef207..3dc1d2826ee3d7 100644 --- a/EIPS/eip-7702.md +++ b/EIPS/eip-7702.md @@ -128,8 +128,6 @@ 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. -Again for the purpose of [EIP-158](../eip-158.md) cleanup, this storage should be considered attached to the EOA address. - #### In-protocol revocation 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. From 99617f2e0aa920a377bf136c6f45aa941f0e7c5d Mon Sep 17 00:00:00 2001 From: gajinder Date: Fri, 26 Jul 2024 21:41:03 +0530 Subject: [PATCH 08/14] add optimizattion --- EIPS/eip-7702.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/EIPS/eip-7702.md b/EIPS/eip-7702.md index 3dc1d2826ee3d7..93e2b0bcf62400 100644 --- a/EIPS/eip-7702.md +++ b/EIPS/eip-7702.md @@ -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 From 23b7c9358c77580d8bc22a4cf4884773e3498a3a Mon Sep 17 00:00:00 2001 From: gajinder Date: Fri, 26 Jul 2024 22:00:36 +0530 Subject: [PATCH 09/14] typo fix --- EIPS/eip-7702.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7702.md b/EIPS/eip-7702.md index 93e2b0bcf62400..30fe6caa32dcc9 100644 --- a/EIPS/eip-7702.md +++ b/EIPS/eip-7702.md @@ -121,7 +121,7 @@ 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)[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. +To this effect, the delegated EOA's storage keys should be proxied (accessed or written) at `keccak256(key||address)[0:30] || key[31: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: From 2a6bf98111cef4a71ae9e51ff31e4551cfca0118 Mon Sep 17 00:00:00 2001 From: gajinder Date: Fri, 26 Jul 2024 22:12:19 +0530 Subject: [PATCH 10/14] fix --- EIPS/eip-7702.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7702.md b/EIPS/eip-7702.md index 30fe6caa32dcc9..07276f05ee9e66 100644 --- a/EIPS/eip-7702.md +++ b/EIPS/eip-7702.md @@ -121,7 +121,7 @@ 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)[0:30] || key[31: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. +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: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: From c83ca52a03a9a8c4f4769c7c1d7ba94430555fb8 Mon Sep 17 00:00:00 2001 From: gajinder Date: Fri, 26 Jul 2024 22:14:12 +0530 Subject: [PATCH 11/14] fix --- EIPS/eip-7702.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7702.md b/EIPS/eip-7702.md index 07276f05ee9e66..74794940a5bc76 100644 --- a/EIPS/eip-7702.md +++ b/EIPS/eip-7702.md @@ -127,7 +127,7 @@ 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) +* chunks of `256` consecutive keys are mapped again to consecutive keys which is nice for debuggings and more importantly state trie optimizations (a la verkle) #### In-protocol revocation From c9f84a9849eba47caf682c0f2816deb087b23802 Mon Sep 17 00:00:00 2001 From: gajinder Date: Fri, 26 Jul 2024 22:20:17 +0530 Subject: [PATCH 12/14] refix --- EIPS/eip-7702.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7702.md b/EIPS/eip-7702.md index 74794940a5bc76..113b14a965d58e 100644 --- a/EIPS/eip-7702.md +++ b/EIPS/eip-7702.md @@ -121,7 +121,7 @@ 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[0:30]||address)[0:30] || key[31: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. +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: From 44968ccb59a1500644440f193cdb0d328c278715 Mon Sep 17 00:00:00 2001 From: g11tech Date: Sat, 27 Jul 2024 00:43:26 +0530 Subject: [PATCH 13/14] Update EIPS/eip-7702.md Co-authored-by: Guillaume Ballet <3272758+gballet@users.noreply.github.com> --- EIPS/eip-7702.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7702.md b/EIPS/eip-7702.md index 113b14a965d58e..2916dbf1f886d6 100644 --- a/EIPS/eip-7702.md +++ b/EIPS/eip-7702.md @@ -127,7 +127,7 @@ 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 (a la verkle) +* chunks of `256` consecutive keys are mapped again to consecutive keys which is nice for debuggings and more importantly state trie optimizations (à la verkle) #### In-protocol revocation From 725ed31b976a2bba8ceaf6db20181300fb1548b7 Mon Sep 17 00:00:00 2001 From: gajinder Date: Tue, 30 Jul 2024 13:03:38 +0530 Subject: [PATCH 14/14] add another good point --- EIPS/eip-7702.md | 1 + 1 file changed, 1 insertion(+) diff --git a/EIPS/eip-7702.md b/EIPS/eip-7702.md index 2916dbf1f886d6..2d1ada9bafe50f 100644 --- a/EIPS/eip-7702.md +++ b/EIPS/eip-7702.md @@ -128,6 +128,7 @@ 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