Compilation of the original text: The Way of DeFi

Compilation of the original text: The Way of DeFi

The account abstraction allows us to use smart contract logic to specify the effects of transactions, as well as fee payment and validation logic. This brings a number of important security benefits, such as multi-signature and smart recovery wallets, the ability to change keys without changing wallets, and quantum security.

Many approaches to account abstraction have been proposed and implemented to varying degrees, see: EIP-86, EIP-2938, and this paper from two years ago. Today, the development of these EIPs has stalled as developers want to focus on merging and sharding, while ERC-4337, an alternative that does not require any consensus changes, has made great progress.

ERC-4337 tries to achieve the same thing as EIP-2938 through additional protocol means. Users need to send off-chain messages called user operations, which are collected in batches by block proposers or builders who generate bundles for block proposers and packaged into a single transaction. Proposers or builders are responsible for filtering operations to ensure they only accept operations that pay a fee. There is a separate mempool for user actions, and nodes connecting to this pool do ERC-4337-specific validation to ensure user actions are paid before they are forwarded.

ERC-4337 can do many things as a purely voluntary ERC. However, it is weaker than true in-protocol solutions in a few key areas:

1. Existing users cannot upgrade without moving all their assets and activities to the new account;

2. Additional gas overhead(A basic UserOperation user operation is about 42k, while a basic transaction is about 21k);

3. Less benefit from in-protocol censorship-resistant techniques (e.g. crLists), which target transactions and miss user operations

A realistic path to achieve the best results is to start with strong support for ERC-4337 in the short term, and then add EIPs over time to compensate for its weaknesses.This does not necessarily require everyone to specifically commit to complying with ERC-4337. Instead, in-protocol support can be designed to be more general and support ERC-4337 and its alternatives and improvements.

secondary title

Convert EOA Wallet to Smart Contract Wallet

In order to upgrade existing EOA wallets to ERC-4337 wallets, we can make an EIP that allows EOA to perform operations that set its contract code. Once EOA has achieved this, the transition is irreversible. From then on, the account will only be used as a smart contract wallet. Fortunately, since ERC-4337 accounts are DELEGATECALL proxies, the wallet can later be converted to other ERC-compatible smart contracts if desired.

There are some proposals on how to implement this upgrade process:

1. "replace code" transaction type

This hasn't been introduced as an official EIP yet, but the method is simple: add a new EIP-2718 transaction type, just replace account_code with calldata.

2、AUTH_USURP (EIP-5003)

EIP-5003 is an extension proposal to EIP-3074 (AUTH and AUTHCALL), which introduces a new AUTHUSURP opcode. AUTHUSURP allows B to set A's code if, using the EIP-3074 mechanism, EOA address A has authorized another address B to act on its behalf.

secondary title

forced conversion

In the longer term, we may want to do a mandatory conversion to simplify the protocol and make contracts the only account type, removing ECDSA from the protocol.One possible approach is to add an override rule whereby starting from a certain block, accounts without a code are treated as accounts with a specific standardized "ERC-4337 EOA wallet" code.

question

question

1. In-contract ECRECOVER verification:Some smart contracts rely on the assumption that if you provide a signature of ECRECOVER to a particular account, you own that account. If an EOA is converted into a contract, and then its verification key is changed, the original key will still be able to "represent" the account in these specific contexts. This can be done by starting to encourage all such projects to change to using EIP-1271 verification instead of ECRECOVER if the account has a code.

2. Accounts not yet detected:One challenge with forced conversions is accounts that own assets (such as ERC20s, ERC721s, but not ETH) but have not sent or received any transactions, so the protocol cannot reliably detect these accounts. The protocol must either retain the ability to permanently convert such accounts to the default wallet, or there needs to be a deadline (eg 4 years after deployment) after which accounts that have not been converted will be burned.

3. EOA only checks for non-transferability:secondary title

Reduce gas cost

4. One-time contract creation cost (about 32,000 gas, plus 200 gas for each code byte in the proxy, plus 20,000 gas for setting the proxy address)

1. You need to pay a lot of individual storage read/write costs. In the case of EOA, these costs will be bundled into a single payment of 21000 gas:

(1) Edit the storage slot containing pubkey+nonce (~5000);

(2) User operation call data cost (about 4500, which can be reduced to about 2500 through compression);

（3）ECRECOVER (~3000)；

(4) First access to the wallet itself (~2600)

(5) Access to the payee account for the first time (~2600)

(6) Transfer ETH to the beneficiary's account (~9000)

(7) Edit Storage to Pay Fee (~5000)

(8) Access the storage slot containing the agent (~2100), then access the agent itself (~2600);

2. In addition to the above storage read/write costs, the contract also needs to execute "business logic" (unpack UserOperation, hash it, shuffle variables, etc.)

3. Need to consume gas to pay the log fee (EOA does not publish logs);

4. One-time contract creation cost (about 32,000 gas, plus 200 gas for each code byte in the proxy, plus 20,000 gas for setting the proxy address)

Many of these issues will be automatically resolved in the Verkle tree witness gas cost EIP and write gas cost reform EIP, replacing large storage costs with a leaner system. For example, pubkeys and nonces can be stored in slots 0…63, which reduces the cost of accessing them to under 1000. Users will pay less when transferring ETH and paying fees, because the target and receiving accounts only need to be accessed once for the first time.

There are more EIPs that help us simplify. For example:

1. Disabling smart contract logic from using slot 0's voluntary ERC would allow it to be used for storage proxies, allowing it to benefit from cheaper gas costs.

2. The "code address" field can make proxying easier and consume less gas.

3. "snappy compression" precompilation makes it easier to use ABI objects without paying the calldata gas cost for all zero bytes.

secondary title

crLists

This is a long-term problem, because crLists are only really applicable when a full protocol proposer/builder separation scheme is enabled. The challenge is that we want proposers to be able to identify user actions that are "worthy" of inclusion (i.e. they pay enough fees) so that the protocol can force them to be included in the next block that has room.

This requires that the concepts of "validation" and "execution" be made explicit in the protocol. For user actions, there must be a defined way to validate the action, and a defined way to perform the action, such that if an action is validated, attempts to perform the action will be guaranteed to pay unless The read state is modified during validation. These operations can be implemented by embedding ABI methods, or by adding a dedicated EOF section if the EOF EIP is implemented.

Fortunately, this doesn't require us to treat ERC-4337 as a final standard, but instead incorporates a weaker concept supported by ERC-4337 that can be easily supported by other largely different ERCs.

The reason is that the complexities of ERC-4337 and EIP-2938 are largely related to solving the problem of stronger DoS resistance: it is not possible to make one operation cancel hundreds of other operations, as this would allow cheap garbage of the mempool Transactional attack. This requires imposing restrictions on what account verification can access. Here, we can do something simpler: just log which state objects were touched during validation, and don't need to include if any of those state objects were edited.

This allows individual accounts to choose their own tradeoff between censorship resistance and flexibility. In extreme cases, accounts can pay fees during verification via Uniswap if they wish, but since anyone can send transactions that affect the state of Uniswap, such accounts have effectively no censorship-resistant guarantees.

The general outline of the crList design is as follows:

1. A proposal can contain a crList that specifies a list of operations to include, and a list of state object (key, value) pairs that each operation reads. A builder (or anyone else) that accepts a crList must check that all operations pass the validate check.

2. The block is required to execute every operation in the crList unless the block does not have enough gas left, or the current state at the time of execution has edited one of the state objects read by the operation.

The remaining complexity of ERC-4337 will only be used for mempool security. In principle, there could be multiple competing ERCs that achieve this goal in different ways, as long as they all adhere to the same verification and enforcement standards.

secondary title

short term

short term

1. Put ERC-4337 into full production. Ideally, this could be extended with signature aggregation functionality for rollup friendliness.

2. There should be an easy-to-use browser wallet that interfaces with ERC-4337.

3. Consider implementing signature aggregation and compression to make ERC-4337 more L2-friendly;

4. mid term

mid term

1. Implement Verkle tree, add EIP to reduce gas cost;

2. Add optional EOA-to-ERC-4337 conversion;

3. long

long

1. secondary title

possible alternatives

1. Consider writing an EIP that includes ERC-4337 equivalent accounts and transactions at the protocol layer and drive its adoption in L2;

2. Eliminate the need for user actions to be readable to the Ethereum protocol using a censorship-resistant solution that works through axuliary blocks;