From 252cd9d19d0e2f2add35985db61d48ee5101d761 Mon Sep 17 00:00:00 2001 From: Alex Forshtat Date: Sun, 5 May 2024 21:37:11 +0200 Subject: [PATCH] Add EIP: Native Account Abstraction with EOF Merged by EIP-Bot. --- EIPS/eip-7701.md | 213 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 213 insertions(+) create mode 100644 EIPS/eip-7701.md diff --git a/EIPS/eip-7701.md b/EIPS/eip-7701.md new file mode 100644 index 0000000000000..5ea95cd60374c --- /dev/null +++ b/EIPS/eip-7701.md @@ -0,0 +1,213 @@ +--- +eip: 7701 +title: Native Account Abstraction with EOF +description: A variant of RIP-7560 transactions relying on EOF Smart Contract Accounts +author: Vitalik Buterin (@vbuterin), Yoav Weiss (@yoavw), Alex Forshtat (@forshtat), Dror Tirosh (@drortirosh), Shahaf Nacson (@shahafn) +discussions-to: https://ethereum-magicians.org/t/eip-7701-native-account-abstraction-with-eof/19893 +status: Draft +type: Standards Track +category: Core +created: 2024-05-01 +requires: 3540 +--- + +## Abstract + +This proposal describes a slight variation of the Native Account Abstraction design fully described in RIP-7560. +This version's difference compared to the original proposal is in relying on features of "EVM Object Format" to +distinguish between validation and execution code sections. + +## Motivation + +Talking about Full Native Account Abstraction, the fundamental idea any solution has to address is a +mechanism for a Smart Contract Account to separate its validation and execution code sections. + +RIP-7560 is build on the current Ethereum contract structure, and therefore has little choice but to rely +on using some higher-level abstraction. + +In its current form, RIP-7560 transactions use Solidity method selectors in order to achieve this separation. + +This, however, is far from ideal as this approach "leaks" the concept from a programming language widely used +in the EVM into the core design of the Ethereum protocol. + +While there is no purely technical reason to disallow it and there are already instances of Solidity code +being "enshrined" in the Ethereum protocol, e.g. the validator deposit contract, such violation of abstraction levels +often lead to unnecessary technical debt and are worth avoiding if possible. + +Additionally, method selectors provide very weak indication of the contract developer's decision to become a +participant in Native Account Abstraction transaction flow. +The chance of accidentally exposing a function with a colliding 4 byte +method identifier that returns a valid 4 byte magic to indicate approval is pretty low, but a malicious developer +can easily hide such a function giving it an innocent name, making it hard to spot a Native Account Abstraction entity. + +This issue to some extent is also present in [ERC-4337](./eip-4337.md). + +As an alternative, if Native Account Abstraction is to be implemented in coordination with [EIP-3540](./eip-3540), +relying on the concept of "code sections" it introduces is a superior approach. + +## Specification + +### System-level code entry points + +Modify the EOF container format to consist of the following sections: + +``` +container := header, body +header := + magic, version, + kind_types, types_size, + kind_entrypoints, entrypoints_size, + kind_code, num_code_sections, code_size+, + [kind_container, num_container_sections, container_size+,] + kind_data, data_size, + terminator +body := types_section, entrypoints_section, code_section+, container_section*, data_section +types_section := (inputs, outputs, max_stack_height)+ +entrypoints_section := (entrypoints_role, target_section_index, target_section_pc_offset)+ +``` + +For regular calls to the contract, the execution always starts at the first byte of code section 0, and pc is set to 0. + +Here the `entrypoints_section` defines alternative indexes of code sections to start the execution for system calls. +This is reserved for execution of special roles in the `entrypoints_role` range. + +Note: do not confuse code execution `entrypoint` with the `EntryPoint` contract defined in ERC-4337. + +### Validation and PostTransaction code entry points + +The contract that may have a role in an Account Abstraction transaction, either as a Sender, a Paymaster or a Deployer, +has to contain a section marked with one of the following `entrypoints_role` marker: + +``` +role_sender_execution = 0x0000 +role_sender_deployment = 0x0001 +role_sender_validation = 0x0002 +role_paymaster_validation = 0x0003 +role_paymaster_posttx = 0x0004 +``` + +This section is equivalent to a code section. + +Its code can be executed during a regular transaction execution and has no special effects. +If it is the first code section of a contract, it can act as an entry point during regular transaction execution. + +Only a single section per role is allowed in a contract. +This rule is validated during contract creation. + +### Execution entry point for Account Abstraction transaction type participant entity (Sender, Paymaster and Deployer) + +During a regular contract code execution, its behaviour is defined as follows by EIP-3540: + +``` +Execution starts at the first byte of code section 0, and pc is set to 0 +``` + +However, if a contract is referenced in an `AA_TX_TYPE` transaction as a Sender, Paymaster or a Deployer, +execution starts at the first byte of code section with the `entrypoints_role` marker corresponding to the current step, +and `pc` is set to the corresponding `target_section_pc_offset`. + +If the specified contract does not contain such a section, or is not an EOF contract, the transaction is not valid. + +### Encoding inputs for different execution frames + +#### Sender Deployment + +Inputs to the `deployer` contract are not defined by the protocol and are controlled by the `deployerData` parameter. + +The sender deployment frame MUST result in the `sender` address becoming initialized with contract code. + +This step is performed with the `role_sender_validation` code section. + +#### Sender Validation + +Inputs to the `Sender` validation section are defined by the protocol as an SSZ encoding of the transaction data, +excluding the `chainId` and `accessList` fields and with an extra field of the `txHash`: + +``` +ssz([ + subtype, + sender, nonce, builderFee, + callData, + paymaster, paymasterData, + deployer, deployerData, + maxPriorityFeePerGas, maxFeePerGas, + validationGasLimit, paymasterValidationGasLimit, + callGasLimit, paymasterPostOpGasLimit + signature, txHash +] +``` + +This step is performed with the `role_sender_deployment` code section. + +In order for the transaction to be considered valid the +sender validation frame MUST return two 64-bit values: + +``` +ssz(bool success, uint64 validUntil, uint64 validAfter) +``` + +#### Paymaster Validation + +Inputs to the `Paymaster` validation section are same as the ones in the [Sender Validation](#sender-validation) step. + +This step is performed with the `role_paymaster_validation` code section. + +In order for the transaction to be considered valid the +paymaster validation frame MUST return the following values: + +``` +ssz(uint64 validUntil, uint64 validAfter, bytes context) +``` + +#### Sender Execution + +This step is performed with the `role_sender_execution` code section. + +Inputs to the `Sender` contract are not defined by the protocol and are controlled by the `callData` parameter. + +#### Paymaster post-transaction frame + +Inputs to the `Paymaster` post-transaction are defined by the protocol as an SSZ encoding of the following data: + +``` +ssz([uint256 actualGasCost, bool success, bytes context]) +``` + +This step is performed with the `role_paymaster_posttx` code section. + +## Rationale + +### SSZ encoding for system frames' input and output data + +Using an SSZ encoding format for data provided by the protocol itself does represent an abstraction levels violation, +however it is a relatively safe and any alternative solution would require some trade-offs. + +The validation section of a Smart Contract Account code needs to have full access to the majority of transaction +details in order to be able to make an informed decision about either accepting or rejecting the transaction. + +A small subset of this data is available with the existing opcodes, however creating an opcode for every transaction +parameter is not feasible. + +Allowing wallets to specify their own encoding for this data is also not feasible as Smart Contract Accounts must +avoid any ambiguity about the meaning of the received data. + +## Backwards Compatibility + +An EOF contract with `kind_entrypoints` section is not valid according to EIP-3540 and cannot exist on-chain +before this proposal is implemented. + +The introduction of `kind_entrypoints` will break an assumption that a contract code can only have a single +execution starting point, which might confuse some developer tooling that relies on this assumption. + +## Security Considerations + +A contract with a `kind_entrypoints` section explicitly indicates its role as a Native Account Abstraction entity. +This is a significant improvement over ERC-4337 and RIP-7560 where entities are not explicitly marked. + +As the `kind_entrypoints` code sections represent a generic way to authorize any action on behalf of the contract, +correct and secure implementation of this code is critical. +We expect compilers targeting EVM will play a major role in enabling and ensuring Smart Contract Accounts' security. + +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE.md).