This paper is available on arxiv under CC 4.0 license. Authors: (1) Qin Wang, CSIRO Data61, Australia; (2) Shiping Chen, CSIRO Data61, Australia. Table of Links Abstract & Introduction Ethereum Accounts Account Abstraction Security Analysis Further Discussions Conclusion & References III. ACCOUNT ABSTRACTION A. Previous Attempts A series of continuous efforts have been made to make existing accounts extensible with more functions. We list a series related token standards in Tab.II. In Ethereum’s early phases, attempts were made to distinguish between EOA and CA by introducing various new transaction types. EIP-86/208 leverage the differentiation between two accounts to design customizable and collisionresistant contract addresses. This, in turn, led to the implementation of EIP-1014 and EIP-2470. EIP-859 introduced transaction-initiated contract deployment. It allowed for onthe-spot deployment of contract addresses if none existed, forming the basis for the fundamental functionality of EIP4337. EIP-2718 ushered in compatibility for future Ethereum iterations with any newly suggested transaction types. EIP293 systematically cataloged various advantages of contract accounts, encompassing recovery, key rotation, customized identity verification algorithms, and meta-transactions, which collectively entrenched the role of contract accounts. However, these efforts resulted in unwieldy complexity. Altering transaction types requires concurrent modifications to the underlying signature verification algorithms. This encompasses considerations like miner acceptance of new types, ensuring incentives are not lower than regular transactions to encourage verification, and addressing concerns about account address management and conflicts. Unfortunately, this approach lacked both backward and forward compatibility. Ultimately, these attempts have coalesced around two primary directions as stated in our Sec.I. B. Account Abstraction Account abstraction introduces a suite of functions designed to personalize fundamental elements that enable smart contract functionalities. These customizations encompass various aspects, including user operations, fee payment methods, and transaction packing mechanisms. . The workflow is summarized as follows: ① Users initiate interactions with the frontend abstraction (also referred to as application) layer, where their actions are translated into underlying transactions (via UserOperation). ② Bundlers aggregate multiple UserOperation instances, consolidating them into a single transaction that is then transmitted to the EntryPoint contract. ③ Within the EntryPioint contract, user signatures are verified and transactions initiated by the abstraction layer are processed. ④ The entries logged in UserOperation prompt the activation of relevant smart contracts, initiating state transitions tailored to their specific prerequisites. ⑤ Optionally, the user’s operations can be aggregated and authenticated using BLS signatures. Meanwhile, transaction fees for user actions are managed by the Paymaster contract. Consequently, on-chain applications interact with user actions in a manner similar to their interaction with standard external accounts. Overview UserOperation serves as a transaction-like entity, representing a user’s request achieved by transaction events. Within UserOperation, multiple requests and supplementary data can be encapsulated, facilitating the execution of transactions that a CA can perform. While sharing similarities with conventional transactions, UserOperations exhibit several distinctive characteristics. ✑ User operation. UserOperation includes new fields in the transaction structure, e.g., EntryPoint, Bundler, Paymaster and Aggregator. • Additional fields. UserOperation is sent to a separate mempool, where bundlers can package them into transactions which get included in a block. • Alternate mempool. Today, transaction inputs are specific, e.g., swap 2k USDC for 1.2ETH. In contrast, UserOperation can be decorated with additional metadata to be more outcome-focused, e.g., I want to trade 2k USDC for the most amount of ETH possible. • Intent based. Bundlers constitute a pivotal component of the infrastructure necessary for the realization of EIP-4337. These entities are a specific type of Ethereum node dedicated to facilitating the processing of UserOperations. These UserOperations are directed to a network of bundlers, which diligently monitor the mempool. Bundlers efficiently consolidate multiple UserOperations into a singular transaction, expertly packaging and submitting them to the blockchain on behalf of users. In exchange for this service, bundlers receive compensation for their efforts in executing these tasks. ✑ Bundler. It is a singleton smart contract that undertakes the verification and execution of UserOperations. ✑ EntryPoint. The process checks the account balance. It involves assessing whether the wallet possesses sufficient funds to cover the maximum potential gas expenditure (derived from the gas field in the UserOp). Transactions lacking adequate funds will be declined. • Verification loop. Upon verification, the transaction will be executed. Correspondingly, an amount from CA is deducted to reimburse the bundler. This reimbursement is required to cover the gas expenses. • Execution loop. In scenarios where multiple messages are signed using distinct keys, an aggregator plays a role in producing an authenticated signature. The signature inherently validates the authenticity of all individual signatures within the collection. For accounts associated with particular signature types that enable aggregation (such as BLS), the verification process of the account’s signature is deferred to an external contract. This external contract, in turn, is responsible for verifying a solitary signature across an entire bundle, thus streamlining the validation process. ✑ Aeggregator (optional). Through the consolidation of multiple signatures into a singular entity, aggregators contribute to the efficient management of data availability. This allows for the validation of numerous bundled UserOperations in a single consolidated process. The Paymaster takes charge of implementing gas payment policies, offering developers the capability to offer their end users gas-free interactions through sponsored or ERC-20 gas policies. These policies introduce flexibility in how gas is paid, such as the choice of currency (e.g., native ETH or ERC-20 tokens), and by whom it is paid. This effectively eliminates the need for users to possess native blockchain tokens to engage with the blockchain. ✑ Paymaster (optional). C. AA Benefits Based on its design, AA brings a series of direct benefits that previous CA and EOA do not have. Capitalizing on the capabilities of the EntryPoint contract, the consolidation of multiple transactions can guard against frontrunning attacks and potential MEV threats. • Transaction batching. . Departing from reliance solely on a single signer (EOA, private key holder), AA introduces the capability of multi-signatures sourced from a spectrum of entities. • Multisig ERC-20 tokens are accepted as valid payment for these fees, unshackling the restrictions previously confined to ether (ETH). • Gas abstraction. AA is engineered to encompass a mechanism for recovery through a social network of trusted associates. This mechanism offers an alternative route to regain access to the wallet. • Social recovery. Users are empowered with the ability to craft bespoke modules catering to specific functions. • Custom module. D. AA Surroundings EIP-2771 is designed to enable gasless transactions for users by introducing the concept of metatransactions. It permits third parties to cover a user’s gas expenses without necessitating modifications to Ethereum. The standards include the following key steps: The transaction signer signs and dispatches transactions to a gas relay. The Gas Relay, operating off-chain, receives these signed requests and subsidizes the gas costs, transforming them into valid transactions that are then routed through a trusted forwarder. This trusted forwarder is essentially a contract entrusted by recipients to accurately verify signatures and nonces. Supportive standards. EIP-3047 is designed to enable users to delegate control of their EOA to a contract, a parallel approach discussed in Sec.I. This feature allows any EOA to function as a smart contract wallet without requiring the deployment of a separate contract. As part of this standard, two new opcodes are introduced to the Ethereum Virtual Machine (EVM): AUTH and AUTHCALL. These opcodes facilitate proper invocation from smart contracts. Although this standard are incorporated into future updates of Ethereum’s account infrastructure, it still provides valuable insights. EIP-6900 introduces a standard aimed at synchronizing the implementation efforts of CA developers and plugin developers. It outlines the creation of a modular CA with the capability to accommodate all plugins adhering to standard protocols. In this standard, CAs are rendered as fully programmable accounts capable of housing assets within on-chain smart contracts. In parallel, account plugins serve as interfaces for smart contracts that facilitate the integration of compositional logic within CAs. This approach enhances data portability for users and alleviates the need for plugin developers to target specific wallet implementations. EIP-6551 introduces a token standard primarily focused on NFTs [14]. This standard enables the binding of one or multiple Ethereum accounts to an NFT. By doing so, NFTs gain the capability to possess assets and engage with applications, all without necessitating modifications to current smart contracts or infrastructure. These accounts, which are associated with tokens, seamlessly integrate with existing on-chain asset standards and have the potential to encompass forthcoming asset standards. Ethereum’s abstract account model offers an enhanced approach to implementing this standard, exemplified by the Web3 game project Sapienz [15]. In light of the forthcoming updates to Ethereum, a diverse range of competitive blockchain platforms are also stepping up their game. Notable contenders such as BNB Chain, Avalanche, Optimism, Polygon, StarkNet, and zkSync have all unveiled their respective initiatives for implementing crucial updates. Supportive platforms. Complementing the infrastructural advancements, an equally pivotal component lies within the realm of wallets. Serving as the hub where users manage, utilize, and safeguard their accounts, wallets play a pivotal role. Multiple wallet service providers, including MetaMash, Argent, Beam, Safe, Trust Wallet, Braavos, and OKX Wallet, have expressed their commitment to seamlessly incorporate these anticipated updates into their products. Supportive wallet. E. Real Case Adoption . As demonstrated in [16], Visa is actively exploring a solution that leverages the Paymaster smart contract. This solution aims to abstract the core interactions of blockchain technology and enhance the user payment experience by introducing a self-custodial smart contract wallet. The primary goal is to streamline the process for users conducting transactions within their wallets. One of the intriguing aspects is that users can now use any token to pay for gas fees, and these gas costs will be covered by Paymaster. In more detail, users have the capability to make payments to the Paymaster contract using USDC. Subsequently, the Paymaster contract converts the USDC into ETH and facilitates the transaction on the blockchain network. After a period of on-chain processing, the recipient of the transaction can receive an equivalent amount converted back to USDC. As of now, this particular use case is still in the conceptual verification stage. Visa By seamlessly integrating AA into existing EOA wallets, the accounts are elevated to the status of smart contract wallets, enriched with programmable logic and functionalities. For instance, Gnosis Safe [17] brings forth a smultisignature approach, necessitating multiple authorized entities to provide signatures for the same account, rather than relying solely on individual private keys. Argent [18] introduces the concept of social recovery, enabling users to recover lost or forgotten private keys. It allows users to utilize email addresses and phone numbers for offline recovery, introducing a familiar two-factor authentication mechanism. Users in Braavos [19] can access their wallets using the biometric features of their smartphones, such as facial or fingerprint recognition, adding an extra layer of security. Web3 wallet.

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

Account Abstraction, Analysed: Account Abstraction

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Account Abstraction, Analysed: Abstract & Introduction

Abstracting Away Account Abstraction on Polkadot

Account Abstraction Could Be The Next Big Thing in Web3

Account Abstraction: Solutions for L1 & L2 Layers and Current State of Adoption

Blockchain Mass Adoption and Exciting Brand Experiences With Account Abstraction: ERC-4337

EIP-4337 Based Account Abstraction: Why It Won't Work for Institutions

Account Abstraction, Analysed: Abstract & Introduction

Abstracting Away Account Abstraction on Polkadot

Account Abstraction Could Be The Next Big Thing in Web3

Account Abstraction: Solutions for L1 & L2 Layers and Current State of Adoption

Blockchain Mass Adoption and Exciting Brand Experiences With Account Abstraction: ERC-4337

EIP-4337 Based Account Abstraction: Why It Won't Work for Institutions

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps