Account Abstraction on Everscale vs. Ethereum

This article compares and contrasts two different approaches to providing Account Abstraction functionality.

Note: We will use two abbreviations throughout this article. One for Account Abstraction: AA, and one for externally owned accounts: EOA.

Reminder: Currently, there are only two types of on-chain accounts: EOA and AA.

Ethereum’s limitation: no built-in AA functionality

By protocol architecture, all crypto wallets on Ethereum are Externally Owned Accounts (EOA), which entails huge limitations. With EOA accounts, users have to rely on wallet private keys for access and all transactions have to be signed. As a result, crypto wallet setup procedures and private key security measures are exceedingly complex and not user-friendly. For example, if a user loses their recovery seed phrase, it usually means they lose access to the wallet without the possibility of recovery (so the funds are lost as well). To solve this issue, back in 2021, Vitalik Buterin together with some other developers proposed an Ethereum Improvement Protocol (EIP 4337). Its purpose was to supply Ethereum wallets with some form of Account Abstraction functionality. Already this year, in March, the protocol was successfully deployed on the Ethereum mainnet and is expected to lead to the roll out of more user-friendly crypto wallets. However, considering the protocol’s complex structure and interaction mechanics, the results for end-users remain to be seen.

What is EIP 4337?

EIP 4337 is a specification or protocol that aims to use an Entry point contract to provide Account Abstraction functionality without changing the consensus layer protocol of Ethereum. Basically, it is a separate transaction system that runs in parallel to the existing protocol.

EIP 4337 is a difficult read. In particular, it is tough to comprehend the reason why there are so many participants and why they interact the way they do. To simplify things, we have put together a visualization of how it works.

EIP 4337 high-level scheme

Some definitions for EIP 4337 (please familiarize yourself with them so you can easily understand what is happening in the animations below):

UserOperation (op) — an entity that describes a user’s transaction intent. It can contain any instructions to execute smart contract calls initiated by the Smart Contract Account. It differs from an ordinary crypto transaction in that it is sent to a separate UserOp mempool and the authentication is programmable compared to signature based authentication (single private key) for ordinary crypto transactions.

• Sender (users) — the contract that sends UserOps. It should be mentioned that users refund the Bundler for the gas fee spent. For this, users must have a deposit on the Entry Point smart contract.

• Bundler — a node that packs many UserOps and creates an EntryPoint.handleOps transaction. Note that not all nodes on the network have to be Bundlers.

• Entry Point — the contract that executes bundles of UserOps.

• handle Ops — the method that checks whether the crypto wallet has enough funds to pay the max transaction fee the UserOp could possibly use. If not, then the Op is rejected.

• validate Ops — the method for UserOps validation. Any UserOp that fails validation will be removed.

• execute Ops — the method that tracks how much gas a UserOp uses, then transfers ETH to the Bundler to pay for that transaction fee.

EIP 4337 UserOp flow

Flexibility: gas fee payment in any ERC 20 token

To enable flexible gas payment policies, there is a special smart contract called Paymaster. With its help, instead of paying gas fees for Ethereum transactions in the native ETH token, users can pay transaction fees in any ERC 20 token, including USDT, as demonstrated in the animation below.

Everscale’s built-in Account Abstraction functionality

As for Everscale, there was no need to think of complex parallel systems enabling AA. This is due to the fact that it was built into the core protocol from the beginning. You will recall that everything in Everscale is a smart contract with which users can interact by sending External Messages. That is all there is to it. It is a simple enough concept, but the flexibility it provides puts Everscale in a class of its own among blockchains. We have put together several animations below that illustrate how a number of the most common use cases are made possible owing to Everscale’s AA.

Illustrating Everscale’s Account Abstraction in Action

Use cases

Social Recovery: enhancing wallet access

Customize other accounts so you can authorize new devices in case you lose access to your wallet.

Setting limits: control over token transfers

Set daily, weekly, monthly, or any other limits for how many tokens can be transferred from an account.

Blacklist addresses: avoiding undesirable interactions

Prohibit transactions to addresses you don’t want your wallet to interact with. For instance, sanctioned addresses.

Multisig

Share spending responsibilities with business partners or family members. This is particularly useful if you have a shared account and want unanimity on large crypto transactions.