ERC-4337 Primer: What You Need to Know

ERC-4337, or ”account abstraction”, is an Ethereum proposal that
introduces “account” smart contracts. Account abstraction simplifies the
handling of Ethereum accounts, providing a generalized interface for
both traditional externally owned accounts (EOAs) and smart contract
accounts. Social recovery, paying for gas, and transaction security are
some of its proposed improvements. In this new approach, users are no
longer bound to handle their private keys and enjoy the flexibility of
setting up additional account rules, which improve their security
posture.

In this post, we’ll break down the main advantages of account
abstraction over current wallet solutions, as well as its security
considerations for users and developers.

Current Wallet Management Solutions​

Externally owned accounts (EOAs) are the fundamental type of account on
the Ethereum blockchain. Whoever possesses the private key has complete
control over the actions of the associated EOA. While it allows for
straightforward interactions with the network, it also comes with the
inherent challenge of managing private keys. A simple mistake could mean
permanent loss of funds, and on chain, permanent really means permanent.
Apart from that, there’s also the concept of gas fees. This is
counterintuitive for most Web2 users, as there’s rarely any type of
pay-per-action situation in a modern Web or mobile app.

Given these challenges, several alternatives and enhancements over the
basic EOA structure have been implemented:

• Web browser wallets: Integrated directly into Web browsers,
  either as extensions or plug-ins. Examples include the MetaMask and
  Coinbase browser extensions. They provide a user-friendly interface
  for viewing balances, performing transactions, and interacting with
  dApps directly from the browser. Operating within a browser makes
  them susceptible to various attacks, including phishing, XSS, social
  engineering, and so on.
• Multi-signature (multi-sig) wallets: These are smart
  contract–based wallets that require multiple private keys to
  authorize a transaction. Thus, even if one key is compromised, the
  attacker still needs access to the other keys to move funds or
  execute critical actions. Examples here include Safe, Argent, and
  Armory multi-sigs.
• Multiparty computation (MPC) wallets: Similar to multi-sig
  wallets, this type of wallet distributes the transaction
  authorization by dividing a singular private key among multiple
  actors. Some examples include ZenGo and Fireblocks. Some MPC
  implementations use the novel threshold signature, where only m of
  the n total signatures are necessary. Unlike multi-sig wallets, this
  threshold property is an intrinsic property of the cryptographic
  primitive itself, not a programmed smart contract constraint.
• Hardware wallets: Devices like Ledger or Trezor provide a
  physical layer of security. They store private keys offline and
  require physical confirmation on the device to sign transactions.
  The keys in a properly designed hardware wallet should never leave
  the device. This makes them most resilient against online hacking
  attempts.

While these solutions partly address the challenges associated with
vanilla EOAs, they also introduce complexities and trade-offs of their
own. For example, none provide an actually effective account recovery
mechanism. Some use a recovery passphrase that itself can be lost or
even stolen, thus still leaving all the responsibility in the hands of
users.

First, let’s start with the rationale behind the ERC-4337 proposal and
discuss some of its benefits.

Account Abstraction In a Nutshell​

At its core, account abstraction streamlines users’ interaction with the
Ethereum network. It makes the learning curve gentler for new users, who
may otherwise be intimidated by the technical aspects of Ethereum. They
no longer need to handle private keys, and the transaction approval
procedure can be delegated to other trusted parties.

Meanwhile, developers benefit from greater flexibility when designing
and implementing dApps. Account abstraction enables new ways to improve
the user experience. These include sponsoring gas fees, transaction
legitimacy checks by whitelisting particular addresses, and
authentication via social log-in (e.g., “Log-in with Google”), among
others. Account rules like transaction spending limits can be set up to
eliminate the potential of leftover approvals being misused when a
protocol is compromised.

Despite the complexities involved in developing a feature-rich account
abstraction wallet, the general architecture is transparent. In fact,
there’s only one “off-chain” component, the new mempool. Everything else
is handled in smart contracts. Without all the external components that
previous solutions had, the attack vectors are significantly diminished.

We see great improvements in user experience with account abstraction,
but when things sound overly promising there’s usually a catch. Let’s
explore some of the need-to-knows for developers and users, including
potential security pitfalls.

How an Account Abstraction Transaction Works Under the Hood​

Under the hood, the following steps take place in a typical user
interaction:

Step 0: The user sends a UserOperation to a special mempool
customized for the ERC-4337. This new mempool is needed so that users
don’t pay the gas fees upfront. Bundlers (which are essentially EOAs)
will then pick up the newly added UserOperation from the mempool and
add it to a bundle transaction.

Step 1: The bundle transaction is then forwarded to a singleton
contract called “Entry Point”.

Step 2: Entry Point then individually calls validateUserOP on each
user’s account contract (i.e., the wallet smart contract that inherits
IAccount) for each transaction in the bundle. (For simplicity, we
assume that the bundle only contains one UserOperation in the bundle
transaction.)

Step 3: The user’s account contract returns whether the
UserOperation it has been asked to verify is valid, according to the
rules they set in the validateUserOp function.

Step 4: If valid, the Entry Point verifies that the user account has
paid it enough for the gas fees and then calls execute back on the
user’s account contract.

→ If invalid, terminate the execution and return the appropriate
response back to the Entry Point contract.

Step 5: The user account contract then performs the low-level call
with the calldata and target provided in the actual UserOperation,
finalizing the execution chain.

There are several enhancements over this simple architecture. One is the
usage of Paymasters, which handles sponsoring the transaction’s fees.
In this scenario, at Step 4, the Entry Point will verify that the
Paymaster has supplied enough for the gas fees to cover the particular
UserOperation that’s being verified. This may be crucial for projects
concerned about user adoption, as the interactions on the Ethereum
blockchain will be more seamless, much like current Web and mobile apps.
Alternatively, users could be allowed to pay in stablecoins for gas for
a more familiar and convenient pricing scheme.

Moving the transaction execution logic into smart contracts increases
developers’ security responsibilities. We present several security
considerations when developing account abstraction wallets.

Need-to-Knows for Developers​

As we just saw in the previous section, in order to support the ERC-4337
(i.e., account abstraction) standard, a wallet contract must implement
the function validateUserOp.

interface IAccount {
  function validateUserOp
      (UserOperation calldata userOp, bytes32 userOpHash, uint256 missingAccountFunds)
      external returns (uint256 validationData);
}

The validateUserOP function should ensure all of the following:

• Assure↗
  that the function call originated from the singleton EntryPoint
  (i.e., require(msg.sender == EntryPoint);), to prevent forged
  calls.
• Assure that the user operation is valid based on the
  userOpHash.↗
  This is mainly to prevent malicious UserOperations from being
  executed on behalf of the user account wallet. Also, return
  SIG_VALIDATION_FAILED (do not revert) on signature mismatch,
  as per the
  standard↗.
  Revert on any other type of error.
• (In the case that the Paymaster is not supported) Pay the
  EntryPoint (msg.sender) at least the missingAccountFunds,
  thus ensuring that the gas fees are paid for the
  particular↗
  userOp transaction.
• The return value should be packed encoded of (authorizer,
  validUntil, validAfter).
  • authorizer – 0 for valid signature, 1 to mark signature
    failure. Otherwise, an address of an authorizer contract. The
    ERC defines “signature aggregator” as authorizer. More details
    on the signature aggregator can be found
    here↗.
  • validAfter and validUntil are six-byte timestamps. The
    UserOp is only valid either until validUntil or after
    validAfter, or within the validAfter ... validUntil range.

For reference, the ERC-4337 core team has implemented
SimpleAccount.sol↗,
a sample account contract, with all the necessary checks in place. Over
time, developers will begin prototyping different improvements over the
default ERC-4337, and we anticipate that the following security
considerations will come in handy:

• Upgradability: Since most of the account abstraction’s
  components are smart contracts, it’s safe to assume projects will
  make them upgradable. Bugs to look out for here include
  mismanaging storage variables against overwrites and mishandling the
  migration functions, business-logic wise. In this Twitter
  thread↗,
  we describe a storage collision hack that led to over $6,000,000 in
  lost funds. Recently, we also identified an issue that would
  permanently lock the contract after it was upgraded.
• Reentrancy: Sponsoring gas is tricky to implement securely. Will
  there be a Vault that will pick up UserOperations, pay the gas,
  and forward the transactions? Or will there be some sort of
  permit-based transaction? Regardless, we anticipate that protocols
  will opt for custom Paymasters, maybe to allow for ERC-20
  transfers, swaps, and so on. Considering this, the most likely
  attack vector here is reentrancy, as Paymasters will forward some
  sort of tokens, either native or ERC-20, via calls and callbacks to
  external contracts.
• Front-running: Since transactions will be publicly available in
  the special mempool, front-running attacks will be prevalent,
  regardless of how transactions are eventually bundled and executed.
• (For third-party contracts) Reliance on tx.origin: The user
  will transact via a contract rather than an actual EOA; thus, the
  tx.origin will no longer match msg.sender. Any EOA-only checks
  will thus be obsolete, and necessary modifications must be supported
  by all protocols wanting to offer support for account abstraction
  wallets. All smart contract developers, even those not directly
  working with ERC-4337, should be aware of this.

Need-to-Knows for Users​

On its own, account abstraction does not come with more security risks
for the users. As an ERC, the standard code will be heavily audited and
the room for error is minimal. The default implementation, however, does
not come with all the features we’ve talked about in this post. So,
before any features like transaction spending limit, social
recovery↗, or
authentication and so forth are implemented, heavy development and
customization are needed. As we all know, smart contracts often turn out
to be insecure. Selecting a security-focused account abstraction wallet
solution still requires careful diligence.

The Takeaway​

The goal of account abstraction is to simplify the implementation of
account abstraction–like user experiences. Centralized components are no
longer needed to provide an effective alternative for the default EOA.
It’s an opportunity for developers to onboard a larger audience to
Ethereum, as less technical knowledge will be required to operate an
account. This simplification doesn’t directly translate to bug-free
code. By reducing the possible external attack vectors, however,
developers now have a smaller sandbox to deal with; here, security
invariants are more easily defined. We consider account abstraction to
be an important step towards a more secure and resilient Ethereum
ecosystem, paving the way for additional use cases and user experiences.

About Us​

Zellic specializes in securing emerging technologies. Our security researchers have uncovered vulnerabilities in the most valuable targets, from Fortune 500s to DeFi giants.

Developers, founders, and investors trust our security assessments to ship quickly, confidently, and without critical vulnerabilities. With our background in real-world offensive security research, we find what others miss.

‍Contact us↗ for an audit that’s better than the rest. Real audits, not rubber stamps.

*** This is a Security Bloggers Network syndicated blog from Zellic — Research Blog authored by Zellic — Research Blog. Read the original post at: https://www.zellic.io/blog/erc-4337-primer