In a nutshell, account abstraction is the ability to separate cryptographic keys from an account.
In Ethereum, the account model is such that accounts operated by users (Externally Owned Account, or EOA) start off as a private key (ECDSA secp256k1), which generates a public key, which in turn is used to generate an address. The account is thus inseparable from its private key, public key, and address. Almost all other EVM-compatible networks have followed Ethereum, and EOAs work the same way across multiple networks.
While the EOA approach has worked well for its intended use cases, new and interesting use cases are made possible when cryptographic keys are separated from their accounts. Account abstraction uses an alternative account model where this is possible.
This article will cover the following:
The account abstraction concept in a nutshell
How Web3 adoption is held back, and how account abstraction removes the barrier
Protocol-level account abstraction, and how it differs from current account abstraction implementations
Hedera’s unique capabilities among EVM networks that enable protocol-level account abstraction
Entering the world of Web3 and interacting with DApps (Web3 applications) presents a steep learning curve, especially for those accustomed to the more user-friendly interfaces of Web2 applications. The first step lies in navigating the complexities of wallet set up, which includes understanding cryptographic keys, managing seed phrases, and the daunting realization that there is no equivalent “reset password” in this space.
The few users who make it past this hurdle now need to navigate the intricacies of interacting with DApps, which includes signing transactions, transaction fees, smart contracts, tokens, and more complex user interfaces.
Interacting with DApps thus requires users to be far more tech-savvy than they were with Web2 applications. There have been many attempts to solve this in various Web3 applications, but so far none of them have come close to achieving the simplicity of the humble username-password combination of Web2, plus the ability to easily reset passwords when you forget them.
Some Web3 applications have a “solution” for this: Let users continue to create usernames and passwords, amounting to a faux account. In this case, the Web3 application will manage the account (private keys included) on its own Web2 server, which has custody of the real account. While this approach technically works, it misses the whole point of Web3 technology and philosophy. In this scenario, users may as well use a Web2 application instead.
Remember: Not your keys, not your crypto.
So, how can we solve this problem? Is it possible to create a true equivalent Web2 user experience for accounts on Web3? One that does not involve ceding custody of cryptographic keys to any (centralized) entity?
Account abstraction, as it turns out, is a great way to achieve that! One of the use cases for account abstraction includes the ability to recover your account in a decentralized manner, as illustrated in these articles:
Ref: Social Recovery Wallets - Vitalik Buterin
Ref: Decentralised Wallet Recovery - Itmar Lesuisse
Ref: DeRec Protocol - Rohit Sinha
Recovering accounts in this manner solves the first (and major) hurdle to the adoption of Web3 technology. What else can account abstraction enable?
Easy to understand transactions: Transferring currency (fungible tokens) without the need to manage a separate currency (native coin) for transaction fees.
Cheaper transactions: Transferring currency (fungible tokens) with transaction fees subsidized or discounted.
Cheaper transactions (again): Lower average network transaction fees by bundling operations of multiple users into a single transaction.
Programmability/flexibility: Generally, any task that can be performed by a smart contract.
In short: Yes.
Account abstraction fundamentally transforms the user experience of a DApp. Imagine a DApp where signing up is as simple as a few clicks, similar to a Web2 application. Imagine recovering an account in a DApp being as straightforward as “reset password” on Web2 applications. Imagine using a DApp without the need to understand or manage cryptocurrencies, tokens, and transaction fees, with each interaction as seamless as a Web2 application. Imagine interacting with a DApp whose transaction costs have been optimized to be a fraction of what they typically are at present.
By abstracting away these complexities from DApps, account abstraction makes Web3 more understandable, and therefore approachable, lowering the barriers to entry. This shift has the potential to catalyze a new era of Web3 adoption, by kicking off a positive feedback loop, where this incentivises more companies that currently build Web2 applications to start building Web3 applications as well. Perhaps it might even inspire more Web2 companies to switch to a Web3-first approach, and build Web3 applications instead of Web2 applications.
Web2 companies typically choose to adopt Web3 technology for a couple of reasons:
The buzzword factor.
The ability to create immutable and transparent public records in a decentralized manner.
The ability to remove trust assumptions. For example, no need to trust the entity hosting the databases or web servers.
The buzzword-inspired companies are usually motivated by generating press attention at worst, and innovation pilots/proofs-of-concept at best. Let’s set these aside.
Instead, let’s focus only on Web2 companies that have truly understood and internalized the value of Web3 principles and want to bring them in-house. These companies would be willing to build their products based on those fundamentals; however, they will not be willing to do so at all if they cannot turn a profit. If these companies think that Web3 technology adoption will place an upper limit on user acquisition, they simply will not make the jump.
Without account abstraction, Web3 does indeed experience the problem of an adoption barrier. By lowering the barrier to enjoy and adopt Web3, those same companies that are currently holding back on building their products with Web3 technology may now reconsider and decide to go through with it. This will be critical to adoption!
However, this comes with a big caveat. Whenever new technology is introduced, you can be sure of two things: (1) It will be used to build more or better software, perhaps in ways that weren’t possible before; and (2) The attackable surface area will increase, which will inevitably lead to exploits as security vulnerabilities are discovered.
When the latter happens, new sets of security best practices would need to be created and implemented to counter them. The good news is that unlike when the EVM (and smart contracts in general) first started, there are now far more players with expertise in Web3 technologies in the security space compared to back then. They are far more established too. It is likely that the feedback cycles will be shorter as a result, and we will see a quicker turnaround between the discovery of an attack vector and adoption of security best practices that counter each new vector.
In short: No.
Smart wallets are controlled through smart contracts in a non-custodial manner. They can be implemented using account abstraction or through other means. Account abstraction can be thought of as a lower-level concept, where smart wallets are the application and account abstraction is the underlying protocol.
Stated in another way: When the term “smart wallets” is used interchangeably with “account abstraction,” an application built using a protocol is being conflated with the protocol. This would incorrectly imply that the protocol has a single purpose.
Let’s say that the account model does not need to work in the way that EOAs do in Ethereum, and we could start fresh — in other words, design a new account model. What would that look like? What traits/behaviors should accounts ideally have in order to enable account abstraction?
Here are four necessary properties:
An account should be able to update its own cryptographic keys.
to another account, and/or
to a smart contract.
by a cryptographic key signature, and/or
by invocation of a specified smart contract.
by the same account in both cases, or
by different accounts.
If accounts in a network can exhibit all four of the above properties, that would mean that this network supports account abstraction at a protocol level. This makes it possible (and easier) for developers to build utilities in their Web3 applications for their end users: easy-to-understand and cheaper transactions, programmability/flexibility, and account recovery. The result is a knock-on effect of accelerating the adoption of Web3 technology, especially when this is available “by default” on a network, as developers do not have to perform any additional customizations to enable account abstraction.
On Ethereum, the preferred approach toward implementing account abstraction is EIP-4337. Its abstract reads as follows:
“An account abstraction proposal which completely avoids the need for consensus-layer protocol changes. Instead of adding new protocol features and changing the bottom-layer transaction type, this proposal instead introduces a higher-layer pseudo-transaction object called a UserOperation. Users send UserOperation objects into a separate mempool. A special class of actor called bundlers package up a set of these objects into a transaction making a handleOps call to a special contract, and that transaction then gets included in a block.”
Essentially, at the protocol level, Ethereum’s accounts and transaction model does not support account abstraction, and therefore, UserOperation and special contracts are needed.
Hypothetically, this would not be needed if the protocol supports the four properties in its account model, as outlined in the “What is protocol-level account abstraction?” section earlier - update cryptographic keys, delegate authorization, m-of-n multisig, and third-party transaction fees.
Let’s contrast Ethereum’s account abstraction approach with what is available on Hedera.
Simultaneously, Hedera:
Is EVM-compatible, and
Does not follow Ethereum’s account model.
This article will not detail exactly how this is possible nor how it works. Instead, please refer to my presentation: Understanding Hedera through EVM-related HIPs (press S to view detailed notes on each slide).
To summarize: Hedera launched with its own account model in 2019 and subsequently added EVM equivalence starting in 2022. This included:
Adding support for ECDSA secp256k1 keys, in addition to EdDSA ED25519 keys.
Adding an EthereumTransaction transaction type, which would “wrap” EVM-compatible transactions within the existing transaction model.
Creating an “account alias” system that would map conversions between “native accounts” and EVM addresses.
Hedera has its own accounts and transactions protocol, which exhibits all four of the properties listed earlier.
Again, this article does not intend to detail how this is possible nor how it works. Instead, please refer to another presentation: Account Abstraction on EVM-compatible networks: Hedera and Ethereum (press S to view detailed notes on each slide).
To summarize: Check out the following two code demos that illustrate how to perform protocol-level transactions on an account to transfer fungible tokens, which is one of the key uses cases for smart wallets:
multisig-account: How to use native m-of-n multisig with cryptographic keys to authorize transactions.
multisig-sc-account: How to use native m-of-n multisig with a mix of cryptographic keys and smart contracts to authorize transactions.
In effect, the primary difference is that the native account and transaction models on Hedera are designed to allow accounts to be separate from their cryptographic keys. This breaks the fundamental limitation of the EOA concept from Ethereum, which involves 1-to-1 mapping from cryptographic keys to accounts.
The implication of this is that almost all of the required ingredients for account abstraction are already present in Hedera.
This poses an interesting challenge for Hedera. While the network has been around much longer, it became compatible with EVM about two years ago — as opposed to Ethereum, which included EVM since its inception. This has a knock-on effect. In this case, when implementing account abstraction, should Hedera follow the path trodden by Ethereum (such as EIP-4337)? Or should Hedera tread its own path that leverages its fundamentally different account model? We welcome the community’s thoughts on the pros and cons of each approach.