From abd61bae6f0a6a86c0369c1877b8c7480331a45d Mon Sep 17 00:00:00 2001 From: sudeepdino008 Date: Tue, 25 Jun 2024 17:41:34 +0530 Subject: [PATCH 1/3] eip-7702: move the lighter check up --- EIPS/eip-7702.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-7702.md b/EIPS/eip-7702.md index 513ffc2160663..66960805c7812 100644 --- a/EIPS/eip-7702.md +++ b/EIPS/eip-7702.md @@ -63,8 +63,8 @@ The [EIP-2718](./eip-2718.md) `ReceiptPayload` for this transaction is `rlp([sta At the start of executing the transaction, after incrementing the sender's nonce, for each `[chain_id, address, nonce, y_parity, r, s]` tuple do the following: -1. `authority = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s]` -2. Verify the chain id is either 0 or the chain's current ID. +1. Verify the chain id is either 0 or the chain's current ID. +2. `authority = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s]` 3. Add `authority` to `accessed_addresses` (as defined in [EIP-2929](./eip-2929.md).) 4. Verify the code of `authority` is either empty or already delegated. 5. Verify the nonce of `authority` is equal to `nonce`. From 9179883b12d2a6839d4db094c42b7995a450c8a3 Mon Sep 17 00:00:00 2001 From: sudeepdino008 Date: Wed, 28 Aug 2024 11:46:09 +0530 Subject: [PATCH 2/3] selfdestruct opcode behaviour change in eip-7702 --- EIPS/eip-7702.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/EIPS/eip-7702.md b/EIPS/eip-7702.md index 66960805c7812..63e56b21731b8 100644 --- a/EIPS/eip-7702.md +++ b/EIPS/eip-7702.md @@ -120,6 +120,12 @@ The main families of instructions where a ban was considered were storage relate Creation instructions were considered for a ban on other similar EIPs, however because this EIP allows EOAs to spend value intra-transaction, the concern with bumping the nonce intra-transaction and invalidating pending transactions is not significant. A neat byproduct of this is that by combining EIP-7702 and CREATE2 it will be possible to commit to deploy specific bytecode to an address without committing to any fee market parameters. This solves the long standing issue of universal cross-chain contract deployment. +### behaviour of SELFDESTRUCT opcode + +[EIP-6780](./eip-6780.md) restricted SELFDESTRUCT opcode behaviour, allowing account data deletion only if the account was created in the same transaction. A 7702 transaction essentially allows code to be assigned to an EOA. The subsequent execution of such code in the same transaction can cause the EOA to selfdestruct, causing account data deletion, leading to issues like transaction replay. + +To prevent problems arising from EOAs selfdestructing, this EIP updates the opcode behaviour, by not deleting account data for EOAs with delegated designation. + ### Signature structure The signature scheme in this EIP supports flexible design patterns, allowing for both full delegation to `address` and more protected delegations to `address`. From ab79897d60ab1d053386f8c9f467592e64d7a24c Mon Sep 17 00:00:00 2001 From: sudeepdino008 Date: Wed, 28 Aug 2024 21:11:12 +0530 Subject: [PATCH 3/3] respond to comments --- EIPS/eip-7702.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/EIPS/eip-7702.md b/EIPS/eip-7702.md index 63e56b21731b8..96730f036f1f5 100644 --- a/EIPS/eip-7702.md +++ b/EIPS/eip-7702.md @@ -63,8 +63,8 @@ The [EIP-2718](./eip-2718.md) `ReceiptPayload` for this transaction is `rlp([sta At the start of executing the transaction, after incrementing the sender's nonce, for each `[chain_id, address, nonce, y_parity, r, s]` tuple do the following: -1. Verify the chain id is either 0 or the chain's current ID. -2. `authority = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s]` +1. `authority = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s]` +2. Verify the chain id is either 0 or the chain's current ID. 3. Add `authority` to `accessed_addresses` (as defined in [EIP-2929](./eip-2929.md).) 4. Verify the code of `authority` is either empty or already delegated. 5. Verify the nonce of `authority` is equal to `nonce`. @@ -120,11 +120,11 @@ The main families of instructions where a ban was considered were storage relate Creation instructions were considered for a ban on other similar EIPs, however because this EIP allows EOAs to spend value intra-transaction, the concern with bumping the nonce intra-transaction and invalidating pending transactions is not significant. A neat byproduct of this is that by combining EIP-7702 and CREATE2 it will be possible to commit to deploy specific bytecode to an address without committing to any fee market parameters. This solves the long standing issue of universal cross-chain contract deployment. -### behaviour of SELFDESTRUCT opcode +### Behaviour of SELFDESTRUCT opcode [EIP-6780](./eip-6780.md) restricted SELFDESTRUCT opcode behaviour, allowing account data deletion only if the account was created in the same transaction. A 7702 transaction essentially allows code to be assigned to an EOA. The subsequent execution of such code in the same transaction can cause the EOA to selfdestruct, causing account data deletion, leading to issues like transaction replay. -To prevent problems arising from EOAs selfdestructing, this EIP updates the opcode behaviour, by not deleting account data for EOAs with delegated designation. +To prevent problems arising from EOAs selfdestructing, this EIP updates the opcode behaviour, which will not delete account data for EOAs with delegated designation. ### Signature structure