Understanding the Benefits of Account Abstraction for Web3
Overcoming the Limitations of Stateful Applications with Stateless Protocols
Ethereum as we all know is a decentralized platform that enables users to sign transactions and interact with the blockchain. Now, to participate in the Ethereum network, a user must have an Ethereum account, which is either an Externally Owned Account (EOA) or a Contract Account.
EOAs are controlled by users through private and public keys, while Contract Accounts are smart contracts defined by code. Understanding the distinction between these two types of accounts is important for using and interacting with the Ethereum network.
Now that we know about the accounts, what about transactions?
Transactions are necessary to write information to the blockchain and must be signed by an EOA, which also has to pay associated gas fees. In Ethereum for example, transactions are initiated by an Externally Owned Account (EOA) and can either be sent to another EOA, such as in the case of transferring ETH, or to a Contract Account, such as when minting an NFT.
So, how does account abstraction fit into all this?
Account abstraction is a mechanism that allows the programmatic setting of transaction validity conditions. It suggests that users can utilize smart contract wallets instead of Externally Owned Accounts (EOAs), thereby eliminating the requirement for users to utilize EOAs for transactions.
This mechanism enables the building of new features and applications that were not possible before. Some examples of these features include paying gas fees for other users, walletless web3 login, and the ability to initiate transactions from a multi-sig.
But why?
The reason for using smart contract wallets instead of EOAs is to eliminate the need for users to manage private keys and reduce the risk of losing control over their funds, as private keys are susceptible to loss and cannot be recovered. Additionally, smart contract wallets can offer more advanced capabilities compared to EOAs, which are limited to only executing a few actions such as submitting a transaction to transfer tokens or executing a function on a contract account.
It is a way to change the rules for what makes a transaction valid on a blockchain network. Currently, on Ethereum, a transaction is only considered valid if it has enough funds to pay for the gas, the nonce is correct, and it has a valid digital signature.
With account abstraction, developers can change these rules and specify their own conditions for a transaction to be valid. This means that instead of relying only on a digital signature for authentication, transactions can be authorized by other means.
For example, developers could create smart contract wallets that use facial recognition or biometric data for authentication, or set conditions based on specific events or conditions on the blockchain network.
The history of Account Abstraction Proposals dates back to 2016 with the proposal EIP-86, which aimed to allow users to create “account contracts” to perform signature/nonce checks instead of using the hard-coded mechanism in transaction processing. In 2020, two more proposals, EIP-2938 and EIP-3074, were introduced to create a new transaction type and delegate control of EOA to smart contract wallets, respectively. However, none of these proposals has been adopted into Ethereum due to the need for consensus-layer protocol changes. The inactive status of these proposals continued until 2021 when EIP-4337 was proposed.
Hence, ERC-4337 was the first standard for account abstraction in Ethereum that did not require changes to the core protocol. It moves the validation of transactions from the protocol to the smart contract level, allowing greater flexibility.
Types of account abstraction
Account abstraction can be divided into two:
Stateless account abstraction
Stateful account abstraction
Stateless and stateful account abstraction are two different approaches to executing transactions automatically based on certain conditions.
Stateless account abstraction
In stateless account abstraction, the system operates without retaining any information regarding a user’s state. The smart contract that defines the conditions does not depend on the external state or have any side effects. Every interaction is self-sufficient and not influenced by the server’s past state, relying solely on the data available at that moment.
Consequently, each client request must carry all required information, including authentication keys, for the server to perform and respond to the request. Stateless protocols treat each action as a standalone event. This ensures that the conditions for executing the transaction remain the same and eliminates the risk of changing validity.
Now, let’s assume we have a blockchain platform designed with statelessness in mind that operates similarly to the REST architecture. Every transaction request must include all necessary information, including authentication keys, in order to be executed by the network. The network then performs the specified task, with the data contained in the transaction request, and returns the result as a part of the blockchain’s state.
In this example, we first create an instance of the Ethjs library using an Ethereum node URL provided by Infura. We then define the sendTransaction function that prepares and sends a transaction. In the function, we specify the sender address, receiver address, value (in wei), gas price (in gwei), gas limit, and nonce. The nonce is the number of transactions sent from the sender address and is used to prevent replay attacks.
Next, we create a raw transaction object with the transaction details and sign it using eth.signTransaction. Finally, we send the signed transaction to the Ethereum network using eth.sendRawTransaction.
The transaction request would contain the source address, a destination address, and the amount of funds to be transferred, along with the necessary authentication keys. The network would then process the request and update the blockchain’s state to reflect the transfer of funds. The next transaction request starts the process over again, with no knowledge of previous transactions required to be stored on the network.
This demonstrates how stateless blockchain transactions can be executed with just the required data and authentication, without any server state being needed.
Stateful account abstraction
In contrast, stateful account abstraction allows the smart contract to access the chain’s state, which may cause the conditions to change and result in invalid transactions. A stateful protocol maintains a record of past session information as part of the user’s state.
This state data from client sessions enables the application to handle subsequent transactions based on prior ones. For example, In a blockchain network, transactions are stored in blocks and linked to previous blocks to form a chain of blocks, hence the term “blockchain.” Each block contains a list of transactions and is linked to the previous block using a cryptographic hash. This creates an immutable and transparent ledger of all transactions on the network. In a blockchain system, a user’s funds, linked accounts, and authorization are recorded as part of the state.
This code represents a simple implementation of a blockchain network, where transactions are stored in blocks that are linked to previous blocks using a cryptographic hash. The `Transaction` class represents a transaction, the `Block` class represents a block, and the `Blockchain` class represents the blockchain. In this code, transactions are verified, blocks are added to the chain, and the proof of work is computed in order to secure the network.
When a user initiates a transaction, it changes the state of their account, and the transaction is saved in the next block added to the blockchain. The user’s public key, which serves as their account identifier, is used to confirm their identity when making transactions. If the user wants to update their account information, such as changing the linked accounts, they need to initiate a new transaction to update the state of their account on the blockchain.
The use of a database for storing data does not automatically make an application stateful — the key distinction is that the client’s current state information is saved on the server itself. This is why ERC4337, a specification for stateless account abstraction, bans the use of certain opcodes to avoid these issues.
Stateless Vs Stateful
The use of stateful and stateless protocols depends on the software engineer’s discretion. Stateless protocols are more scalable and agile than stateful protocols due to their lack of server-side storage for client information. Stateful protocols struggle to handle the overhead of multiple client sessions, but stateless protocols do not store the client state on the server, allowing for greater scalability. Client information can still be stored through cookies or retrieved from a database, but it is stored on the client side, not the server. This makes stateless protocols a key factor in the rise of containerization, microservices, and cloud computing.
Usecase argument for account abstraction
The goal of account abstraction is to allow for more flexibility and creativity in how transactions are authorized and validated, enabling new possibilities for how digital assets can be used and managed on the blockchain. The ability to auth by anything other than a key opens up new possibilities for digital asset management and creates new opportunities for innovation in the space.
Let’s consider a scenario where a user wants to interact with a DeFi platform to trade cryptocurrency.
Traditionally, the user would need to hold the cryptocurrency in their own EOA and manually initiate transactions to buy or sell the assets. This can be a time-consuming and confusing process for many users, especially those new to blockchain technology.
With account abstraction, the user can interact with the DeFi platform through a smart contract wallet, which acts as an intermediary between the user and the blockchain. The user no longer has to manage their own EOA, as all transactions are automatically handled by the smart contract wallet.
The user simply needs to interact with the smart contract wallet’s user-friendly interface to trade assets on the DeFi platform. The smart contract wallet then handles the underlying transactions on the blockchain, including managing the user’s funds and authorization.
This simplifies the process of interacting with DeFi applications and removes many of the challenges associated with managing an EOA, making it easier for users to participate in DeFi and take advantage of its benefits.
So, in summary, the use-case highlight for account abstraction is:
Perform transactions more efficiently: By separating the state of an account from the underlying ledger, it is possible to access and update the state of the account more quickly, making transactions faster and more efficient.
Improve security: By storing the state of an account in a secure, encrypted environment, it is much more difficult for a malicious actor to steal or manipulate the data. This makes account abstraction ideal for applications where security is critical, such as digital asset custody or financial applications.
Use digital assets in decentralized applications: Account abstraction makes it possible to use digital assets in decentralized applications, such as decentralized exchanges, without the need for a centralized authority.
Manage multiple digital assets: Account abstraction allows users to manage multiple digital assets from a single account, making it easier to track and manage their portfolio.
Access digital assets from any location: With account abstraction, the state of an account can be securely stored and accessed from any location, making it easier to manage digital assets from any device.
How will account abstraction change web3 UX?
The evolution of wallets into contract accounts is necessary to significantly enhance the user experience of web3.
Account abstraction can significantly redefine user experience (UX) improvements in the way digital assets are managed and used. It can allow for a more intuitive and streamlined experience for users by abstracting the underlying technical details of transactions and accounts.
This can include improvements such as easier account management, more secure transactions, and faster and more efficient processing of transactions. Additionally, account abstraction can lead to the development of new and innovative financial products and services that are more accessible to a wider range of users.
The possibilities are almost endless. We have:
Automated payouts for content creators without the need for manual wallet transfers
One-click purchases for online shops that don’t require manual wallet transfers
Simplified savings and investment management through smart contract-based portfolios
Enabling seamless and secure cross-platform transactions and exchanges of digital assets
Easy-to-use multi-signature wallets for increased security and management of funds by multiple users.
Other ways include:
Simplified asset management: With account abstraction, it is possible to manage multiple digital assets from a single account, making it easier to track and manage a portfolio.
Improved transaction speed: By separating the state of an account from the underlying ledger, transactions can be executed more quickly, improving the overall user experience.
Enhanced security: Account abstraction enables the secure storage of digital assets, making it easier for users to feel confident that their assets are protected
Better interoperability: By allowing digital assets to be used in decentralized applications, account abstraction can improve the interoperability of different blockchain networks, making it easier for users to access and use digital assets from different platforms.
Increased accessibility: With account abstraction, users can access their digital assets from any location, using any device. This increases accessibility and makes it easier for users to manage their digital assets on the go.
Applications enabled by account abstraction
Account abstraction can enable a number of new applications and use cases for digital assets. Some of these include:
Decentralized exchanges: With account abstraction, it is possible to build decentralized exchanges that allow users to trade digital assets without the need for a centralized authority.
Digital asset custody: Account abstraction makes it possible to store digital assets in a secure, encrypted environment, making it ideal for digital asset custody applications.
Non-fungible tokens (NFTs): Account abstraction can be used to manage NFTs, making it possible to use these unique digital assets in decentralized applications.
Gaming: By allowing digital assets to be used in decentralized applications, account abstraction can enable the creation of new gaming experiences where users can earn and trade in-game assets.
Decentralized finance (DeFi): Account abstraction can be used to build decentralized finance applications that allow users to access financial services without the need for a centralized authority.
Supply chain management: Account abstraction can be used to track the movement of goods in a supply chain, making it possible to build more efficient and transparent supply chain management systems.
Conclusion:
The introduction of account abstraction has shifted the focus of blockchain development towards improving the user experience. With the help of layer 2s, fees have become low enough to make blockchains usable, but the user experience of applications still needs to be improved. In the coming years, more teams are likely to focus on account abstraction-enabled user experience improvements, which will be a crucial step in bringing a web2-like experience with the security benefits of web3.
Concerning improved transaction speed, can you throw more light on how Account abstraction enables it?
If stateless account abstraction allows the protocol to just determine if a transaction is valid based on only the data the tx provides, we'll still need to process the tx on the Blockchain to complete it. Which should take same time as a normal tx.