The history and the future of Account Abstraction

The concept of Account Abstraction isn't novel; it's been envisioned for several years. In fact, Vitalik had the ambition to incorporate Account Abstraction into Ethereum from its inception. Curious about its origins and where it's headed next

Let's dive deeper ??

It all began with EIP 86, which introduced an abstraction of transaction origin and signature mechanisms ?

As many are aware, on Ethereum, transactions are typically initiated with EOAs. This limitation is the reason why users can initiate transactions with smart wallets.

EIP 86 has proposed to change the transaction origin and signature scheme, enabling smart wallets to initiate transactions. Implementing this EIP required changes at the protocol level, which complicated coordination and widespread acceptance ??

Another issue was its vulnerability to potential DoS attacks. This stems from a foundational aspect of Ethereum: There is no way to know the output of the Ethereum transaction without executing it. Typically, Ethereum prevents DoS attacks by checking the validity rules ??

Introducing any specific censoring or rejection mechanism to the network introduces potential DoS vectors. A case in point is the Ethereum DAO fork, which inadvertently opened up a DoS vector. EIP 86 faced a similar issue. Thus, this EIP wasn't adopted. https://hackingdistributed.com/2016/06/28/ethereum-soft-fork-dos-vector/

Subsequent to this, EIP 2938 was proposed. This proposal introduced two new opcodes to enable AA and offered a new transaction type for Smart Accounts. EIP 2938 aimed to enable gas abstraction, signature abstraction, and several other intriguing AA functionalities but;

Even with EIP 2938, we still can't execute batch transactions (i.e., combining approve + transferfrom in one transaction) or meta-transactions. It does not fully support AA, and it cannot provide definitive solutions to the DOS vector found in EIP 86 and EIP 4337.

EIP 2938 didn't receive acceptance, so we finally got EIP 3074, which is not actually an upgrade aimed at account abstraction. Instead of a radical change like altering the validity rules of transfers, it aims to add programmability to EOA wallets with a simpler upgrade.

EIP 3074 introduced two new opcodes to enhance EOA wallets. First, the user grants permission to the Invoker contract using the Auth opcode. Then, they sign the transaction to initiate the ERC20 token transfer. The gas is covered by the sponsor through the AuthCall function.

Using the messaging format provided by the Auth opcode, we can consolidate multiple transactions into a single transaction and execute it within the EVM using the "commit" function. This approach can enhance the user experience in many applications.

Since EIP 3074 entailed the introduction of two new opcodes via a protocol-level change, it underwent an extensive security review process. EIP 3074 is still under review because of potential issues identified in these security reviews. For more: https://docs.google.com/document/d/1itvPn7BhZ9N8h27d1Ig5C86_FZpyG5_cdpsuPJYmb-o/edit#heading=h.g8uis5uw10nd

And finally, we have ERC 4337. ERC 4337 enables Account Abstraction without necessitating any protocol changes and has garnered significant traction from the community. ERC 4337 is now live on Ethereum, and the count of successful UserOperations has recently surpassed 1M.

We'll delve into the details of ERC 4337 in a subsequent tweet. For now, let's proceed with the proposals that were introduced after ERC 4337. EIP 5003: This is an improvement of EIP 3074, introducing a new opcode.

In EIP 3074, the owner of the account is the EOA's signer. This implies that we cannot revoke the official signer from the account, leading to a risk where leaked keys could result in a loss of funds. 5003 introduces a new opcode to allow for the revoke of the initial keys.

Smart wallets require certain standards to build upon. ERC 6900 introduces modular smart contract standards for these wallets. ERC-6900 allows developers to abstract execution and validation logic, paving the way for innovative features in smart contract wallets.

EIP 7212 introduces a new precompiler for P256 curve verification. The P256 curve is widely used in web2 systems, such as DNS, WebAuthn, Passkeys, Secure Enclave, and many others. However, Solidity verifier remains quite expensive. To solve this, EIP 7212 offers a precompiler

If you possess an EOA wallet and wish to transition to smart wallets, you'd typically need to transfer all your assets to a new wallet. This is the challenge EIP 7377 addresses. EIP 7377 allows EOAs to transition to smart wallets using a new transaction type.

We have accomplished the history of AA in our Account Abstraction report. You can check it for more ??

https://blog.getclave.io/p/ultimate-account-abstraction-guide