From 93de9d8859d4041f074d30cb9dea461691c48f13 Mon Sep 17 00:00:00 2001 From: Francisco Giordano Date: Sat, 14 Dec 2024 13:59:06 -0300 Subject: [PATCH 1/5] apply feedback from @jochem-brouwer in #8969 --- EIPS/eip-7702.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/EIPS/eip-7702.md b/EIPS/eip-7702.md index b2cbf9fe1fb5ce..f564c7e04dfba3 100644 --- a/EIPS/eip-7702.md +++ b/EIPS/eip-7702.md @@ -86,7 +86,7 @@ If transaction execution results in failure (any exceptional condition or code r ##### Delegation Designation -The delegation designation uses the banned opcode `0xef` from [EIP-3541](./eip-3541.md) to designate the code has a special purpose. This designator requires all code executing operations to follow the address pointer to get the account's executable code, and requires all other code reading operations to act only on the first 2 bytes of the designator (`0xef01`). The following instructions are impacted: `EXTCODESIZE`, `EXTCODECOPY`, `EXTCODEHASH`, `CALL`, `CALLCODE`, `STATICCALL`, `DELEGATECALL`, as well as transactions with `destination` targeting the code with delegation designation. +The delegation designation uses the banned opcode `0xef` from [EIP-3541](./eip-3541.md) to designate the code has a special purpose. This designator requires all code executing operations to follow the address pointer to get the account's executable code, and requires all other code reading operations to act only on the first 2 bytes of the designator (`0xef01`). The following reading instructions are impacted: `EXTCODESIZE`, `EXTCODECOPY`, `EXTCODEHASH`, and the following executing instructions are impacted: `CALL`, `CALLCODE`, `STATICCALL`, `DELEGATECALL`, as well as transactions with `destination` targeting the code with delegation designation. For example, `EXTCODESIZE` would return `2` (the size of `0xef01`) instead of `23` which would represent the delegation designation, `EXTCODEHASH` would return `0xeadcdba66a79ab5dce91622d1d75c8cff5cff0b96944c3bf1072cd08ce018329` (`keccak256(0xef01)`), and `CALL` would load the code from `address` and execute it in the context of `authority`. @@ -252,6 +252,10 @@ While there are a few mitigations for this, the authors recommend that clients d A related issue is that an EOA's nonce maybe incremented more than once per transaction. Because clients already need to be robust in a worse scenario (described above), it isn't a major security concern. However, clients should be aware this behavior is possible and design their transaction propagation accordingly. +### Storage management + +In order to simplify the migration of an account from one delegate contract to another, it is important for delegate contracts to use storage in a disciplined way that ensures they won't conflict with one another. For example, through the use of [EIP-7201](./eip-7201.md) + ## Copyright Copyright and related rights waived via [CC0](../LICENSE.md). From e5493b182f15b72c9f2d3435ab515db4e48423a8 Mon Sep 17 00:00:00 2001 From: Francisco Giordano Date: Sat, 14 Dec 2024 14:16:26 -0300 Subject: [PATCH 2/5] add security consideration about storage --- EIPS/eip-7702.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/EIPS/eip-7702.md b/EIPS/eip-7702.md index f564c7e04dfba3..631860629bcc1a 100644 --- a/EIPS/eip-7702.md +++ b/EIPS/eip-7702.md @@ -254,7 +254,9 @@ A related issue is that an EOA's nonce maybe incremented more than once per tran ### Storage management -In order to simplify the migration of an account from one delegate contract to another, it is important for delegate contracts to use storage in a disciplined way that ensures they won't conflict with one another. For example, through the use of [EIP-7201](./eip-7201.md) +In order to simplify the migration of an account from one delegate contract to another, it's important for these contracts to use storage in a way that avoids accidental collisions among them. For example, using [EIP-7201](./eip-7201.md) a contract may root its storage layout at a slot dependent on a unique identifier. To help with this, smart contract languages may provide a way of re-rooting the entire storage layout of an existing contract implementation. + +Changing an account's delegation is a security-critical operation that should not be done lightly, especially if the newly delegated code is not purposely designed and tested as an upgrade to the old one. If all contracts previously delegated to by the account used the approach described above, a migration should not cause any issues. However, if there is any doubt, it is recommended to first clear all account storage, an operation that is not natively offered by the protocol but that a special-purpose delegate contract can be designed to implement. ## Copyright From 95421031b0043b6ffe7d09c7aaa8301fa99a4e0c Mon Sep 17 00:00:00 2001 From: Francisco Giordano Date: Sat, 14 Dec 2024 14:47:46 -0300 Subject: [PATCH 3/5] fix eip->erc --- 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 631860629bcc1a..13ad64607e8eea 100644 --- a/EIPS/eip-7702.md +++ b/EIPS/eip-7702.md @@ -254,7 +254,7 @@ A related issue is that an EOA's nonce maybe incremented more than once per tran ### Storage management -In order to simplify the migration of an account from one delegate contract to another, it's important for these contracts to use storage in a way that avoids accidental collisions among them. For example, using [EIP-7201](./eip-7201.md) a contract may root its storage layout at a slot dependent on a unique identifier. To help with this, smart contract languages may provide a way of re-rooting the entire storage layout of an existing contract implementation. +In order to simplify the migration of an account from one delegate contract to another, it's important for these contracts to use storage in a way that avoids accidental collisions among them. For example, using [ERC-7201](./erc-7201.md) a contract may root its storage layout at a slot dependent on a unique identifier. To help with this, smart contract languages may provide a way of re-rooting the entire storage layout of an existing contract implementation. Changing an account's delegation is a security-critical operation that should not be done lightly, especially if the newly delegated code is not purposely designed and tested as an upgrade to the old one. If all contracts previously delegated to by the account used the approach described above, a migration should not cause any issues. However, if there is any doubt, it is recommended to first clear all account storage, an operation that is not natively offered by the protocol but that a special-purpose delegate contract can be designed to implement. From b3201becd5ad2aba9049911bc37248d926475054 Mon Sep 17 00:00:00 2001 From: Francisco Giordano Date: Sun, 15 Dec 2024 12:43:15 -0300 Subject: [PATCH 4/5] rename path erc->eip --- 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 13ad64607e8eea..48e5e6454a9a85 100644 --- a/EIPS/eip-7702.md +++ b/EIPS/eip-7702.md @@ -254,7 +254,7 @@ A related issue is that an EOA's nonce maybe incremented more than once per tran ### Storage management -In order to simplify the migration of an account from one delegate contract to another, it's important for these contracts to use storage in a way that avoids accidental collisions among them. For example, using [ERC-7201](./erc-7201.md) a contract may root its storage layout at a slot dependent on a unique identifier. To help with this, smart contract languages may provide a way of re-rooting the entire storage layout of an existing contract implementation. +In order to simplify the migration of an account from one delegate contract to another, it's important for these contracts to use storage in a way that avoids accidental collisions among them. For example, using [ERC-7201](./eip-7201.md) a contract may root its storage layout at a slot dependent on a unique identifier. To help with this, smart contract languages may provide a way of re-rooting the entire storage layout of an existing contract implementation. Changing an account's delegation is a security-critical operation that should not be done lightly, especially if the newly delegated code is not purposely designed and tested as an upgrade to the old one. If all contracts previously delegated to by the account used the approach described above, a migration should not cause any issues. However, if there is any doubt, it is recommended to first clear all account storage, an operation that is not natively offered by the protocol but that a special-purpose delegate contract can be designed to implement. From f1582ed31b1cdc8977889d8435a5b98b61a0f73b Mon Sep 17 00:00:00 2001 From: Francisco Giordano Date: Sun, 15 Dec 2024 13:35:32 -0300 Subject: [PATCH 5/5] rearrange for clarity --- EIPS/eip-7702.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-7702.md b/EIPS/eip-7702.md index 48e5e6454a9a85..76cb945cde48f1 100644 --- a/EIPS/eip-7702.md +++ b/EIPS/eip-7702.md @@ -254,9 +254,11 @@ A related issue is that an EOA's nonce maybe incremented more than once per tran ### Storage management -In order to simplify the migration of an account from one delegate contract to another, it's important for these contracts to use storage in a way that avoids accidental collisions among them. For example, using [ERC-7201](./eip-7201.md) a contract may root its storage layout at a slot dependent on a unique identifier. To help with this, smart contract languages may provide a way of re-rooting the entire storage layout of an existing contract implementation. +Changing an account's delegation is a security-critical operation that should not be done lightly, especially if the newly delegated code is not purposely designed and tested as an upgrade to the old one. -Changing an account's delegation is a security-critical operation that should not be done lightly, especially if the newly delegated code is not purposely designed and tested as an upgrade to the old one. If all contracts previously delegated to by the account used the approach described above, a migration should not cause any issues. However, if there is any doubt, it is recommended to first clear all account storage, an operation that is not natively offered by the protocol but that a special-purpose delegate contract can be designed to implement. +In particular, in order to ensure a safe migration of an account from one delegate contract to another, it's important for these contracts to use storage in a way that avoids accidental collisions among them. For example, using [ERC-7201](./eip-7201.md) a contract may root its storage layout at a slot dependent on a unique identifier. To simplify this, smart contract languages may provide a way of re-rooting the entire storage layout of existing contract source code. + +If all contracts previously delegated to by the account used the approach described above, a migration should not cause any issues. However, if there is any doubt, it is recommended to first clear all account storage, an operation that is not natively offered by the protocol but that a special-purpose delegate contract can be designed to implement. ## Copyright