Why Account Abstraction Paves The Way For Better UX and Security
EIP 4337 is no longer a theoretical proposal. We’re working on solution-compatible smart account implementation, txn bundling, gas abstraction & more!
Abstraction takes the tech behind the scenes while the users engage with their chosen dApps via simple gestures. Abstraction has been a perpetual theme of any system’s evolutionary history, and as such, it has been repeated several times before. In the preliminary days, programmers wrote in assembly code and evolved to more complex and intuitive (high-level) languages and compilers that eliminated most of the machine trifling.
Similarly, we evolved from individual management of hardware systems into the program to operating systems (middleware) delegating the cumbersome tasks; then came hardware virtualization, the cloud, and the applications that were made live on the cloud. Last but not least, the internet also evolved from a few protocol layers (TCP/IP) to the application layer and HTTP, FTP, SMTP, etc.
As you can see, abstraction in systems has always been the starting point of a new evolution, and blockchains, including the Ethereum network, are no different. In the case of the Ethereum Network or Web 3 in general — the system is most likely to evolve from Account Abstraction or smart contract accounts.
A Primer on EOA and Its Limitations
Ethereum currently features two types of entities — EOA (Externally Owned Account) and Smart Contracts.
EOA is the blockchain address controlled by the user’s key pair (public and private). A user generated their EOA by creating a keypair and extracting an address (cryptographic signature) from the chain. There are several ways to generate an address using keypairs, and in Ethereum’s case, it uses a scheme called the ECDSA.
The user controls the key pair, and it can sign transactions from the given address, but there’s a tradeoff. The tradeoff is that the key is the account, which means the user cannot authorize another key for a given address. Losing your key is losing your account. Another argument would be to use a hardware wallet along with your EOA wallet. Just like EOA gives a quasi guarantee that no one will actually ever lose their keys, the hardware wallet solution is a hardship to sell, considering the UX aims to also serve billions of non-technical users who are habituated with the straightforward Web UX.
Additional Limitations of the EOA Include:
On Ethereum, the sender is authenticated using two specific cryptographic algorithms (Secp256k1) and (Keccak256). To create a valid transaction, the user’s wallet implements these two algos and also finds a secure way to manage the keypairs. This sender algo was extremely convenient for designers, but it introduced an additional obstacle for interacting with the network without the Secp265k1 support.
The EVM currently has several cryptographic primitives at its heart — for instance, the ECDSA sign verification. But what if the client wants to implement a different signing scheme than ECDSA? It’s not yet a possibility to code custom logic here.
Last but least (also take this argument with a grain of salt coz Quantum computers aren’t a thing yet, and won’t be for a little while more) — it is speculated that in the near future, Quantum computing might break EDSCA encryption, which could make a transaction on Bitcoin and Ethereum network unsafe and outdated.
At first glance, these design choices may be too obscure for non-technical users. Still, they are of high consequence as much as the consensus algo or other economical parameters of the Ethereum network. The community has spoken about the challenges of using an EOA, not just from the POV of buildoors but also from the users.
UX Problems for Non-technical Users
Using an EOA to execute transactions means using a private key to sign the transaction with an ECDSA sign. Then send it to the Ethereum network, where miners include it into a block. To do that, users have to pay a gas fee in no other than the native currency, ETH. This fee is then paid to the miner and burned according to the EIP1559 protocol.
Moreover, since actions are tied 1:1, not being able to perform batch transactions means more cost and a highly stretched-out UX.
Clearly, these specific design choices have become more complex than the dApps being built on top of the blockchain, and no optimal alternative exists to nip the bud at this level.
A solution presents itself if we remove ourselves from finding better alternatives to these design choices and go back to the initial idea of generating new abstractions — doing away from EOA and allowing smart contracts to be programmed the way the client wants.
The Solution
Account abstraction (AA) allows EOA accounts (wallets) into smart contracts, which can be programmed to use their own logic to verify transactions by decoupling the signer from the account. This gives buildoors a stronger foundation to build mutable applications with better UX and security.
AA can enable the development of powerful dApps that can truly be used by everyone and anyone without losing custody. It facilitates scalability to onboard billions of users with fast and cheap transactions (or gas-free transactions) while offering unrivaled UX that creates a user experience.
- Superior Key Management or No Keys Needed
AA allows the user to change the wallet’s key or even use multiple signing keys for the same wallet. In the long run, account abstraction can potentially eliminate the need for private keys, passwords, confirmation times, transaction fees in native assets, etc. Quite frankly, it is the key to a truly frictionless and secure Web 3 experience, especially at the transactional level.
- Social Recovery Enabled Wallets Will Become the Standard for Securing Large Amounts of Capital
Social recovery stands at the core of offering a better UX in Web 3. For all user classes managing passwords has always been a tandem. In Web 2, if you forget your password, you’re relying on a centralized party like your banking service to recover it. Social recovery eliminates this as it allows you to access the account by simply asking your friends and family to recover it for you. Implementing social recovery to wallets by enabling a majority of authorized guardians to cooperate with each other and manage the signing key of a user’s wallet. The same key could be used to remove or add the said guardians with a time delay. The bigger picture is much more nuanced, but the essence remains the same, abstracting away the reliability of rudimentary security patches and providing a much higher level of security via a simple interface.
- Another Angle to Social Recovery and Key Rotation is Improved Security
Two or more users can be implemented to approve a single transaction for improved security. An emergency account hold feature could be implemented to allow an account to be locked or access from a specific address deactivated or on a more crazy spectrum — the funds transferred from that account to another account if malicious activity is detected. A transaction limit can be set to prevent human error, similar to traditional banking accounts or payment apps, to help buffer errors or prevent the complete draining of a wallet due to an exploit. Users can specify transfers to be made only to known addresses that prevent phishing attacks.
- Better UX for Blockchains Games With Micro-economies and a fertile design Space for Building on-chain Guilds
Play-to-earn games are one of the most striking verticals that will benefit greatly from account abstraction. In-game assets are an important part of a huge and unified marketplace. For P2E games, a primary business is to create the gaming experience.
At the same time, the gaming UX depends on the identity of the on-chain assets. Players interact with the game for the UC on the one hand and to capture in-game assets by playing the game on the other hand. The player’s private key controls the assets on the network. That is all very cool but imagine this — the more the density of in-game assets, the more the players drive to build — imagine trying to play a competitive game while also approving your hundred or something micro MetaMask transactions.
Account abstraction allows builders to develop guild wallets for depositing and withdrawing items, facilitate guide administration, and wallets customized for accessing on-chain game environments.
- Atomic (batch) Transactions
AA allows users to pay for a transaction in a different currency (for example, any other ERC 20 in the Ethereum network or L2) while not holding any ETH or that L2’s native currency or knowing anything about it. When done on an L2, this transaction for being settled in seconds.
AA Could Pave The Way For Use Cases:
- Developers are not limited to the Blake2b and Secp256k1 authentication options;
- Assortment of signature verification options besides ECDSA, including post-quantum algorithms;
- Virtual machines running in the same environment as smart contracts created by application developers, with no special requirements;
- NFTs that are also wallets
- Our grandmas wouldn’t have to read an article such as this on AA that she has no idea about to execute a transaction on a chain.
So if everybody knows that AA is revolutionary for both UX and security, why hasn’t it been implemented yet?
Good question…we’ll talk about it in our next article.
