Revolutionizing Blockchain with Account Abstraction: A Deep Dive into the Future of Crypto

Let's take a deep dive into the inner workings of Account Abstraction. Every discussion about Account Abstraction typically begins with the concepts of External Owner Accounts (EOAs) and Contract Accounts, but is this the best way to comprehend Account Abstraction? I beg to differ. I've invested considerable effort in simplifying the technical aspects to make it comprehensible for all. I hope this simplification helps.

So, in essence, with Account Abstraction, we're simplifying the complexity associated with EOAs for the user, particularly those who aren't well-versed in Web3 technology. Isn't that the primary objective? Indeed, it is. Here's the process we'll follow:

Firstly, there's no concept of a "transaction" for the user. A user simply wants to perform an action through a Web3 application. Let's call this action "UserOperation" or "UserOp."

Now, what information should this UserOp include to enable the user's action on the Blockchain? It should include the same parameters used in eth_sendTransaction(): target address, data (in bytes), the amount of Wei to send (if any), gas, the user's signature to authorize the action/transaction, and a nonce to prevent replay attacks.

But who will execute this action? It can't be the user themselves because they don't have an EOA.

So, what exactly does an EOA do to execute a user's transaction under the hood? It essentially has two roles: signing (authorizing) the transaction using the owner's private key and paying the gas fee.

This implies that there must be another entity involved, one that owns a separate EOA and can execute user transactions on the Blockchain network. This entity is called the Executor.

But why would this Executor send the user's transaction and cover the fee from its own resources? It won't. The Executor will be compensated for its services. After executing the transaction, the user's Smart Contract Wallet will refund the gas spent by the Executor.

But wait, didn't I say the user doesn't need to worry about any wallet? That's correct. The Smart Contract Wallet, also known as an Account Abstracted Wallet (AA Wallet), will be automatically created when the Executor processes the first transaction. The user's AA Wallet will contain some Ether to cover the gas paid to the Executor.

What if a malicious user gets their action executed but doesn't have enough Ether to compensate the Executor for the gas? In that case, the Executor should run a simulation to check this beforehand, before sending the actual transaction.

But can we truly trust simulations? They might work perfectly in advance, but things can go awry in real-time. When might this happen? For example, reading a contract's storage in a simulation might yield different results than when the Executor actually sends the transaction.

The solution is to introduce an audited and source-code-verified Smart Contract called EntryPoint, deployed on the Blockchain. The Executor can trust this contract instead of relying on the user or the simulation they run.

Now, what are the functions of the EntryPoint? It will check whether the user has enough funds in their AA Wallet to pay for the gas, keep track of the actual gas consumption when executing the user's action, and refund the Executor's gas from the user's AA Wallet.

To ensure the refund happens, the user's AA Wallet will deposit some funds beforehand to the EntryPoint. This ensures that EntryPoint doesn't need to chase after funds in the AA Wallet after the action is executed.

The term "simulation" used so far refers to the "validation" of the UserOp. This means there needs to be a mechanism to ensure that the rightful owner of the AA Wallet initiated the UserOp and no one else. This, along with a few other checks, is carried out using simulation (validation). Hence, the AA Wallet will contain two functions: one to validate the UserOp, which is executed locally by the Executor and then on-chain by the EntryPoint; and the other to execute the validated UserOp, which is executed on-chain by the EntryPoint Contract.

If the Executor's validation fails, it won't be sent to the EntryPoint, and the user won't be charged any gas for this, as it was only run locally with certain restrictions. But if validation passes and execute fails during runtime, the user will be charged for the gas to compensate the Executor because it was running on-chain, regardless of success or failure.

In the absence of Paymasters (entities that sponsor gas and enable gasless transactions, covered later), the AA Wallet needs to have some Ether to pay for the gas. The AA Wallet will deposit some Ether to the EntryPoint beforehand. If the EntryPoint calculates during validation that it will run out of gas during execution, it will ask the AA Wallet to deposit more Ether. Any extra or unused Ether remaining with the EntryPoint after successful execution will be refunded to the AA Wallet.

However, refunding to any AA Wallet, which is essentially a contract, can be risky. This is due to the potential for malicious AA Wallet code to be invoked when the EntryPoint attempts to refund the extra Ether. To mitigate this risk, the AA Wallet must call a withdraw() method to receive the remaining Ether as a refund.

Amid all these considerations, you may wonder why the Executor would go through all this trouble. This is where the concept of maxPriorityFeePerGas comes in. The user has the option to add a "tip" to their action data to prioritize its execution. The Executor can also add a similar "tip" when sending the transaction to the EntryPoint, thus pocketing the difference between the two tips.

In summary, the EntryPoint has nothing to do with the Executor or the AA Wallet. It's deployed on the Blockchain for the Executor to call one of its functions to send the user's action or transaction to the network. This means there is only one EntryPoint for countless Executors and Smart Contract Wallets (Users).

To summarize this complex process:

1. A user creates a UserOp.

2. It goes to the Executor (EOA).

3. The Executor validates it locally.

4. If it passes, it's submitted to the EntryPoint.

5. EntryPoint re-validates the UserOp (now a transaction) on-chain.

6. If it passes again, the transaction is executed, and excess Ether is refunded to the User's AA Wallet.

Now, to simplify things even further, let's introduce the concepts of Bundling and Bundlers. Sending each transaction to the Blockchain costs a substantial 21,000 gas. It makes sense to bundle multiple UserOps into a single transaction. This saves a significant amount of gas and, consequently, the Executor is better described as a Bundler. This process is called Bundling.

Our mental model up to this point now needs to be revised to incorporate bundling:

1. Multiple users approach a Bundler to have their UserOps executed.

2. The Bundler keeps their UserOps in a Mempool (similar to how transactions are held in nodes' mempools before being selected to build a block).

3. The Bundler runs validations for all the UserOps locally.

4. All the UserOps that pass are submitted to the EntryPoint, while the rest are discarded.

5. The EntryPoint validates all the UserOps one by one, using their respective sender's AA Wallets.

6. Those that pass are executed one by one.

7. All the AA Wallets should have deposited their respective gas fees to the EntryPoint beforehand.

8. After execution, the EntryPoint refunds any excess gas to the respective wallets, as it keeps track

of each transaction.

Bundling also allows Bundlers to maximize their profits through a concept called MEV (Maximal Extractable Value).

Now, let's introduce the concept of Paymasters. There are various scenarios to consider:

Scenario 1: Gasless for the user - new users might find it challenging to obtain Ether for their AA Wallets, hindering their Web3 adoption.

Scenario 2: A Web3 application wants to cover the gas fees for its new users to boost its adoption.

Scenario 3: Not gasless, but users have the liberty to pay for gas in a non-native token or a fixed ERC-20 token like USDC.

In these scenarios, the Paymaster comes into play. It's a Smart Contract that determines whether or not it will pay for the gas for a specific UserOp. UserOps contain data specifying which Paymaster will cover their gas costs.

The long chain of events is updated to include Paymasters:

1. The user creates a UserOp, including the address of the Paymaster (a deployed Contract).

2. The UserOp goes to the Executor (EOA).

3. The Executor validates it locally, both the AA Wallet and Paymaster Contract.

4. If it passes, it's submitted to the EntryPoint.

5. The EntryPoint re-validates the UserOp (now a transaction) on-chain. It also validates whether the Paymaster mentioned in the AA Wallet will pay for the user's gas.

6. If it passes again, the transaction is executed, and excess Ether is refunded to the Paymaster or the User.

To prevent malicious Paymasters from disrupting the execution of UserOps, an additional concept called Paymaster-reputation is introduced. Bundlers assign reputations to Paymasters to identify those acting maliciously in the system.

Paymasters are also required to stake some Ether with the EntryPoint. This serves as a deterrent for malicious Paymasters, as it demonstrates their commitment to the system.

Now, what happens if the user fails to pay the Paymaster after their action is executed by the Bundler and the Paymaster has covered the gas cost? The process for this involves the Paymaster taking note of the gas amount specified by the user in the UserOp. If it seems sufficient, validation passes. During execution, the EntryPoint tracks gas usage and informs the Paymaster. If on-chain gas consumption exceeds the amount mentioned in the UserOp, the entire execution is reverted. If it's less than or equal to the specified amount, there's no issue. In either case, the Paymaster eventually charges the user for the execution of the operation on-chain, regardless of success or failure.

So far, we've covered the core mechanisms of how Paymasters work while sponsoring gas for the user. The separation of the entity sending the transaction to the network (Bundler) and the entity paying for the gas (user's AA wallet or Paymaster) has simplified the process for non-native Web3 users.

Now, let's delve into the technical aspects of wallet creation. An AA wallet is essentially a Smart Contract, and creating one means deploying a Smart Contract on-chain. This might raise concerns about gas costs for wallet creation. Does this mean users have to pay gas every time they create an AA wallet? Not quite. Users only need to pay gas when they send a transaction using their AA wallet, not when they receive funds.

For an AA wallet, there is a concept called "Counterfactual address," which represents an address where a contract (AA Wallet) will be deployed in the future. This address is deterministically generated using an EVM opcode called CREATE2. This allows users to receive funds in their AA wallet without incurring gas costs.

However, when users want to send funds, their AA wallet must be deployed, and gas costs are involved. They can avoid gas costs for deployment if the AA wallet is deployed by an Account Factory. Users can select an Account Factory, which deploys the AA wallet and returns its address. This way, the user doesn't need to interact with arbitrary bytecode for wallet creation.

Account Factories also play a role in reputation. Similar to Paymasters, Account Factory contracts stake some Ether with the EntryPoint. This serves as a reputation metric to penalize malicious Account Factories.

In addition, a more advanced feature called Aggregate Signature is introduced. This allows multiple UserOps with different signatures to be checked with a single combined signature, which can save on gas costs. Aggregator contracts are responsible for aggregating these signatures and validating them.

The complex process can be summarized as follows:

1. Multiple users approach a Bundler to execute their UserOps.

2. The Bundler groups UserOps with the same Aggregator (signature scheme) into one group.

3. The group of UserOps and their aggregated signature are sent to the Aggregator for aggregation.

4. The Aggregator returns the aggregated signature to the Bundler.

5. The Bundler sends the group of UserOps with the aggregated signature to the EntryPoint.

6. The EntryPoint validates the single signature for the set of UserOps, while UserOps that aren't aggregated are validated individually.

This covers the core mechanics of Account Abstraction. It's a complex system, but it simplifies the user experience and enables broader adoption of Web3 technology.

If you find this explanation confusing, I recommend a careful re-reading to fully grasp the inner workings of Account Abstraction. Feel free to provide feedback, criticism, or appreciation as it helps me improve. Peace in the world of Web3.