Exploring a new RPC endpoint to support ERC-4337 and account abstraction

Account abstraction is an exciting development that aims to revolutionize the way users interact with blockchains in the Ethereum ecosystem. This blog post delves into the intricacies of account abstraction, ERC-4337, and the benefits of a novel RPC endpoint that is being built to make it easier for bundlers to succeed. If this post gets you curious about what we’re building, don’t hesitate to reach out to me on Twitter to see how you can get involved.

Understanding account abstraction and ERC-4337

In essence, account abstraction allows users to define an authorization policy for performing actions on behalf of an account. This policy, implemented in a smart contract wallet, simply returns true or false, determining if the action is authorized.

Currently, Ethereum uses an ECDSA signature to authorize transactions from specific accounts. However, smart contract-based authorization policies can be more computationally intensive, and therefore, more expensive to execute. To prevent denial of service attacks on the network, the authorization policy within smart contract wallets must be constrained.

Account abstraction can be implemented either statefully or statelessly. Stateful account abstraction enables more expressive authorization policies but the authorization policy can return different values as the blockchain state changes over time. Stateless account abstraction, on the other hand, is generally less expensive to validate but less expressive.

ERC-4337 is an out-of-protocol meta-transaction standard that enables a form of account abstraction. It allows users to interact with the network by sending UserOps to their smart contract wallets, which can be bundled into transactions by bundlers.

Introducing a new RPC endpoint for conditional inclusion

One challenge with stateful account abstraction is that a UserOp valid at one block may be invalid at another block. To address this issue, a new RPC endpoint has been proposed that conditionally includes transactions based on validity conditions. This development aims to make it easier for bundlers to be successful.

This RPC endpoint allows users to specify conditions for their transaction inclusion, such as preferred account values, storage slots, block numbers, or timestamps. The block builder's profitability and reputation are the only factors ensuring that user preferences are observed. Bundlers should monitor block builders' performance and stop sending bundles to those that do not observe their preferences.

While this RPC endpoint is more efficient than requiring full simulation of the bundle, it still adds resource consumption to the block builder. An upper bound on resource consumption must be defined to prevent denial of service attacks. This upper bound can be larger if a reputation system is built on top, where successful bundlers are given more resources than unsuccessful ones.

What might such a reputation system look like? Well, with this RPC endpoint, block builder profitability and reputation are the sole factors ensuring user preferences are observed. As block builders earn more through transaction fees by acting honestly, their reputation with bundlers improves, creating a flywheel effect that can help to bootstrap the 4337 economy. Since there are no in-protocol incentives to ensure that bundler preferences are followed, bundlers should monitor the performance of the block builders and stop sending bundles to block builders that do not observe their preferences. Having a permissionless set of block builders is important so that bundlers can opt out of block builders that are malicious.

Interested in getting involved?

The proposed RPC endpoint for ERC-4337 promises to improve the efficiency and flexibility for bundlers, making it easier for them to succeed in this growing account abstraction ecosystem. If you're a developer interested in collaborating on this project, please send me a message reach out to me at @tyneslol on Twitter.