Written by: Gal Ron, stanford blockchain review
Compilation: Deep Tide TechFlow
*Note: This article comes from the Stanford Blockchain Review, and TechFlow is a partner of the Stanford Blockchain Review, and is exclusively authorized to compile and reprint.
"No private keys, no tokens!" This is the slogan of the blockchain. But what exactly is a "private key"?
Keys in the real world change according to the function they serve. The key for the bike lock is not the same type as the Brinks van high security key.
However, on Ethereum, all keys have the same structure. Any operation on Ethereum—regardless of its value or purpose—requires a transaction to be signed using a Seed Phrase. Moreover, the content of the Seed Phrase should only be mastered by the account owner. This is a significant UX hurdle and one that hinders mainstream adoption of cryptocurrencies.
Account abstraction helps blockchain applications move away from this paradigm . The concept of account abstraction, first introduced by Vitalik in a 2015 article, is now being implemented on Layer-2 blockchains such as Starknet and zkSync, and on Ethereum itself via EIP-4337. Combining the power of Web3 with the simplicity and comfort of Web2, Account Abstraction is an important milestone towards extended self-custody.
EOA on Ethereum and its limitations
First, let's review how crypto accounts on Ethereum work. Ethereum has two basic entities: smart contracts and EOAs (externally owned accounts).
EOA is an entity with the following characteristics:
(1) The account address derived from the private key,
(2) ETH balance used to pay fees or send Ether to others,
(3) An identifier called a "nonce" used to record the sequence number of transactions sent from this EOA for replay protection.
On Ethereum, only EOAs can send transactions . In order for a transaction to be valid, it must be signed with a private key derived from the account address. This means that "owning" an EOA actually means owning the private key used to derive the account address.
Although smart contracts on Ethereum are fully programmable, the logic used to verify the validity of transactions is not programmable, but hard-coded in the EVM (Ethereum Virtual Machine). A valid transaction must strictly follow a set of rules, such as:
signature scheme . Transactions must be signed on the elliptic curve secp256k1 using the ECDSA signature scheme.
transaction fees . The source of the transaction fee must be the same EOA that initiated the transaction. Additionally, transaction fees must be denominated in ETH .
Replay protection . Transactions must be sent sequentially by the sequence number of their "nonce" identifier.
Private keys are immutable . Since the account address is derived from the private key, it is impossible to change the "secret" used to sign the transaction.
These rules are embedded into the Ethereum protocol and cannot be changed. They stem from design decisions aimed at optimizing protocol security and the operating efficiency of Ethereum nodes. However, they limit many use cases for Dapp developers. For example, it is not possible to have another account pay for your transaction fees when using EOA. This is a valuable feature for decentralized games that may wish to fund the first few "moves" of each player.
In other cases, blockchain users may wish to authorize other users to send transactions on their behalf, perhaps setting some limits on transaction value or frequency. This is also not possible with EOAs.
Also, in Web2, password rotation is a basic primitive, but it's not possible to change the EOA's password, or count on other entities to help you recover your password without giving them full access to your account.
account abstraction
Account abstraction is a way of decoupling the above hard-coded logic from EOA, turning all accounts into fully programmable smart contracts. This will give account owners, wallets, and Dapp the flexibility to determine how transactions should be signed and accepted, and where transaction fees come from. In other words, account abstraction is the technical infrastructure for implementing smart contract wallets .
The concept of account abstraction can be divided into three categories, corresponding to the three main limitations that exist in current EOAs:
(1) Signer abstraction . Instead of enforcing the ECDSA scheme and fixed private key as the only acceptable signatures, smart contracts are given the flexibility to determine what a validly signed transaction is. This means that smart contracts can, at their discretion, accept other signature schemes, such as ones that are more suitable for sharing secrets. Contracts can also require different signature schemes for different entry functions, or even require no signature at all.
(2) Cost abstraction. On Ethereum, the first thing an account owner needs to do is fill the account with some ETH in order to pay transaction fees and start using the account. Imagine a blockchain architecture where Dapp could fund their users' transaction fees, or let users pay fees in whatever token currency they wish (and do ETH swaps on the fly); this would solve a significant UX facing Ethereum today challenge.
(3) Nonce abstraction . This is a less discussed but more subtle area of account abstraction, but no less interesting. The "nonce" identifier on EOAs provides protection against transaction replay, but it also enforces an inherently sequential transaction model. What if a smart contract wants to accept two parallel transactions from the same EOA, regardless of their order? This becomes possible when the "nonce" mechanism can be controlled by a smart contract rather than being hardcoded into general transaction processing logic.
Extended self-hosting
15 years after the Bitcoin Whitepaper was published, today's crypto wallets still require high maintenance rather than the fluid products we expect. Last year's CEX debacle taught us that self-custody is the way to go, but managing your own private keys is still a significant burden and security risk . Even hardcore crypto developers occasionally lose their private keys or have them stolen (tweets). Smart contract wallets operating through account abstraction could be the catalyst to remove these risks and drive mass adoption of self-custodial wallets. Account abstraction makes account management easier through two mechanisms: smarter transaction signing and better recovery processes .
First, the signer abstraction allows wallets to embed Web2 functionality into their products . For example, the Braavos wallet leverages the secure compartment of iOS and Android devices to allow users to sign transactions using fingerprint or face ID without entering any Seed Phrase at all. Similar signer abstraction capabilities allow developers to control the level of security required to approve individual transactions on a case-by-case basis. This paves the way for true multi-factor authentication for Web3 wallets. Similar to your online bank account, everyday transactions can be performed from a single device, but performing a transaction to a new recipient or performing a particularly valuable transaction may prompt the user to sign up on multiple devices.
Account abstraction also improves the UX of account recovery . The signer abstraction allows having multiple signers for an account, each with individual powers and privileges. For example, the primary owner of an account could share some lower-privilege keys with a friend, in a way that the friend can help recover the master key but cannot spend any assets in the account. This is commonly referred to as social recovery and has been implemented in smart contract based wallets such as the ArgentX wallet.
Opportunities for Crypto Payments
Cryptocurrency payments are widely discussed as one of the main use cases of blockchain. However, this promise has not been fulfilled. Historically, this was due to expensive transaction fees, but with the advent of convolution and scalability solutions, these fees are now falling. However, the success of well-established payment solutions in traditional finance goes beyond low transaction costs. They require additional functions such as credit issuance, fraud detection, dispute handling and recurring payment mechanisms.
Account abstraction allows these traditional payment concepts to be translated into the cryptocurrency realm. For example, Visa recently presented a proof of concept for using account abstraction to design a recurring payment system. Imagine a programmable self-custodial wallet that could authorize Visa to automatically transfer funds (up to a limit) at regular intervals without requiring a user's signature on each transaction.
When Game UX Meets Web3
The abstraction of batched transactions and fees makes Web3 games another area that is vulnerable to account abstraction.
The main hurdle to bringing gaming activity on-chain is that every on-chain activity needs to sign a transaction, which can outweigh transaction costs. Prompting the user to click the "Sign" button in the wallet breaks the flow of the game and makes the Web3 gaming experience rather cumbersome.
The account abstraction allows game developers to create "session keys" that are pre-authorized to sign game transactions for a specific period of time. These keys can be stored in the browser or in the smartphone's local storage and revoked as needed. This will bring the Web3 game gaming experience closer to that of a Web2 game.
Additionally, the fee abstraction allows game developers to subsidize transaction fees for their users. This is especially effective for attracting new players, who may not be familiar with cryptocurrencies, or want to try the game first, and pay transaction fees after learning about the game experience.
road ahead
Account abstraction has always been part of the Ethereum roadmap. Ethereum Improvement Proposals, such as EIP-86 (2017), EIP-2983 (2020) and EIP-3074 (2020), paved the way for EIP-4337 (2021), which introduced a new foundation for decentralization Facility for operating smart contract wallets.
In addition to EIPs, smart wallet Dapp like Gnosis have popped up on Ethereum. However, all of these are second-class citizens of Ethereum's native account model, the EOA.
The opportunity to solve the limitations of Ethereum and bring smart contract wallets to users may be realized through Layer 2 scaling networks. Layer 2 like Starknet and zkSync embed account abstraction at the protocol level, making it easily accessible to developers through native tools and infrastructure.
