By customizing certain elements of smart contract accounts, account abstraction makes it easier for users to interact with blockchain.
Earn Bitcoin Every Hour + Daily Interest
What Is Account Abstraction?
Account abstraction is the process of making it easier for users to interact with blockchain by customizing certain elements of smart contract accounts, from fee payment methods to transaction approval mechanisms.
This has been discussed widely in the Ethereum community, with Vitalik Buterin putting forward multiple proposals (ERC 4337, EIP 2938, among others) that outline how to make transactions simpler for the end user.
Background on Ethereum Accounts
To understand the value of account abstraction, it is necessary to understand some fundamentals about Ethereum accounts first. On Ethereum, there are two types of entities: External Owned Accounts (EOA) and Smart Contracts accounts.
An EOA is made up of a cryptographic pair of keys: public and private. It is represented by an address that is created after a user has set up his/her key pair. A private key is used to sign transactions; it grants users custody over the funds associated with their accounts.
The key pair can then sign transactions from a given address. This is because the key and the account are one. This results in specific restrictions. For example, only having one key to authorize transactions and control the account. If lost or stolen, the account is likely lost forever.
EOA’s also pose a problem because as individual accounts, they can put out single transactions which need to be verified creating gas fees each time.
Ultimately, there is little wiggle room or 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.
Account Abstraction for Improved Users Experience
Account abstraction is a way to address these roadblocks by converting an EOA into a smart contract with its own logic for deciding what constitutes a verified transaction. This means the signer and the account can be decoupled, opening up a wider range of possibilities for account use.
For example, account abstraction could allow the EOA to do a wide range of actions, such as using multiple or zero keys to authorize transactions or changing the signer of the account every week.
A significant benefit of account abstraction is the improved user experience (UX) and security because of the seamless interactions it facilitates.
It has multiple use cases and relieves some of the issues faced especially when it comes to project scaling and onboarding.
Social Recovery and Account Abstraction
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. Account abstraction can assist by creating a better security net through multiple signers.
Account abstraction can also be used to build better blockchain games with micro-economies. Play-to-earn is already becoming such a lucrative arena but is held up by the number of micro-transactions needed to keep gameplay up with multiple NFT in-game assets across thousands of users. Account abstraction addresses this through the collective signers’ mechanism.
Improved Transactions and Account Abstraction
Finally, atomic (batch) transactions through account abstraction can allow users to pay fees in a native token rather than using ETH, which is currently the case. That makes interacting with L2s simpler and doesn’t require extensive buy-in by the user before utilizing a chain.
Account abstraction also allows for meta-transactions. These are like a butler that executes a transaction signed by another party on behalf of the original signer. This removes complexities and gas costs on public blockchains by letting a relayer network handle these while the user just needs to sign the transaction with one click.
These meta-transactions allow the payment for the transaction to be abstracted away from the user and given to the dApp, thereby simplifying the transaction process. This is especially useful in areas such as play-to-earn gaming and onboarding tools.
This fee abstraction can also remove the complexity of paying on-chain transactions through dApps, by allowing payments through their native token. Should a user wish to pay with a native token rather than the blockchain’s cryptocurrency (like $ETH), account abstraction makes this possible. Finally, it allows for better control of your interactions with a dApp in the form of session keys. A session key is a symmetric cryptographic key used to encrypt a communication session. More simply, it’s a single-use key for encrypting and decrypting data sent between two parties. For example, should you wish to interact with a dApp but don’t want to keep signing transactions to approve every move you make, a session key sets the parameters for what the dApp can and can’t do in relation to your account.
As such, you don’t have to trust a third party with your logins and approvals, and you can also avoid the exhausting effort of re-approving everything.
Account Abstraction for Enhanced Security
Account abstraction may make interacting with dApps and the user experience in web3 simpler but it also provides improved security.
Account abstraction allows you to customize your accounts to work only when certain conditions, including the number of signers, are met. This is customizable across accounts so users can have more control, than for example a classic multi-sig.
Some examples of customization can include actions like setting limits on transfers and multi-factor authentication. This removes the current massive point of failure in that users can lose everything if they are not extremely careful.
Account abstraction opens up usability without risking security and even further enhances it with its adaptable options.
Bio: Sachin Tomar, CTO and Co-Founder of Biconomy, a hyper-flexible toolkit to superpower your Web3 stack. With a background in software engineering, Sachin is working to make a decentralized world through blockchain.