EIP-7702

Overview

The EIP-7702 introduces the change of the ethereum's EOA operation. It allows for the EOA to act like a CA, with the actual storage and code on it. With this update, user can freely give the EOA a fuction and call it like a CA, but only in the user's TX itself. It is made to support the AA wallet(SCW) to use the same address of the owner's EOA address, which results to fully acheive the "CA wallet".

The basic format of the newly introduced TX type

The EIP-7702 is the update which adds the TX type to the Ethereum core. During this transaction, the EOA gets a contract code, which is called as a EOA account code. The TransactionType of the new TX is specified as 0x04, and the TransactionPayload's RLP serialization format is like this:

rlp([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])
authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]

chain_id: The chain Id of the chain. nonce: The contract's nonce max_priority_fee_per_gas, max_fee_per_gas: values for the gas calculation. check the EIP-1559 gas_limit: The gas limit for the TX can spend destination: The address for the TX to integrate value: The ETH balance to send data: The calldata of the TX access_list: The list of addresses and storage keys that the transaction plans to access authorization_list: The list of code authorizations that will be executed in the context of EOA signature_y_parity, signature_r, signature_s: The sign of the TX.

You can see the access_list and the authorization_list. It is newly added in the new TX type:

access_list:

• List of account addresses and storage keys that the transaction will access

• Format: [[address, [storage_key1, storage_key2, ...]], ...]

• Pre-declare to optimize gas costs. If the TX access the storage specified above, the gas cost of the access would be diminished.

• Follows EIP-2930 structure

authorization_list:

• List of code authorizations that EOA will execute

• Format: [[chain_id, address, nonce, y_parity, r, s], ...]

• Each tuple contains authorization information for delegated contract code

• Requires at least one authorization

• Specifies code to be executed in EOA's context. It allows the EOA to call multiple times at one TX. (do you know the solidity dev framework 'foundry'? It is quite similar to the 'forge script')

CF) The original TX format is like this:

[nonce, gasPrice, gasLimit, to, value, data, v, r, s]

How does EOA gets an contract code?

The EIP-7702 does not only introduces new types of the TX, it also introduces the ability for a EOA to act as an CA(only for the TX runtime). The EOA now has a 'delegation designation', which is a pointer of an existing contract. If the 0x04 type TX are called, the user's EOA turns into a CA with a code of the delegation designation contract, and has it's own storage. The EOA's storage remains permanently if the user does not modifies it. (Yes, now the EOA has it's own storage)

Integration with the ERC-4337 and the Paymaster

The new types of the EOA's idea made the Account Abstraction more stable. Now users don't need to use the deployed account apart from the EOA, while integrating successfully with the ERC-4337, and also the ERC-6900. The user can simply use the EOA address as a deployed AA wallet, while changing the config values to the pointed delegation designation contract.(The logic contract that the EOA uses). If the owner of the contract is pointed by the user, the AA wallet rekt vulnerability would be very diminished. This means that the danger using the ERC-4337 would be decreased too.

But with this EIP changes, the pay for the gas fee is still an issue. The EIP-7702 con't solve the gas abstraction problem, so the paymaster is still needed for the gas payment by proxy. (as the same reason, the bundler and the SCW factory are still needed on order to use the Account abstrction.