Everscale

Meta description: Learn about Everscale’s use of Account Abstraction, accompanied by helpful animations. Dive into Everscale’s implementation of Account Abstraction, including multisignature functions, batch transactions, session keys, and social recovery. Explore the EIP-4337 protocol and its impact on Ethereum’s Account Abstraction functionality. Learn about the transitions from EIP-86 to EIP-4337 and how EIP-4337 upgrades Ethereum and the role of Paymasters in transaction sponsorship.
This article continues the analysis of Ethereum’s ‘’Three transitions’’ by examining the long-awaited EIP-4337 protocol which, along with its Paymasters extension, upgrades the Ethereum blockchain with a major part of Account Abstraction functionality and partially achieves one of the transitions outlined by Vitalik Buterin. As for Everscale, Account Abstraction is embedded in blockchain’s core protocol from scratch. Therefore, to fill in the space left, we will supply readers with Account Abstraction most common use cases illustrated with the help of animations and schemes.
<img src="https://miro.medium.com/v2/resize:fit:1050/0*ExQUwe41sN3pEH4s">
Note: There was a long and tedious way involving several EIPs before Ethrereum succeeded to propose a viable solution for Account Abstraction functionality that fits the architectural construct of its blockchain.
Some definitions for a smoother navigation throughout Ethereum’s stages to EIP-4337
Account Abstraction — a new paradigm allowing programming blockchain accounts. It provides something incredibly convenient for the user — a Smart Account.
Smart Account — a type of account that is programmed using a set of rules and conditions. Smart Accounts can perform any programmed actions automatically without the need for human intervention.
EIP — the abbreviation for ‘Ethereum Improvement Proposal’. Each proposal includes the methods according to which updates are made on the Ethereum blockchain.
Nonce — the abbreviation for the ‘number used once’. A randomly generated number proving that a function or value was used only once.
ECDSA signature — the abbreviation for ‘Elliptic Curve Digital Signature Algorithm’. This is a variant of the Digital Signature Algorithm (DSA) which uses elliptic-curve cryptography.
AUTH — an EVM instruction that sets a context variable authorized based on an ECDSA signature.
AUTHCALL — an EVM instruction that sends calls in the same vein as an authorized account.
Both AUTH and AUTHCALL — basically delegate control of an EOA to a smart contract.
Paymaster — a special smart-contract that enables a number of use cases, such as, sponsoring transactions for other users or paying fees with any ERC-20 tokens.
The path towards EIP-4337
EIP-86 — abstraction of transaction origin and signature
The first attempt to provide Account Abstraction functionality for Ethereum. It sought to implement a number of changes to abstract out both signature verification and nonce checking. Basically, this allows users to create Account Contracts performing any desired signature/nonce checks. At the time, it was a considerable breakthrough even if it did not provide AA functionality in its entirety. The protocol just offered an alternative to using the already established mechanism hard-coded into transaction processing. Within the realm of this model, all accounts became contracts with the ability to pay crypto gas fees. Also, users were able to adjust the account security and implement their desired signature/nonce scheme.
EIP-2938 — a limited version of Account Abstraction
The second attempt provided for a limited version of Account Abstraction. Namely, it did not succeed in removing EOAs and did not support several important features of Account Abstraction such as nonce abstractions and meta transactions. On the positive side, the proposal allowed smart contracts to function as EOAs, providing them with the opportunity to initiate transactions and pay for gas. To accomplish this, the devs introduced a new type of transaction as well as two new opcodes. Transactions of this type are dubbed “AA transactions” and their payload includes three fields: nonce, target, and data. In this model, data represents all parameters that the account abstraction contract must execute and the transaction must validate, while the target represents the smart contract with the logic to validate transactions.
EIP-3074 — allowing EOAs to delegate control to a contract
The third attempt took a different path compared to its predecessors. Instead of converting smart contracts to EOAs, the proposal tries to adapt EOAs by adding a few changes to make them behave like smart contracts. This is achieved by the introduction of two EVM instructions: AUTH and AUTHCALL. The proposal sought to allow users to hand over control of their accounts to a contract by signing a message with their account. With the signed message and two new opcodes, the target smart contract could initiate transactions in the EOAs instead.
The main focus of EIP-3074 has to do with transaction sponsoring and multicall execution. This would have allowed users with EOA accounts to enjoy the benefits of account abstraction without creating new accounts. The proposal achieved AA flexibility to a great extent. However, it did not eliminate the security concerns. Notably, within the realm of this proposal, users still have to back up their seed phrase.
EIP-4337 — enabling a big chunk of AA functionality
The most recent attempt is a complex structure which succeeds in simplifying the creation and management of Smart Accounts. Contrary to previous proposals, the implementation of EIP-4337 does not require any Ethereum consensus layer changes. Instead, this is realized by the division of the load across on-chain and off-chain infrastructure. The protocol is a U-turn compared to previous attempts and therefore needs to be explained in detail.
Some definitions to understand how EIP-4337 works
UserOperation (op) — an entity describing a user’s transaction intent. It can contain any instructions to execute smart contract calls initiated by the Smart 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 network nodes 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 network 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 crypto transaction fee.
EIP-4337 enables users to send UserOps to a separate UserOp mempool. Bundlers (validators) pick UserOps (bundlers can select and process first those UserOps that offer more gas), pack them into a single transaction and send it to the Entry Point contract. The Entry Point executes the transaction and compensates the bundlers duly. To compensate bundlers, each user must deposit some funds into the Entry Point contract. The animation below illustrates how it actually works.
<img src="https://miro.medium.com/v2/resize:fit:1050/1*tasboqDoiSMWMBfVhkgJcg.gif">
EIP extension with Paymasters
Paymasters are special smart contracts that extend the Entry Point logic, enabling a number of other use cases. One of them is transaction sponsorship, which allows third party participants to pay for crypto transactions. However, as happens with most technological improvements, there are issues that remain unresolved or, in some cases, new ones are triggered. As mentioned in <a href="https://eips.ethereum.org/EIPS/eip-4337" rel="noopener noreferrer nofollow">EIP-4337 documentation</a>, Paymasters have two fundamental limitations:
<ol>
 <li>No possibility to accept fees on some ERC-20 tokens at an exchange rate pulled from an on-chain DEX.</li>
 <li>Significant risks of Paymasters’ exploitation. For instance, users could send UserOps that appear to pay the Paymaster but then change their behavior after a block.</li>
</ol>
Let’s see how Paymasters can connect decentralized and traditional infrastructures
The animation below demonstrates a scenario where customers want to make purchases on a merchant’s website. They want to transfer 100 dollars but only have ERC-20 tokens (USDC) in their wallets. In this case, a Paymaster smart-contract plays the role of an exchanger. It rids customers of the need to hold native tokens exclusively for paying network gas fees. For this, the Paymaster does the following three things:
1. accepts USDC as network transaction fees from the user
2. pays ETH as transaction fees to the blockchain
3. enables the merchant to receive payment in an ERC-20 token like USDC
<img src="https://miro.medium.com/v2/resize:fit:1050/1*DC9curibwPIxXtuOcRAuCA.gif">
EIP-4337 drawbacks
Several technical issues in the application stack still have to be worked through.
Increased vulnerability to DDos attacks: This is due to the verification logic being more complicated than in a regular Ethereum mempool.
Increased gas costs: UserOps require more gas units compared to normal crypto transactions. However, in most cases, this is compensated by batch transactions.
One transaction at a time: Smart accounts cannot queue and send multiple transactions to a mempool. Again, in most cases, this can be compensated by the ability to execute batch transactions.
Backward compatibility: Existing (old) accounts cannot be switched to Smart Accounts.
Everscale’s AA in action
Let’s examine some use cases that offer a unique value proposition for users and can easily be implemented in Everscale.
With Everscale, you can have protection similar to traditional banking or even better
Multisignature is one of the most convenient functions, especially for the management of family funds and business deals. For example, family members decide to set a threshold on purchases. In this case, each purchase above the amount set would require the approval of all family members (you can see how it works in the animation below). Likewise, when a business deal is planned, often it requires the approval of two or more partners. Therefore, you can easily add their wallets to the whitelist and they will be able to approve the transaction.
<img src="https://miro.medium.com/v2/resize:fit:1050/1*mbj8A2bU1OHNREpKcTRwNw.gif">
Smart Accounts expand the possibilities of multi-signature
Smart accounts allow users to adapt security levels according to their needs and use various methods of crypto transaction confirmation.
-Set a daily or any other limit on transfers and automatically block everything that exceeds it.
-Integrate off-chain services for additional protection. For example, if you buy an NFT, use Tokstock or any other NFT marketplace to make sure that the collection is verified before approving the transaction. If the collection is not verified, there will be a request for additional authentication.
-Block transactions with unverified or sanctioned contracts.
-Integrate AML (anti-money-laundering) services to check other addresses to make sure that the recipient/sender has nothing to do with illegally obtained assets.
In the animation below, you can see a daily limit set at 90 currency units.
<img src="https://miro.medium.com/v2/resize:fit:1050/1*mxgNFQ_yMF6FHswfyes4dQ.gif">
Batch transactions
When you use dApps based on Ethereum (prior to EIP-4337) and most other blockchains, you need to sign a transaction for every interaction on the network, which is time-consuming, expensive and frustrating. With a Smart Account, you can combine multiple crypto transactions into one (multicall).
For instance, to ensure liquidity on a decentralized crypto exchange, three transactions are usually required: approval of each of the two tokens, and then their deposit. Using batch transactions, you can do this in just one transaction because you get rid of the need for endless approval.
<img src="https://miro.medium.com/v2/resize:fit:1050/1*ZHUErLl3HumbAH0YJXc4LA.png">
Session keys and subscription payments
Session keys are a breakthrough for UX (user experience), especially for games based on blockchain. They allow users to pre-approve the rules for interacting with a dApp. Session key parameters can include: duration, maximum amount of gas, maximum transaction volume of a certain token, or a specific function in a specific contract. Moreover, session keys are perfectly combined with batch transactions, which allows you to save on gas once again.
You can enjoy using a dApp knowing that your assets are protected because you have predetermined what the dApp can do with them.
Social recovery
The purpose of social recovery is to protect people in case of compromise or loss of access to a Smart Account. Social recovery does this by avoiding seed phrases. Vitalik Buterin believes that seed phrases should be excluded because they are difficult to use, unsafe and are a serious obstacle to mass adoption. With social recovery, if you lose your private key, you can simply authorize the new key as the rightful owner of the wallet. The mechanisms for this can be different. You can choose the recovery method based on trusted contacts (guardians).
You can see how social recovery works in the animation below. 
<img src="https://miro.medium.com/v2/resize:fit:1050/1*c-dolOiCsqm8eA4WX_edoA.gif">

Everscale Deep Tech: Ethereum’s three transitions vs Everscale’s current tech. Part two Account Abstraction

Everscale

Other articles published on Aug 7, 2023

Join our free newsletter for daily crypto updates!