ERC-4337 - From Zero To Hero

We know that there are two account models in Ethereum, EOA and CA, and ERC-4337 as an Account Abstraction Scheme (a standard for meta transactions) has recently been announced for official deployment by @Yoav (opens in a new tab).

EOA + CA

EOA, as a first-class citizen in the ecosystem, is the only entity that can trigger transactions, but CA, as a Turing-complete model, has more functional flexibility, such as multi-signature, multi-FA, and if we need to use these additional functions, we need to use EOA as a trigger to call a Smart Contract Wallet (aka. SCW). this is a simple AA model.

An SCW contract needs to implement the processing of an op sent by an EOA. execOp is a contract call, so for the UserOperation design we need to keep all the parameters in eth_sendTransaction.

But then we need to maintain two separate wallets of our own.

Introduce Executor

So how do we optimize this design? We can choose to bring in a third party to help execute all the ops so that as users we don't have to call execOp ourselves.

But there is an even more difficult problem with such a design. The Executor needs to ensure they are protected by the SCW's refund behavior, but how can they guarantee that the SCW will not misbehave?

A simple idea emerges, we can simulate an execOp operation prior to execution to determine if the SCW will honestly refund gas, this approach solves the problem at hand, but again raises other issues, firstly adding a simulation process will result in an increase in the cost of gas, and more critically we need to ensure that there is no difference between the simulation and the actual execution. This requires us to ensure that the state is consistent, which eliminates any operations that could lead to state changes. As a key part of the onboarding of the blockchain, we can’t accept a wallet that can't be a fully functional wallet if we put a lot of restrictions on operations and can't use fields with state, such as the blockNumber.

Introduce EntryPoint

We can ensure that the rights of the Executor are not compromised by introducing a trusted smart contract, EntryPoint, so that the refund process is handled by EntryPoint, which requires SCW to make a deposit in advance to ensure the success of the refund.

However, we need to consider the security of the SCW, as the EntryPoint will refund regardless of the success of the transaction, and a rogue executor can get a gas refund for the transaction by sending a lot of ops that will fail.

Decouple the validation and execution

Faced with such an attack, we can eliminate it by decoupling validation and execution, we only need to pay gas for valid transactions, so now in handleOp we will first call SCW's validateOp to ensure the validity of the op.

But for the Executor, his rights seem to be violated once again. If a bad user sends a lot of invalid ops, the executor cannot forward these ops after validating them, so he will not be reimbursed for the gas he paid for the on-chain exchange, so he needs to validate the ops as well to protect his rights.

Economics Incentives

We can also use the economic effect of EIP-1559 to provide some economic incentive to the Executor, which will increase the robustness of the whole network.

Introduce Bundler

We can generalize the executor into a bundler that handles a large number of ops. The design now becomes one where users send ops to a mempool and the bundler bundles these ops into a transaction based on economics.

Introduce Paymaster

The current design still requires the user themselves to pay for the gas with Ether, we can do this by introducing a Paymaster contract to pay for the gas, again we need to validatePaymasterOp to ensure it doesn't generate nefarious behavior.

This way our Refund process no longer needs to be done by our respective SCWs.

Introduce Paymaster Reputation System

However, since the Paymaster contract is a shared storage space, even a valid op can be invalidated by a previous doom op, so we can prevent some DoS attacks by introducing an on-chain reputation system, i.e. each paymaster must stake at EntryPoint.

We can add a stake using addStake, and if the paymaster wants to remove the stake, he must call unlockStake and wait a while before calling withdrawlStake to remove the stake.

Introduce postOp

We could also implement a postOp function to get the gas cost that the transaction would incur, which could help us implement more complex logic.

Deploy By Factory

So how do we do the contract deployment of the SCW? If we follow the normal method, then the EOA account is always the first-class citizen who controls the SCW, then we need to use the Factory contract while using the CREATE2 method can fix the contract address, even if we haven't done any transaction, we can tell others our SCW address, which is very much in line with our understanding of the EOA.

Introduce Aggregator

Finally, we can also introduce aggregators to reduce the cost of gas.

Outros

In this way, we have presented the overall design idea of the ERC-4337 and the final choice of solution. Of course, we will make a series of trade-offs in the final engineering implementation, but in general, the design idea will follow the above presentation.