From 04a56dd8534705b7ea3b25d7a77a5299a914b5a3 Mon Sep 17 00:00:00 2001 From: Peter Date: Fri, 18 Apr 2025 19:52:47 +0300 Subject: [PATCH 1/9] fix: eth org link --- docs/wiki/research/account-abstraction/eip-7702.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/wiki/research/account-abstraction/eip-7702.md b/docs/wiki/research/account-abstraction/eip-7702.md index 178cf91e..de0d517d 100644 --- a/docs/wiki/research/account-abstraction/eip-7702.md +++ b/docs/wiki/research/account-abstraction/eip-7702.md @@ -7,7 +7,7 @@ The primary goal of EIP-7702 is to introduce a standardized framework that allows developers to create custom transaction validation logic. A new transaction type (Type 4) is introduced to secure and allow user-friendly wallet solutions, as well as innovative use cases that were previously not possible with the traditional account model. By abstracting the account logic, EIP-7702 aims to reduce the complexity of smart contract interactions and lower the barrier to entry for new users. With this feature, users can set their address to be represented by a code of an existing smart contract. Type 4 transaction allows address owners to sign an authorization that sets their address to mimic a chosen smart contract. -With this EIP, users can opt in to programmable wallets that allow new features like transaction bundling, gasless transacting and custom asset access for alternative recovery schemes. It's another step towards [account abstraction](https://ethereum.org/roadmap/account-abstraction/) that improves user experience and security when interacting with Ethereum. +With this EIP, users can opt in to programmable wallets that allow new features like transaction bundling, gasless transacting and custom asset access for alternative recovery schemes. It's another step towards [account abstraction](https://ethereum.org/en/roadmap/account-abstraction/) that improves user experience and security when interacting with Ethereum. Review `@lightclient's` technical deep dive: From e5ccfad3b2f9d825554c3919985c9ee286345a53 Mon Sep 17 00:00:00 2001 From: Peter Date: Fri, 18 Apr 2025 19:54:35 +0300 Subject: [PATCH 2/9] chore: use convention --- docs/wiki/research/account-abstraction/eip-7702.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/wiki/research/account-abstraction/eip-7702.md b/docs/wiki/research/account-abstraction/eip-7702.md index de0d517d..6bd431d6 100644 --- a/docs/wiki/research/account-abstraction/eip-7702.md +++ b/docs/wiki/research/account-abstraction/eip-7702.md @@ -14,7 +14,7 @@ Review `@lightclient's` technical deep dive: -other resources: +## Resources - [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) - [EIP-7702 Discussion](https://ethereum-magicians.org/t/eip-7702-account-abstraction/) From 36479db4258e8d904e5befc1d11f09d3b08d3a1b Mon Sep 17 00:00:00 2001 From: Peter Date: Fri, 18 Apr 2025 19:57:26 +0300 Subject: [PATCH 3/9] fix: use correct link --- docs/wiki/research/account-abstraction/eip-7702.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/wiki/research/account-abstraction/eip-7702.md b/docs/wiki/research/account-abstraction/eip-7702.md index 6bd431d6..fae00187 100644 --- a/docs/wiki/research/account-abstraction/eip-7702.md +++ b/docs/wiki/research/account-abstraction/eip-7702.md @@ -17,5 +17,5 @@ Review `@lightclient's` technical deep dive: ## Resources - [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) -- [EIP-7702 Discussion](https://ethereum-magicians.org/t/eip-7702-account-abstraction/) +- [EIP-7702 Discussion](https://ethereum-magicians.org/t/eip-7702-set-eoa-account-code/19923) - [Decoding 7702](https://medium.com/inception-capital/decoding-vitaliks-eip-7702-507c56f9f70c) From f96f543c89cb2cfc83a6f446068048c1c5b27727 Mon Sep 17 00:00:00 2001 From: Peter Date: Wed, 23 Apr 2025 23:17:20 +0300 Subject: [PATCH 4/9] feat: outline --- .../research/account-abstraction/eip-7702.md | 83 +++++++++++++++++++ 1 file changed, 83 insertions(+) diff --git a/docs/wiki/research/account-abstraction/eip-7702.md b/docs/wiki/research/account-abstraction/eip-7702.md index fae00187..ac917af9 100644 --- a/docs/wiki/research/account-abstraction/eip-7702.md +++ b/docs/wiki/research/account-abstraction/eip-7702.md @@ -14,8 +14,91 @@ Review `@lightclient's` technical deep dive: +## Why? + +It is also precedeed by ERC-4337, the account abstraction standard. +Given the existence of ERC-4337 you might ask why is EIP-7702 required. The account abstraction has an entirely different goal while this proposal's main goal is to give EOAs some temporary programmability. + +The benefits include of programmability are the following: +- Transaction batching +- Transaction Sponsorship +- Privilege de-escalation and Session keys +- Social Recovery +- And the list is endless... + + +Historically EIP-7702 is a toned-down successor to EIP-3074 which would've added AUTH and AUTHCALL opcodes, but this innitiative didn't make into the protocol. +The main reason for this limited EOA is to push users towards Smart Wallets and create a unified interface froma dApp standpoint. +7702 is a step towards native Account Abstraction and is compatible with Account Abstraction, meaning you can delegate via 7702 to a Smart Wallet. + +## Technical Details + +In the ethereum account model the difference between contract accounts and externally owned accounts is that EOAs do not have code that can be executed onchain. The code field is set to null as you can see here. +This proposal adds a new EIP-2718 compatible transaction call to set code field for an EOA temporarily. +The EIP-2718 `TransactionType` type is called `SET_CODE_TX_TYPE` with value=4. +The `SET_CODE_TX_TYPE` transaction has a `TransactionPayload` object defined as a RLP serialized object w/ the following parts: +`chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s`. +The authorization list is defined as non-empty list of `chain_id, address, nonce, y_parity, r, s` tuple, where the `address` refers to the delegated code's address, the `chain_id` can be set to a valid chain's id or to 0 and the `nonce` has to equal to the EOA for replay protection. +`y_parity, r, s` is the signature of the EOA. +This list can be submitted by anyone meaning the `tx.origin` doesn't have to be the EOA owner as long as it contains a valid signature. Setting the chain id to zero allows the rerunning of the transaction on any chain, given that the nonce values match. + +The transaction receipt is defined as the `status, cumulative_transaction_gas_used, logs_bloom, logs` tuple in RLP seralized form. + +You can learn more about RLP encoding in [this section](https://epf.wiki/#/wiki/EL/RLP). + + +When such a set code transaction is submitted the following basic steps happen for each tuple in the `authorization_list`. +1. Alongside basic validation(e.g. auth.chain_id < 2^256, auth.nonce < 2^64, etc.) the chain id is verified that it is either 0 or the current chain's id. +2. Then the address of the authority is recovered from the signature and the payload. +3. The code of the authority is either set to `0xef0100 || address` if the `address` is not `0x0000000000000000000000000000000000000000`, otherwise the EOA's code is cleared and is set to the hash of an empty address (`0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470`). This acts as a revocation mechanism +4. The addresses are marked as warm address. + +This simplified execution steps skipped important steps, a more detailed execution can be found at the [Behavior section](https://eips.ethereum.org/EIPS/eip-7702#behavior) of the EIP. + + +### creation by template + + +Due to space optimization the traditional `initCode` is replaced by a "code pointer" and the initialization happens during a regular call. +[EIP-3607](https://eips.ethereum.org/EIPS/eip-3607) specifies that an account with deployed code cannot originate transactions. +To work around this the `code` field gets populated with the address of the delegated contract and a prefix which is 23 bytes in total. +The prefix is 3 bytes and the first byte(`ef`) is ... +The next 2 bytes is the 7702 designator. + +### Opcode changes + +Some reading and execution instructions are impacted by the changes, including: + - CODESIZE 23 bytes: 20 for code address + 3 bytes of magic prefix `ef0100`, where `ef` comes from EIP-... + - CODEHASH is the hash of `MAGIC || ADDRESS` and not the hash of the code at `ADDRESS` + - EXTCODESIZE returns 2 + - EXTCODECOPY returns `0xef01` + - CALL instruction would execute the code from `address` in the context of the `authority` + - CALLCODE + - STATICCALL + - DELEGATECALL + +### Wallet and UX Changes + +proxy-contract, a proxy account potentially has multiple "linked" EOAs +The intention of such a proxy contract is that an EIP-7702 transaction delegates to this contract, which points to the wallet implementation of the user. When a user wants to upgrade their wallet they can simple chane the proxy pointer and they don't have to sing another EIP-7702 transaction. +A bundler submits the authorization inside the setcode tx onchain +Next you have to call "yourself" to init the code. The init data is signed and can been anything e.g. owner, a session key, some delegation, etc. +A lot of 4337's components can and should be reused for 7702 e.g. bundler + +### Gas costs + +25000 gas/authorization or 12.5k if account already exists +global refund mechanism applies +destination warming + ## Resources - [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) +- [EIP-7702 Homepage](https://eip7702.io/) - [EIP-7702 Discussion](https://ethereum-magicians.org/t/eip-7702-set-eoa-account-code/19923) - [Decoding 7702](https://medium.com/inception-capital/decoding-vitaliks-eip-7702-507c56f9f70c) +- [EIP-7702: A Deep Dive](https://hackmd.io/@colinlyguo/SyAZWMmr1x) +- [Recommended Proxy Pattern](https://gist.github.com/lightclient/7742e84fde4962f32928c6177eda7523) +- [Awesome EIP-7702](https://github.com/fireblocks-labs/awesome-eip-7702) +- [Great talk about wallet, security, use cases, etc.](https://www.youtube.com/watch?v=TUNtZ5jzXAk) + From d13ca7def84dbb1138c0319b54c0374856face67 Mon Sep 17 00:00:00 2001 From: Peter Date: Thu, 24 Apr 2025 08:24:06 +0300 Subject: [PATCH 5/9] feat: opcodes --- .../research/account-abstraction/eip-7702.md | 17 +++++++---------- 1 file changed, 7 insertions(+), 10 deletions(-) diff --git a/docs/wiki/research/account-abstraction/eip-7702.md b/docs/wiki/research/account-abstraction/eip-7702.md index ac917af9..a3442096 100644 --- a/docs/wiki/research/account-abstraction/eip-7702.md +++ b/docs/wiki/research/account-abstraction/eip-7702.md @@ -62,20 +62,17 @@ This simplified execution steps skipped important steps, a more detailed executi Due to space optimization the traditional `initCode` is replaced by a "code pointer" and the initialization happens during a regular call. [EIP-3607](https://eips.ethereum.org/EIPS/eip-3607) specifies that an account with deployed code cannot originate transactions. To work around this the `code` field gets populated with the address of the delegated contract and a prefix which is 23 bytes in total. -The prefix is 3 bytes and the first byte(`ef`) is ... +The prefix is 3 bytes and the first byte(`ef`) is a banned opcode specified in [EIP-3541](https://eips.ethereum.org/EIPS/eip-3541). The next 2 bytes is the 7702 designator. ### Opcode changes -Some reading and execution instructions are impacted by the changes, including: - - CODESIZE 23 bytes: 20 for code address + 3 bytes of magic prefix `ef0100`, where `ef` comes from EIP-... - - CODEHASH is the hash of `MAGIC || ADDRESS` and not the hash of the code at `ADDRESS` - - EXTCODESIZE returns 2 - - EXTCODECOPY returns `0xef01` - - CALL instruction would execute the code from `address` in the context of the `authority` - - CALLCODE - - STATICCALL - - DELEGATECALL +While `CODESIZE` and `CODECOPY` operate on executable code means that they are not impacted. +Contrary some reading and execution instructions are impacted, including: + - [EXTCODESIZE](https://www.evm.codes/?fork=cancun#3b) returns 2 bytes + - [EXTCODEHASH](https://www.evm.codes/?fork=cancun#3f) is the `keccak256` hash of `0xef01` + - [EXTCODECOPY](https://www.evm.codes/?fork=cancun#3f) returns `0xef01` + - Exeuction instructions (`CALL`, `CALLCODE`, `STATICCALL`, `DELEGATEACLL`) execute the code from the delegated code address in the context of the EOA ### Wallet and UX Changes From c180513987ae3ac4e40e4257461cd1971baea5e8 Mon Sep 17 00:00:00 2001 From: Peter Date: Thu, 24 Apr 2025 09:05:13 +0300 Subject: [PATCH 6/9] chore: cleanup --- .../research/account-abstraction/eip-7702.md | 58 +++++++++---------- 1 file changed, 27 insertions(+), 31 deletions(-) diff --git a/docs/wiki/research/account-abstraction/eip-7702.md b/docs/wiki/research/account-abstraction/eip-7702.md index a3442096..090fcf40 100644 --- a/docs/wiki/research/account-abstraction/eip-7702.md +++ b/docs/wiki/research/account-abstraction/eip-7702.md @@ -14,7 +14,7 @@ Review `@lightclient's` technical deep dive: -## Why? +## Rationale It is also precedeed by ERC-4337, the account abstraction standard. Given the existence of ERC-4337 you might ask why is EIP-7702 required. The account abstraction has an entirely different goal while this proposal's main goal is to give EOAs some temporary programmability. @@ -26,44 +26,40 @@ The benefits include of programmability are the following: - Social Recovery - And the list is endless... - -Historically EIP-7702 is a toned-down successor to EIP-3074 which would've added AUTH and AUTHCALL opcodes, but this innitiative didn't make into the protocol. -The main reason for this limited EOA is to push users towards Smart Wallets and create a unified interface froma dApp standpoint. -7702 is a step towards native Account Abstraction and is compatible with Account Abstraction, meaning you can delegate via 7702 to a Smart Wallet. +Historically EIP-7702 is a simpler alternative to the proposed EIP-3074 which would've added AUTH and AUTHCALL opcodes. +The main reason for this limited EOA is to push users towards Smart Wallets as describe in [ERC-4337](https://eips.ethereum.org/EIPS/eip-4337) and create a unified interface from the dApp perspective. +7702 is a step towards native Account Abstraction and is fully compatible with Account Abstraction, meaning you can delegate via 7702 to a Smart Wallet. ## Technical Details -In the ethereum account model the difference between contract accounts and externally owned accounts is that EOAs do not have code that can be executed onchain. The code field is set to null as you can see here. -This proposal adds a new EIP-2718 compatible transaction call to set code field for an EOA temporarily. -The EIP-2718 `TransactionType` type is called `SET_CODE_TX_TYPE` with value=4. -The `SET_CODE_TX_TYPE` transaction has a `TransactionPayload` object defined as a RLP serialized object w/ the following parts: -`chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s`. -The authorization list is defined as non-empty list of `chain_id, address, nonce, y_parity, r, s` tuple, where the `address` refers to the delegated code's address, the `chain_id` can be set to a valid chain's id or to 0 and the `nonce` has to equal to the EOA for replay protection. -`y_parity, r, s` is the signature of the EOA. -This list can be submitted by anyone meaning the `tx.origin` doesn't have to be the EOA owner as long as it contains a valid signature. Setting the chain id to zero allows the rerunning of the transaction on any chain, given that the nonce values match. - -The transaction receipt is defined as the `status, cumulative_transaction_gas_used, logs_bloom, logs` tuple in RLP seralized form. +In the ethereum account model the difference between contract accounts and externally owned accounts is that EOAs do not have code that can be executed onchain, practically the code field is set to null. +This proposal adds a new [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) compatible transaction call to set code field for an EOA temporarily. +The `TransactionType` type is called `SET_CODE_TX_TYPE` with value=4. +The `TransactionPayload` object defined as a RLP serialized tuple with the following fields: +`chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s`. +The authorization list is defined as non-empty list of `chain_id, address, nonce, y_parity, r, s` tuples, where the `address` refers to the delegated code's address, the `chain_id` can be set to a valid chain's id or to 0 and the `nonce` has to equal to the EOA for replay protection. +`y_parity, r, s` is the signature of the EOA. +This list can be submitted by anyone meaning the `tx.origin` doesn't have to be the EOA owner as long as it contains a valid signature. Setting the chain id to zero allows the resubmission of the transaction on any chain, given that the nonce values match. +The `ReceiptPayload` is defined as the `status, cumulative_transaction_gas_used, logs_bloom, logs` tuple in RLP seralized form. You can learn more about RLP encoding in [this section](https://epf.wiki/#/wiki/EL/RLP). - When such a set code transaction is submitted the following basic steps happen for each tuple in the `authorization_list`. 1. Alongside basic validation(e.g. auth.chain_id < 2^256, auth.nonce < 2^64, etc.) the chain id is verified that it is either 0 or the current chain's id. 2. Then the address of the authority is recovered from the signature and the payload. 3. The code of the authority is either set to `0xef0100 || address` if the `address` is not `0x0000000000000000000000000000000000000000`, otherwise the EOA's code is cleared and is set to the hash of an empty address (`0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470`). This acts as a revocation mechanism -4. The addresses are marked as warm address. +4. The delegation address is marked as warm address. +For each authorization tuple the nonce of the EOA is increased by 1, meaning every tuple has to calculate their nonce value based on their position in the list. This simplified execution steps skipped important steps, a more detailed execution can be found at the [Behavior section](https://eips.ethereum.org/EIPS/eip-7702#behavior) of the EIP. -### creation by template +### Creation by template - Due to space optimization the traditional `initCode` is replaced by a "code pointer" and the initialization happens during a regular call. -[EIP-3607](https://eips.ethereum.org/EIPS/eip-3607) specifies that an account with deployed code cannot originate transactions. -To work around this the `code` field gets populated with the address of the delegated contract and a prefix which is 23 bytes in total. -The prefix is 3 bytes and the first byte(`ef`) is a banned opcode specified in [EIP-3541](https://eips.ethereum.org/EIPS/eip-3541). -The next 2 bytes is the 7702 designator. +[EIP-3607](https://eips.ethereum.org/EIPS/eip-3607) specifies that an account with deployed code cannot originate transactions. +To work around this the `code` field gets populated with the address of the delegated contract and a prefix which is 23 bytes in total. +The prefix is 3 bytes and the first byte(`ef`) is a banned opcode specified in [EIP-3541](https://eips.ethereum.org/EIPS/eip-3541) and the follwing 2 bytes is the 7702 designator. ### Opcode changes @@ -71,23 +67,23 @@ While `CODESIZE` and `CODECOPY` operate on executable code means that they are n Contrary some reading and execution instructions are impacted, including: - [EXTCODESIZE](https://www.evm.codes/?fork=cancun#3b) returns 2 bytes - [EXTCODEHASH](https://www.evm.codes/?fork=cancun#3f) is the `keccak256` hash of `0xef01` - - [EXTCODECOPY](https://www.evm.codes/?fork=cancun#3f) returns `0xef01` + - [EXTCODECOPY](https://www.evm.codes/?fork=cancun#3c) returns `0xef01` - Exeuction instructions (`CALL`, `CALLCODE`, `STATICCALL`, `DELEGATEACLL`) execute the code from the delegated code address in the context of the EOA +### Gas costs + +Each authorization tuple costs 25000 gas, which is calculated by the following formula: `21000 + 16 * non-zero calldata bytes + 4 * zero calldata bytes + 1900 * access list storage key count + 2400 * access list address count`. +This charges maximum gas upfront and a partial refund of 12500 gas is issued if the contract already exists, which happens through a global refund mechanism. +The delegated addressed are marked as warm address according to [EIP-2929](https://eips.ethereum.org/EIPS/eip-2929). + ### Wallet and UX Changes -proxy-contract, a proxy account potentially has multiple "linked" EOAs +[EIP-7821](https://eips.ethereum.org/EIPS/eip-7821) is a proposal to create a batch executor interface for delegations. The intention of such a proxy contract is that an EIP-7702 transaction delegates to this contract, which points to the wallet implementation of the user. When a user wants to upgrade their wallet they can simple chane the proxy pointer and they don't have to sing another EIP-7702 transaction. A bundler submits the authorization inside the setcode tx onchain Next you have to call "yourself" to init the code. The init data is signed and can been anything e.g. owner, a session key, some delegation, etc. A lot of 4337's components can and should be reused for 7702 e.g. bundler -### Gas costs - -25000 gas/authorization or 12.5k if account already exists -global refund mechanism applies -destination warming - ## Resources - [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) From 58773610ef1ec84941a61efd4b7da88e9d256923 Mon Sep 17 00:00:00 2001 From: Peter Date: Thu, 24 Apr 2025 09:11:55 +0300 Subject: [PATCH 7/9] chore: cleanup wallet section --- docs/wiki/research/account-abstraction/eip-7702.md | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/docs/wiki/research/account-abstraction/eip-7702.md b/docs/wiki/research/account-abstraction/eip-7702.md index 090fcf40..5d68f848 100644 --- a/docs/wiki/research/account-abstraction/eip-7702.md +++ b/docs/wiki/research/account-abstraction/eip-7702.md @@ -78,11 +78,8 @@ The delegated addressed are marked as warm address according to [EIP-2929](https ### Wallet and UX Changes -[EIP-7821](https://eips.ethereum.org/EIPS/eip-7821) is a proposal to create a batch executor interface for delegations. -The intention of such a proxy contract is that an EIP-7702 transaction delegates to this contract, which points to the wallet implementation of the user. When a user wants to upgrade their wallet they can simple chane the proxy pointer and they don't have to sing another EIP-7702 transaction. -A bundler submits the authorization inside the setcode tx onchain -Next you have to call "yourself" to init the code. The init data is signed and can been anything e.g. owner, a session key, some delegation, etc. -A lot of 4337's components can and should be reused for 7702 e.g. bundler +[EIP-7821](https://eips.ethereum.org/EIPS/eip-7821) is a proposal to create a batch executor interface for delegations with the aim to reduce the number of delegations given the risks and high gas costs associated with it. +A [proposed proxy pattern](https://gist.github.com/lightclient/7742e84fde4962f32928c6177eda7523) by @lightclient is a minimal contract that EOA can delegate to, which in turn points to the wallet implementation of the user. When a user wants to upgrade their wallet they can simply make change the in the proxy contract and they don't have to sing another EIP-7702 transaction. ## Resources From 8120ce9eaaa8ec1be1f4855ed308d9244d71915c Mon Sep 17 00:00:00 2001 From: Peter Date: Sun, 27 Apr 2025 20:52:35 +0300 Subject: [PATCH 8/9] feat: rewrite + minor cleanups --- .../research/account-abstraction/eip-7702.md | 88 ++++++++----------- 1 file changed, 38 insertions(+), 50 deletions(-) diff --git a/docs/wiki/research/account-abstraction/eip-7702.md b/docs/wiki/research/account-abstraction/eip-7702.md index 5d68f848..663addad 100644 --- a/docs/wiki/research/account-abstraction/eip-7702.md +++ b/docs/wiki/research/account-abstraction/eip-7702.md @@ -14,72 +14,60 @@ Review `@lightclient's` technical deep dive: -## Rationale +Although ERC-4337 introduces account abstraction, EIP-7702 serves a different purpose by providing externally owned accounts (EOAs) with temporary programmability. The benefits of introducing programmability to externally owned accounts (EOAs) include transaction batching, transaction sponsorship, privilege de-escalation and session keys, and social recovery. -It is also precedeed by ERC-4337, the account abstraction standard. -Given the existence of ERC-4337 you might ask why is EIP-7702 required. The account abstraction has an entirely different goal while this proposal's main goal is to give EOAs some temporary programmability. - -The benefits include of programmability are the following: -- Transaction batching -- Transaction Sponsorship -- Privilege de-escalation and Session keys -- Social Recovery -- And the list is endless... - -Historically EIP-7702 is a simpler alternative to the proposed EIP-3074 which would've added AUTH and AUTHCALL opcodes. -The main reason for this limited EOA is to push users towards Smart Wallets as describe in [ERC-4337](https://eips.ethereum.org/EIPS/eip-4337) and create a unified interface from the dApp perspective. -7702 is a step towards native Account Abstraction and is fully compatible with Account Abstraction, meaning you can delegate via 7702 to a Smart Wallet. +Historically, EIP-7702 was introduced as a simpler alternative to the proposed EIP-3074, which would have added two new EVM instructions, AUTH and AUTHCALL. The primary motivation behind this "limited" proposal is to encourage users to transition towards Smart Wallets, as described in [ERC-4337](https://eips.ethereum.org/EIPS/eip-4337), and to create a unified interface from the dApp perspective. EIP-7702 represents a step toward native Account Abstraction and is fully compatible with existing Account Abstraction infrastructure, allowing components such as paymasters and bundlers to work seamlessly. ## Technical Details -In the ethereum account model the difference between contract accounts and externally owned accounts is that EOAs do not have code that can be executed onchain, practically the code field is set to null. -This proposal adds a new [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) compatible transaction call to set code field for an EOA temporarily. -The `TransactionType` type is called `SET_CODE_TX_TYPE` with value=4. -The `TransactionPayload` object defined as a RLP serialized tuple with the following fields: -`chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s`. -The authorization list is defined as non-empty list of `chain_id, address, nonce, y_parity, r, s` tuples, where the `address` refers to the delegated code's address, the `chain_id` can be set to a valid chain's id or to 0 and the `nonce` has to equal to the EOA for replay protection. -`y_parity, r, s` is the signature of the EOA. -This list can be submitted by anyone meaning the `tx.origin` doesn't have to be the EOA owner as long as it contains a valid signature. Setting the chain id to zero allows the resubmission of the transaction on any chain, given that the nonce values match. -The `ReceiptPayload` is defined as the `status, cumulative_transaction_gas_used, logs_bloom, logs` tuple in RLP seralized form. - -You can learn more about RLP encoding in [this section](https://epf.wiki/#/wiki/EL/RLP). - -When such a set code transaction is submitted the following basic steps happen for each tuple in the `authorization_list`. -1. Alongside basic validation(e.g. auth.chain_id < 2^256, auth.nonce < 2^64, etc.) the chain id is verified that it is either 0 or the current chain's id. -2. Then the address of the authority is recovered from the signature and the payload. -3. The code of the authority is either set to `0xef0100 || address` if the `address` is not `0x0000000000000000000000000000000000000000`, otherwise the EOA's code is cleared and is set to the hash of an empty address (`0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470`). This acts as a revocation mechanism -4. The delegation address is marked as warm address. - -For each authorization tuple the nonce of the EOA is increased by 1, meaning every tuple has to calculate their nonce value based on their position in the list. -This simplified execution steps skipped important steps, a more detailed execution can be found at the [Behavior section](https://eips.ethereum.org/EIPS/eip-7702#behavior) of the EIP. - +In the Ethereum account model, the primary difference between contract accounts and externally owned accounts (EOAs) is that EOAs do not contain executable on-chain code; their code field is effectively set to null. +EIP-7702 proposes adding a new [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718)-compatible transaction type that allows temporarily setting the code field for an EOA. +The new `TransactionType` is defined as `SET_CODE_TX_TYPE` (`0x04`). +The associated `TransactionPayload` is an RLP-serialized tuple containing the following fields: +`chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s`, where the authorization must be a non-empty list of `chain_id, address, nonce, y_parity, r, s` tuples. +Here, the `address` refers to the address of the delegated contract code, and `chain_id` may be either a valid chain ID or 0, the `nonce` must match the EOA's nonce to provide replay protection and the `y_parity`, `r`, and `s` values are the ECDSA signature components signed by the `authority`. +Anyone can submit a transaction containing a valid authorization list — meaning the `tx.origin` does not have to be the EOA’s address, as long as the signature is valid. Setting the `chain_id` to `0` enables resubmission of the transaction across different chains, provided the nonce values match. +The `ReceiptPayload` is defined as the `status, cumulative_transaction_gas_used, logs_bloom, logs` tuple in RLP-seralized form. +More information about RLP encoding can be found in [this section](https://epf.wiki/#/wiki/EL/RLP). + +When such a transaction is submitted the following steps are performed for each tuple in the `authorization_list`: +1. Basic validations are performed, such as verifying `chain_id < 2^256`, `len(auth.address) == 20` etc.. Additionally, the `chain_id` must either match the current chain's ID or be set to `0`. +2. Verify that the `nonce` is less than `2^64 - 1`. +3. The `authority` is recovered from the signature and the payload using the `ecrecover` method: +`authority = ecrecover(msg, y_parity, r, s).` where `msg = keccak(MAGIC || rlp([chain_id, address, nonce]))` and `s` must be less than `secp256k1n/2`. +4. The recovered `authority` is marked as a warm address and is added to the `accessed_addresses` set. +5. Verify that `nonce` is equal to nonce of `authority` if the `authority` exists in the trie otherwise `nonce` has to equal `0`. +6. If `authority` exists in the trie the refund amount of `PER_EMPTY_ACCOUNT_COST - PER_AUTH_BASE_COST` is added to the global refund mechanism. +7. In case of a non-zero `address` the code of the authority is set to `0xef0100 || address` (where `||` denotes concatenation), otherwise the EOA's code is cleared and the code hash is set to the hash of a null address (`0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470`). This serves as a revocation mechanism. +8. The nonce of `authority` is incremented by one. ### Creation by template -Due to space optimization the traditional `initCode` is replaced by a "code pointer" and the initialization happens during a regular call. +Due to space optimization concerns, the traditional `initCode` is replaced by a "code pointer" mechanism, with initialization occuring during a regular call. [EIP-3607](https://eips.ethereum.org/EIPS/eip-3607) specifies that an account with deployed code cannot originate transactions. -To work around this the `code` field gets populated with the address of the delegated contract and a prefix which is 23 bytes in total. -The prefix is 3 bytes and the first byte(`ef`) is a banned opcode specified in [EIP-3541](https://eips.ethereum.org/EIPS/eip-3541) and the follwing 2 bytes is the 7702 designator. +To work around this the `code` field is populated with a 23-byte value composed of a prefix and the delegated contract’s address. +The prefix is 3 bytes long: + - The first byte (`0xef`) is a banned opcode, as defined in [EIP-3541](https://eips.ethereum.org/EIPS/eip-3541). + - The following two bytes (`0x0100`) act as a 7702-specific designator. ### Opcode changes -While `CODESIZE` and `CODECOPY` operate on executable code means that they are not impacted. -Contrary some reading and execution instructions are impacted, including: - - [EXTCODESIZE](https://www.evm.codes/?fork=cancun#3b) returns 2 bytes - - [EXTCODEHASH](https://www.evm.codes/?fork=cancun#3f) is the `keccak256` hash of `0xef01` - - [EXTCODECOPY](https://www.evm.codes/?fork=cancun#3c) returns `0xef01` - - Exeuction instructions (`CALL`, `CALLCODE`, `STATICCALL`, `DELEGATEACLL`) execute the code from the delegated code address in the context of the EOA +Some reading and execution instructions are impacted by this design, including: + - [EXTCODESIZE](https://www.evm.codes/?fork=cancun#3b) will return 2, the length of `0xef01` + - [EXTCODEHASH](https://www.evm.codes/?fork=cancun#3f) will return `keccak256` hash of `0xef01` + - [EXTCODECOPY](https://www.evm.codes/?fork=cancun#3c) will return the bytes `0xef01` + - Exeuction instructions (`CALL`, `CALLCODE`, `STATICCALL`, `DELEGATEACLL`) will execute the code from the delegated contract address, but within the context of the EOA ### Gas costs -Each authorization tuple costs 25000 gas, which is calculated by the following formula: `21000 + 16 * non-zero calldata bytes + 4 * zero calldata bytes + 1900 * access list storage key count + 2400 * access list address count`. -This charges maximum gas upfront and a partial refund of 12500 gas is issued if the contract already exists, which happens through a global refund mechanism. -The delegated addressed are marked as warm address according to [EIP-2929](https://eips.ethereum.org/EIPS/eip-2929). +Each authorization tuple incurs a gas cost of 25,000 gas, calculated using the following formula: +```21000 + 16 * non-zero calldata bytes + 4 * zero calldata bytes + 1900 * access list storage key count + 2400 * access list address count``` +This approach charges the maximum gas amount upfront. A partial refund of 12,500 gas is issued if the contract already exists, which happens through the global refund mechanism. ### Wallet and UX Changes -[EIP-7821](https://eips.ethereum.org/EIPS/eip-7821) is a proposal to create a batch executor interface for delegations with the aim to reduce the number of delegations given the risks and high gas costs associated with it. -A [proposed proxy pattern](https://gist.github.com/lightclient/7742e84fde4962f32928c6177eda7523) by @lightclient is a minimal contract that EOA can delegate to, which in turn points to the wallet implementation of the user. When a user wants to upgrade their wallet they can simply make change the in the proxy contract and they don't have to sing another EIP-7702 transaction. +[EIP-7821](https://eips.ethereum.org/EIPS/eip-7821) proposes the creation of a batch executor interface for delegations, aiming to reduce the number of delegations required due to the associated risks and high gas costs. +A [proposed proxy pattern](https://gist.github.com/lightclient/7742e84fde4962f32928c6177eda7523) offers a minimal contract that EOAs can delegate to. This proxy contract then points to the user's wallet implementation. With this setup, when a user wants to upgrade their wallet, they can simply modify the proxy contract without the need to sign a costly EIP-7702 transaction. ## Resources @@ -90,5 +78,5 @@ A [proposed proxy pattern](https://gist.github.com/lightclient/7742e84fde4962f32 - [EIP-7702: A Deep Dive](https://hackmd.io/@colinlyguo/SyAZWMmr1x) - [Recommended Proxy Pattern](https://gist.github.com/lightclient/7742e84fde4962f32928c6177eda7523) - [Awesome EIP-7702](https://github.com/fireblocks-labs/awesome-eip-7702) -- [Great talk about wallet, security, use cases, etc.](https://www.youtube.com/watch?v=TUNtZ5jzXAk) +- [7702 Best Practices](https://hackmd.io/@rimeissner/eip7702-best-practices) From 49c2259c59a91f3e84c9c9101711003b1f29baa9 Mon Sep 17 00:00:00 2001 From: Peter Date: Sun, 27 Apr 2025 20:55:05 +0300 Subject: [PATCH 9/9] fix: typos --- docs/wiki/research/account-abstraction/eip-7702.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/wiki/research/account-abstraction/eip-7702.md b/docs/wiki/research/account-abstraction/eip-7702.md index 663addad..8bcc8d6a 100644 --- a/docs/wiki/research/account-abstraction/eip-7702.md +++ b/docs/wiki/research/account-abstraction/eip-7702.md @@ -43,7 +43,7 @@ When such a transaction is submitted the following steps are performed for each ### Creation by template -Due to space optimization concerns, the traditional `initCode` is replaced by a "code pointer" mechanism, with initialization occuring during a regular call. +Due to space optimization concerns, the traditional `initCode` is replaced by a "code pointer" mechanism, with initialization occurs during a regular call. [EIP-3607](https://eips.ethereum.org/EIPS/eip-3607) specifies that an account with deployed code cannot originate transactions. To work around this the `code` field is populated with a 23-byte value composed of a prefix and the delegated contract’s address. The prefix is 3 bytes long: @@ -56,7 +56,7 @@ Some reading and execution instructions are impacted by this design, including: - [EXTCODESIZE](https://www.evm.codes/?fork=cancun#3b) will return 2, the length of `0xef01` - [EXTCODEHASH](https://www.evm.codes/?fork=cancun#3f) will return `keccak256` hash of `0xef01` - [EXTCODECOPY](https://www.evm.codes/?fork=cancun#3c) will return the bytes `0xef01` - - Exeuction instructions (`CALL`, `CALLCODE`, `STATICCALL`, `DELEGATEACLL`) will execute the code from the delegated contract address, but within the context of the EOA + - Execution instructions (`CALL`, `CALLCODE`, `STATICCALL`, `DELEGATEACLL`) will execute the code from the delegated contract address, but within the context of the EOA ### Gas costs