-
-
Published
Linked with GitHub
# Account Abstraction with EVM Object Format
This is a modified version of [EIP-2938](https://eips.ethereum.org/EIPS/eip-2938) utilising the [EVM Object Format](https://notes.ethereum.org/@ipsilon/evm-object-format-overview). We only list the differences compared to EIP-2938.
*TODO: Check if this needs to be updated after EIP-1559*
## Verifier section
We introduce a new EOF section, `section_kind = 3`, called `verifier`.
This section starts with a 32-bit big-endian encoded integer, the `gas_limit`. After this, the section is treated like the `code` section (in regards to rules for execution, such as `PC`, `JUMP`, etc.).
Example: `00015f90 00` (`verifier.gas_limit = 90000`, `verifier.code = "stop"`)
Note that an account can have both a `verifier` and `code` section.
## Regular transactions / calls
Regular contract calls and transactions will start execution at the `code` section, just as they do with any regular contract.
## AA transactions
From EIP-2938:
> A new EIP-2718 transaction with type AA_TX_TYPE is introduced. Transactions of this type are referred to as “AA transactions”. Their payload should be interpreted as rlp([nonce, target, data]).
>
> The base gas cost of this transaction is set to AA_BASE_GAS_COST instead of 21000 to reflect the lack of “intrinsic” ECDSA and signature.
>
> Nonces are processed analogously to existing transactions (check tx.nonce == tx.target.nonce, transaction is invalid if this fails, otherwise proceed and immediately set tx.nonce += 1).
If the account is executed via the `AA_TX_TYPE`, then the `verifier` section is loaded:
1. The `verifier.gas_limit` is set as the gas limit for the verifier.
2. The `verifier.code` is executed.
The `PAYGAS` opcode takes the arguments from the stack (as opposed to memory): `gas_price_cap` and `gas_limit`. The opcode is only valid to be called within the verifier section. Failure cases are the same as in EIP-2938.
Option 1: Finally (after having used `PAYGAS`) the verifier can use a regular `CALL` to execute the account's code.
Option 2: A new opcode is introduced to start executing the regular `code` section.
## Example
This is a psuedo text encoding of an EOF-formatted bytecode, where the statements use Yul-syntax:
```json
{
header: {},
verifier_code:
"
// Assume the inputs are: [price, limit, nonce, payload, signature]
let price = calldataload(0)
let limit = calldataload(1)
// TODO: do signature verification and nonce check 😅
paygas(price, limit)
// Load payload
let payload_size = sub(calldatasize(), 160)
calldatacopy(0, 96, payload_size)
call(limit, address(), callvalue(), 0, payload_size, 0, 0)
",
code:
"
// My regular contract
"
}
```
Benefits:
1. No need to have an `AA_PREFIX` for `if(msg.sender != shr(-1, 12)) { LOG1(msg.sender, msg.value); return }`, as the verifier code can not be executed via regular calls.
2. The verifier gas limit must be advertised by the account. Miners can decide easily whether they take the risk or not.
3. Simplified rules for `PAYGAS` and checkpointing.
Risk:
1. The `verifier.gas_limit` could pose a problem if costs rise too much.