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
II. ETHEREUM ACCOUNTS
A. Recall Ethereum Account
EOA. EOAs serve the purpose of storing and transferring ether, and ERC-20 tokens. EOAs are generated from a public key, which is a 20-byte hexadecimal identifier (e.g., 0xF57D1D6b84db4053cE452B35B7DB77878dCbdc65). These accounts are managed by a private key, which includes the EOA’s password or seed phrase, held exclusively by the account’s owner. Transactions involving EOAs do not rely on code or smart contract logic for their validity. As long as the private key remains known, the account’s owner possesses the capability to execute transactions. The transaction’s verification is contingent upon the user’s signature and nonce.
Contract account. CA is a type of account that executes operations based on its pre-programmed logic, thereby enabling the creation of decentralized applications (DApps) and facilitating various functionalities within the Ethereum network. CA autonomously executes code in response to transactions, potentially modifying the contract’s state, and exchanging ether or tokens. CA accounts are assigned unique addresses akin to individual identification numbers, which permit interaction with other accounts. Once a CA is deployed, its code and state become immutable, contributing to transparency and ensuring the integrity of transactions. They also offer storage capabilities for manipulating data on the blockchain (Fig.1). These accounts can interact with EOAs and generate events that facilitate communication with other accounts.
Two types of transaction. These different accounts give rise to two distinct practical types of transactions for communication: contract creation and message call. Contract creation involves the generation of a new smart contract, with the transaction carrying an initialization code segment to define the new contract’s properties. This process results in the assignment of a unique address to the newly created contract, which includes both its code and storage within the corresponding account state. Conversely, a message call signifies the modification of a smart contract’s state. In this case, the transaction includes input data to update the contract’s internal data. A message call does not create a new contract in the world state; instead, it alters the existing contract’s state.
B. Challenges in Account Design
Coming with private keys, EOA has many fundamental functions including claiming the ownership of the account and signing the permissions of transactions. However, this may present a number of significant concerns:
• Risk of private key loss. Users who lose their private keys (due to loss or hacking) would face the irreversible loss of all their assets.
• Restricted signature options. The native protocol exclusively supports ECDSA signature and verification algorithms for transaction validation.
• Single signer authority. The absence of inherent multisignature capability (which can only be achieved through smart contracts) means that a single signature is all that’s required to execute any operation.
C. Ethereum Roadmap
Account abstraction is a crucial functional improvement outlined in the sixth phase of Ethereum’s roadmap (Tab.I). This upgrade involves a series of smaller refinements and adjustments aimed at ensuring seamless network operations subsequent to the implementation of other upgrades.