A Synergistic Approach To Account Abstraction With Virtual Account

AELF’s Virtual Account (VA) brings accessibility and affordability to account abstraction

ælf
aelf
5 min readNov 9, 2023

--

The Account Abstraction (AA) wallet is a breakthrough that will bring blockchain and dApps to ordinary users by eliminating the requirements of backing up private keys while introducing web2 login, social recovery and programmable transactions.

In the Ethereum ecosystem, there’s a proposal called ERC-4337 that specifies how account abstraction can be achieved on Ethereum. However, it’s not the only way to realize account abstraction, especially on a non-Ethereum blockchain with other unique features.

This article will provide an introduction to a concept called virtual account on AELF, how it helps to implement account abstraction and what the differences are in the operations of abstract accounts on AELF and Ethereum.

What is a virtual account?

In most other blockchains, there are two types of accounts: Externally Owned Accounts (EOA) and smart contracts, each with a distinct address. Both EOA and smart contract accounts can be thought of as agents that can interact with one another on the blockchain.

We can understand their similarities and differences by identifying:

  • Whether the account can serve as a caller to call other accounts.
  • Whether the account can serve as a callee.
  • Whether the account can initiate transactions.

Both the EOA and smart contract can serve as a caller, but only the smart contract can serve as a callee. On aelf, there’s another type of account called a virtual account. Think of it as an extension to a smart contract account. Let’s delve into the defining features of virtual accounts below:

  • Virtual accounts are created and managed in a smart contract and can be thought of as sub-accounts within a smart contract account.
  • Virtual account addresses are derived from the smart contract address.
  • There can be multiple virtual accounts in a smart contract account. We just need to use some unique IDs within the context of the host smart contract to derive the addresses of the virtual accounts.
  • The permission for virtual accounts is governed by the shared smart contract code. In comparison, each smart contract account has its own code.

Similar to smart contract accounts, virtual accounts can also serve as a caller. However, unlike smart contract accounts, virtual accounts can not serve as a callee.

To make the comparison complete, one last point to be discussed about the three types of accounts is whether they can initiate transactions. Among the three types, only EOA is capable of doing so. If smart contract accounts or virtual accounts want to interact with other contracts, an EOA is required to trigger the transaction.

How is a virtual account constructed?

Let’s dive deeper into how virtual account addresses are derived from the host contract address. The address for a virtual account can be constructed in the following way:

virtualAddress = Address.FromPublicKey(Hash(contractAddress | virtualHash))

where virtualHash is a unique ID of the virtual account within the context of the host smart contract, and it can be constructed in any unique way defined in the smart contract. For example:

virtualHash = Hash(txId | prevBlockHash)

How do the three types of accounts call a contract?

The following diagram depicts how the three types interact with a hypothetical Token Swap contract. Note how the sender has different addresses when the call happens.

Figure 1: Accounts on AELF

Implications of virtual account mechanism

Understanding how virtual accounts work, let’s explore their implications on abstract account-related operations, specifically abstract account creation and transaction processing flow.

Abstract Account Creation

Figure 2 illustrates how an abstract account can be created following the ERC-4337 proposal in Ethereum, while Figure 3 demonstrates the process on AELF, where the abstract account is created using the virtual account mechanism.

Figure 2: Abstract account creation under ERC-4337 proposal

Source: https://www.erc4337.io/docs/understanding-ERC-4337/architecture

Figure 3: Abstract account creation on AELF

Key Differences:

1 . Simplicity: Account creation on AELF is straightforward, resembling a regular transaction without additional complexities. This is thanks to the shared code mechanism used in conjunction with the virtual account system. When a new account is added, it shares the same contract with other accounts, akin to a multi-tenant SaaS service, ensuring separate management of each tenant’s state.

2 . Cost: Account creation costs are significantly lower on AELF, allowing wallet operators to absorb the expenses, making it entirely free for end users. In contrast, Ethereum-based account creation can cost substantially more.

3 . Speed: Account creation on AELF is markedly faster, requiring fewer steps. While Ethereum account creation can take 10 to 20 minutes, AELF account creation is a matter of seconds.

Table: Gas fee estimates for ERC-4337 transactions

Source: https://www.stackup.sh/blog/how-much-more-expensive-is-erc-4337

(1)https://etherscan.io/chart/gasprice (2)https://polygonscan.com/chart/gasprice (3)https://optimistic.etherscan.io/chart/gasprice
(4)Optimism fee range is estimated by applying one standard deviation to both Ethereum Mainnet and Optimism gas fees
(5)
https://snowtrace.io/chart/gasprice
(6)Avalanche gas is slightly different than Table 1. This table uses the measured gas on Avalanche to compute the fee.
(7)
https://bscscan.com/chart/gasprice

Abstract Account Transaction Flow

Figure 4: Abstract account transaction flow under the ERC4337 proposal
Figure 5: Abstract account transaction flow on AELF

Figure 4 illustrates how transactions for abstract accounts are processed according to the ERC-4337 proposal, while Figure 5 depicts the process on AELF.

In ERC-4337, the process involves creating UserOperation pseudo-transaction objects, sending them to a UserOperations mempool, and bundling UserOperations. An aggregator combines multiple UserOperation signatures into a single signature, and an EntryPoint singleton contract verifies and executes bundles of UserOperations.

Conversely, on AELF, users only need to send a wrapper transaction that passes through the AccountKeeper contract to interact with target contracts, eliminating the need for an additional mempool. This streamlined process is more cost-effective.

The following table summarizes the flow.

Conclusion

In conclusion, AELF’s virtual account innovation represents a pivotal step in the evolution of blockchain technology and a significant leap in abstract account operations. AELF’s VA simplifies account creation, reduces costs, and streamlines transactions. This breakthrough offers users enhanced security, efficiency, and convenience, in managing their digital assets.

--

--

ælf
aelf
Editor for

ælf, the next breakthrough in Blockchain.