Introduction
In this article, we will be learning about a recent paradigm in the Ethereum and web3 ecosystem called Account Abstraction. Account Abstraction changes how users use their account wallets in terms of blockchain interactions on the Ethereum network. We will learn about the origin, implications, pros and cons and what providers or products are already using it.
Account Types
Accounts on the Ethereum blockchain can send transactions using their ether (ETH) balances. Depending on the deployment, these accounts are either user-controlled (human) or smart contracts (code-dependent). Therefore, there are two types of accounts that a user can use to interact with the blockchain.
The Externally Owned Accounts (EOAs)
Smart Contract Accounts
The Externally Owned Accounts
The Externally Owned Accounts are made up of a cryptographic pair of keys: public and private. They help prove that a transaction was signed by the sender and prevent forgeries. Your private key is what you use to sign transactions, so it grants you custody over the funds associated with your account. You never really hold cryptocurrency, you hold private keys – the funds are always on Ethereum's ledger. This prevents malicious actors from broadcasting fake transactions because you can always verify the sender of a transaction.
EOAs are much like normal bank accounts. They have an address (IBAN) and a balance (in Ether). Essentially, the EOAs owner possesses a public key pair, of which only he knows the private key. The matching public key is the EOAs "address" - the "IBAN". Now, only the EOAs owner can transfer Ether (ie "withdraw or wire money") from that account - by using the private key in the process. In summary, EOAs are "directly owned and controlled" by their respective owners. These types of accounts are usually provided by wallet providers like Metamask, TrustWallet, SafePal etc. and they are the most in-use type of accounts by blockchain products consumers.
Contract Accounts
Contract Accounts are controlled by code executed by the Ethereum Virtual Machine. They are also referred to as smart contracts. Contract accounts have associated code and data storage, but not private keys. They “control themselves”. These accounts do so in the way determined by their smart contract code.
A contract address hosts a collection of code on Ethereum that executes functions. The functions are executed when a transaction with associated input data (contract interaction) is made. Such addresses are created when a contract is deployed to the blockchain.
Implications to the Ecosystem
In the attempt to spread the adoption of blockchain technologies and products, not just to the technically educated but also the non-technical folks, onboarding to these products and usage has been characterized by poor user experiences because blockchain technologies are associated with a lot of technicalities from setting up accounts, connecting to wallets, using dApps, transactions and recovery of funds.
Externally Owned Accounts Limitations
The use of EOAs does not help much with regards to a seamless experience as one can experience difficulties like:
Not being able to do multi-transaction (eg: swap, send etc at the same time), leads to paying gas fees for every single transaction.
No guarantee for account recovery when one loses the private keys and thereby resulting in the loss of accounts and funds as the private key is the only means to approve transactions.
Ultimately, there is little wiggle room for customization, as users can’t create custom logic to include more signers or authorize different keys to sign on to their accounts. This creates a very limiting scope for transactions.
How does Account Abstraction Improve the User's Experience?
With the advent of account abstraction and the introduction of smart contract addresses, there are lots of benefits that will improve user experience in blockchain products. These benefits include and are not limited to:
Account abstraction unifies contract accounts and EOAs. It makes user accounts more "programmable". You remove the logic of signing transactions from the account, and you “abstract” it out, hence account abstraction.
It unlocks much more flexibility, you could make batch transaction operations at the same time.
It also allows for enhanced security as you can code the conditions to be met before a transaction could be signed, set transfer limits and also perform multi-factor authentications.
Social recovery is one of the UX improvements account abstraction provides by avoiding the issue of a single point of failure with the private key.
It allows the non-custodial blockchain UX to scale.
The State of Account Abstraction
Smart contract wallets exist today but are challenging to implement because the Ethereum virtual machine (EVM) does not support them. Instead, they rely on wrapping relatively complex code around standard Ethereum transactions. Ethereum can change this by allowing smart contracts to initiate transactions, handling the necessary logic in Ethereum smart contracts instead of off-chain. Putting logic into smart contracts also increases Ethereum's decentralization since it removes the need for relayers run by wallet developers to translate messages signed by the user to regular Ethereum transactions.
Currently, there are two major proposals for implementing account abstraction to the Ethereum network:
EIP-4337
EIP-4337 is the first step towards native smart contract wallet support in a decentralized way without requiring changes to the Ethereum protocol. Instead of modifying the consensus layer to support smart contract wallets, a new system is added separately to the normal transaction gossip protocol. The way wallets work would also change under EIP-4337. Instead of each wallet re-implementing common but complex safety logic, those functions would be outsourced to a global wallet contract known as the entry point. This would handle operations such as paying fees and executing EVM code so that wallet developers can focus on providing excellent user experiences. Note that the EIP-4337 entry point contract was deployed to Ethereum Mainnet on 1st March 2023.
EIP-2938
EIP-2938 aims to update the Ethereum protocol by introducing a new transaction type, AA_TX_TYPE that includes three fields: nonce, target and data, where nonce is a transaction counter, target is the entry point contract address and data is EVM bytecode. To execute these transactions, two new instructions (known as opcodes) have to be added to the EVM: NONCE and PAYGAS. The NONCE opcode tracks the transaction sequence and PAYGAS calculates and withdraws the gas required to execute the transaction from the contract's balance. These new features allow Ethereum to support smart contract wallets natively as the necessary infrastructure is built into Ethereum's protocol. Note that EIP-2938 is currently not active. The community is currently favoring EIP-4337 because it does not require changes to the protocol.
Smart contract wallets are already available, but more upgrades are required to make them as decentralized and permissionless as possible. EIP-4337 is a mature proposal that does not require any changes to Ethereum's protocol, so it is possible that this could be implemented quickly. However, upgrades that alter Ethereum's protocol are currently not in active development, so those changes may take much longer to ship. It is also possible that account abstraction is achieved well enough by EIP-4337 that no protocol changes are ever required.
Conclusion
To onboard more blockchain users and provide a very seamless user experience to them, account abstraction has a major role to play in the way blockchain products are built and utilized. Blockchain technologies keep improving every day and we will get to see more innovations around account abstraction not only in the Ethereum ecosystem but also in other blockchain ecosystems as well.
Top comments (0)