Account Abstraction's Impact on Security and User Experience

OpenZeppelin provided support for the launch of Account Abstraction via incremental security audits; the goal of this article is to share our insights on how to build safely with ERC-4337

Account Abstraction supports new use cases for smart contract developers, empowering users to have gas-free experiences, authenticate with biometrics, or leverage social recovery features for their account. However, these innovations come with additional security risk vectors which need to be clearly understood by Web3 developers aiming to take advantage of the new functionality. Hardened security doesn’t stop at the building and testing phase – it is also crucial for developers to set up security monitoring using OpenZeppelin Defender to safeguard deployed contracts against the known risk parameters of otherwise secure code. 

While L2s such as zkSync Era and Starknet have implemented account abstraction at the protocol level, enabling Visa to design an automated crypto bill payment system that leverages account abstraction, the same functionality of account abstraction on the Ethereum mainnet only became possible via ERC-4337. The development of the standard has been underway for two years with funding from the Ethereum Foundation. It is worth emphasizing that, out of the box, ERC-4337 does not automatically grant new security benefits – it gives new functionality with security vectors. 

OpenZeppelin provided support for the launch of Account Abstraction via incremental security audits, and on March 1, 2023, the audited and fixed version of EntryPoint was showcased at ETH Denver and deployed. Following Entrypoint's deployment, the Ethereum Foundation collaborated with OpenZeppelin to review three pull requests aimed at enhancing user operation security and contract functionality.

Use Cases

ERC-4337 adds a new layer of infrastructure, and therefore complexity, but not in a way that the user ever needs to deal with. In fact, this added complexity will allow the user experience to be vastly streamlined.

“Supporting smart contract accounts that enable a wider range of authentication, recovery, and payment mechanisms while respecting the core protocol constraints and ethos is an interesting challenge, and the protocol designers have had to rethink every step of the process.”

– Nikesh Nazareth, Security Researcher at OpenZeppelin

What capabilities does "abstracted validation" enable for a typical user?

• Native multi-signature accounts - Capable of adding/removing signers
  
• Social recovery features - Regain access to an account via a time-locked social/commercial service.
• Gas fee payment in ERC-20 tokens - No need for users to exchange/maintain/spend an ETH balance to pay for user transactions. 
  
• Gas fee sponsorship - Protocols, Dapps, DAOs and other users can participate as paymasters.
• Support for quantum-secure or more efficient signature algorithms - Smart account transactions are no longer tied to base-level ECDSA encryption.
• Upgradeability - Add/remove account functionality over time.
• User-defined tiered account permissions - Set usage roles for multiple users, account types, and usage scenarios.
• Batched transactions - Save on transaction submission costs, and streamline operations.
• User-specified transaction or spending limits - Adds a backstop against user error-related security issues.
• Two-factor authentication - Allows users to sign transactions on their phone using a fingerprint or face scan.
• Time-based permissions or spending limits - Set weekly/monthly account spending limits.
• Session key support - Streamline the play of blockchain games using session keys rather than manual transaction approval.
• Enable subscriptions via pull payments
• Censorship-resistant fee model - EOA transactions require users to transfer ETH into an account, which can generally be tracked to a KYC’d exchange, where privacy could be compromised. Account abstraction removes this requirement for users.

The biggest wins brought by Account Abstraction are in the domain of user adoption and user-centric security. To accomplish this, smart contracts will do more legwork, and users will be able to meaningfully interact with the decentralized blockchain without having to understand cryptography, gas, or nonce management.

Security Considerations for Developers

ERC-4337’s design abstracts many account properties (gas payment, authentication, transaction batching, etc.) into smart contracts, which necessitates extra scrutiny to guard against the potential attack surfaces this opens up.

Since end users would be issuing transactions via contracts rather than EOAs, deployed smart contracts relying on Solidity code that specifies tx.origin rather than msg.sender to check for an EOA-only caller would become invalid, although the rationale for this check would obviously persist and the necessary logic should be retained when updating such code.

Code that implements EIP-4337 enables someone off-chain to deploy a transaction on the user’s behalf without having to trust them. Although Account Abstraction greatly boosts security and usability from the user’s perspective, enabling it at the protocol layer can help ensure security and stability for developers when implementing related functionalities, otherwise the complexity of the ERC can bring potential attack vectors. Ethereum’s existing incentive models have been proven to support secure use cases. 

The design of ERC-4337 does not require participants to know each other. The smart contract which handles transaction payment (the “paymaster”) is nevertheless performing a service for the user. Fortunately, paymasters will be public, and inspectable as a smart contract with its own conditions defined. Paymasters will have conditions for when to pay for things, and people may come up with ways to trick these paymasters. Simple conditions may lead to greater manipulation. 

When building a paymaster, it is necessary to define rules for end users to pay back the owner and guard against opportunities to manipulate this relationship. For example: 

• Is the paymaster staked (or is trust achieved via another means)?
• After the user endorses the transaction, the paymaster has to agree to pay for it, which may involve checking preconditions such as the user’s willingness and ability to reimburse post-execution. 
• After the call, performing necessary cleanup, the paymaster retrieves funds from the user. There is a rare possibility that a user validation could invalidate the check. E.g. despite confirming that a user has DAI, the user operation could use too many funds or revoke. If that occurs, there is an edge case where it will stop the transaction and offer another call to retrieve the funds. A malicious user could get the operation for free, leaving the paymaster on the hook to pay for it.

Monitoring Suggestions

The logic specified within the paymaster should be designed securely. However, it is important to set up security monitoring of any paymasters a project is responsible for to help identify potential edge cases based on additional information about the transactions submitted, or if there is a spike in size or number, for example:

• User operations that have unusually high or low gas parameters 
• Operations or paymasters that consistently fail validation in the mempool 
• Transactions that use non-standard accounts, factories, and aggregators 
• Any bundle that reverts on-chain 
• Operations where any of the participants have an unusually low stake

OpenZeppelin Sentinels can be configured to watch any/all specified contracts for these transaction parameters and trigger automatic functions or notifications accordingly. For an in-depth walkthrough of how to use OpenZeppelin Defender for security monitoring and emergency response, click here.

Because there may be conditions where people will exploit the smart contracts for their benefit, it is important to think through what could possibly go wrong. Some paymasters may define simply that they will pay for any transaction as long as payment is received in a given currency. Scenarios involving gas payment open up an area of opportunity for hackers. One backstop against this stems from the fact that paymasters have to be pre-funded to fulfill their role, and those experiencing a rapid drain would typically not be topped up with fresh funds.

Additional factors to consider:

• Consider validating the maximum operation cost. Accounts can query the EntryPoint contract's balance or defer the decision to users.
• Be aware of paymaster failure cases. Accounts should avoid violating conditions assumed by the paymaster's after-operation function to prevent being charged for incomplete operations.
• Paymasters that are not pre-charging the user must ensure their postOp function reverts if conditions are not met (e.g., non-payment) to avoid being wrongly charged for user operations.
• Paymasters relying on double-postOp capability should guarantee successful completion of the after-revert postOp function if validatePaymasterUserOp succeeds. Discrepancies may lead to throttling or banning of paymaster operations by bundlers.

Account Abstraction as a continued improvement to Ethereum through ERC-4337 is expected to eliminate the need for new users to learn the complex process of setting up an account or memorizing seed phrases while enabling biometrics support, and it creates additional safeguards for account recovery as well as widely richer functionality without compromising decentralization. This is crucial in making digital assets accessible to people without a technical background.

As developers adopt the ERC-4337 standard, it is vital to prioritize best practices throughout the implementation process. This includes the setup of robust security monitoring using OpenZeppelin Defender so that developer teams are able to inspect smart contract state, guard against potential risk vectors, and respond quickly (or even automatically) in the event of a security incident.

Get in touch with OpenZeppelin for security advising, auditing, and products for smart contract security. Work with Web3 experts to ensure secure implementations of Account Abstraction. 🔐 

References

• Account Abstraction Audit - Appendix: Architectural Analysis and Advice for Developers
• Account Abstraction incremental audit