Rust x Ethereum Day 2023 at The Foundry SF

Noam Hurwitz presents on "Rust ERC4337 Bundler"

So as Joe just mentioned, we're talking about our REST implementation of an ERC-4237 user operation bundler.

Quick show of hands, who here is high-level familiar with ERC-4237?

I'll give a very quick primer and then we'll dive into the actual client.

So technical underpinnings of account abstraction.

There's EOAs, which are what most of you guys are familiar with in terms of how you interface with the blockchain.

And then there's smart contract accounts.

For a multitude of reasons, Like we believe that to get a billion people on chain we'll need smart contract accounts.

This was called out in a few recent blog posts, including 1 from Vitalik on his 3 transitions.

But the problem is that natively, Ethereum and EVM can only handle EOAs right now.

So how do we provide the infrastructure off-chain to safely support smart contract accounts?

The full flow is something like this, where still every transaction on Ethereum is initiated by an EOA.

But the entity managing that EOA is what's called a bundler.

And it can accept meta transactions called user operations from a lot of users, bundle them, post a single transaction to Ethereum or any other network, and have those proxy through what's called the entry point contract to the user's account.

Everyone before me made some really nice slides.

So there's just a lot of text that we can parse through.

It's a modular implementation of the ERC-4237 bundler, drawing a lot from Ref's design principles.

There's the RPC layer, the bundle builder, and the mempool.

The RPC layer and bundle builder can scale statelessly on top of that mempool.

The default connection between these components is gRPC, but we also are building an integrated mode with 0 copy.

We've built the UMM pool to handle reorgs in the underlying network.

It heavily uses ethers RS, and we're going to be switching to Alloy when that's all ready.

There's been an absolute truckload of headaches around gas estimation for 43.7.

And this is compounded by a lot of factors, including different fee markets on L2s and what's called the 164th rule.

So we have a binary search implementation implemented in Solidity to help streamline some of these things.

And there is a four-part, 15-page blog post on gas estimation.

If you guys are interested in more about that, it's crazy that that topic can be so deep.

And then we have a pretty advanced bundle builder right now that optimizes for bundle size.

Actually, we had a recent bug last week where it was posting transactions that would use more gas than Optimism would have available per block.

So that's been patched, but otherwise pretty sophisticated.

And it's streamlined so that we can support things like signature aggregation for BLS soon.

The high-level idea there is that on L2, a lot of users submit UOs, signing transactions with the BLS scheme.

The bundler can aggregate all those signatures into 1 signature that's then posted on the underlying network and can save a lot in DA costs.

And then it also handles all of the ERC-4337 simulation rules which are pretty restrictive and we can talk a little bit more about that later.

So when run LERT, so we're currently actually sprinting to open source this.

It's still not yet been open source, but it is in a private beta managing Alchemies managed user operation endpoints on Ethereum, Arbitrum, Polygon, Optimism, and now actually Base.

We have this checklist for open source, And you can see from some of the, like, we actually powered an airdrop for this team called CyberConnect about a week ago, where the Rundler handled super smoothly.

So it's been powering live production use cases.

So how Rundler, We're still waiting for benchmarks.

Most of it is going to be just a proxy to the underlying node layer.

So writes are theoretically constrained by the best base network gas limits.

Reads, too, are constrained by fan outs to things like eth logs and an underlying node layer.

There is some low-hanging fruits for performance optimizations that we'll get in, including things like native tracers that we want to build into Ref to support user op validation.

It's currently a current team of 4 Alchemy engineers, but we'll have open source soon.

Cool, and looking forward, we're cutting the public beta release in early to mid-September.

We've been working with a few folks who are writing their own bundlers and the Ethereum Foundation on the P2P mempool specs, which will be a key component of this to make it more censorship resistant.

There's also general designs for what's called alt mempools to work around the restrictions in core 4337.

So the idea is bundlers can subscribe to execute user operations that violate 4337 rules, and in exchange for taking on that risk, get compensated higher fees.

We want to build, as I mentioned, like a simulation tracer straight into the REST binary, which currently we rely on the JavaScript call tracer, which is not super efficient.

Using the latest and greatest from the EF and the IPFS team for the P2P stuff, following REST lead for Rundlers and SDK, kind of having some prototypes around AA REST, where top of block can be the user operation batch being posted from the UOs it receives.

And yeah, a lot of other performance style improvements using all the great tools that folks have mentioned in earlier talks today.

We're really excited to get this out to the ecosystem soon.

Been just load testing it and running a few experiments in production to make sure that it's all good to go, and cleaning up for everyone to be able to onboard and contribute to it soon.

But yeah, if you have any other questions, check out our website at alchemy.com slash account dash abstraction.

Or I'm happy to chat about these things at any time.


Speaker 0: Sweet. So as Joe just mentioned, we're talking about our REST implementation of an ERC-4237 user operation bundler. Quick show of hands, who here is high-level familiar with ERC-4237? Nice. That's pretty good.

I'll give a very quick primer and then we'll dive into the actual client. So technical underpinnings of account abstraction. High level, there's 2 kinds of accounts. There's EOAs, which are what most of you guys are familiar with in terms of how you interface with the blockchain. And then there's smart contract accounts.

For a multitude of reasons, Like we believe that to get a billion people on chain we'll need smart contract accounts. This was called out in a few recent blog posts, including 1 from Vitalik on his 3 transitions. But the problem is that natively, Ethereum and EVM can only handle EOAs right now. So how do we provide the infrastructure off-chain to safely support smart contract accounts? The full flow is something like this, where still every transaction on Ethereum is initiated by an EOA.

But the entity managing that EOA is what's called a bundler. And it can accept meta transactions called user operations from a lot of users, bundle them, post a single transaction to Ethereum or any other network, and have those proxy through what's called the entry point contract to the user's account. So quickly, Rundler 101. Everyone before me made some really nice slides. I apologize.

I did not. So there's just a lot of text that we can parse through. Cool. So what's Rundler? It's a modular implementation of the ERC-4237 bundler, drawing a lot from Ref's design principles.

There's 3 main components. There's the RPC layer, the bundle builder, and the mempool. The mempool is stateful. The RPC layer and bundle builder can scale statelessly on top of that mempool. The default connection between these components is gRPC, but we also are building an integrated mode with 0 copy.

We've built the UMM pool to handle reorgs in the underlying network. It heavily uses ethers RS, and we're going to be switching to Alloy when that's all ready. There's been an absolute truckload of headaches around gas estimation for 43.7. And this is compounded by a lot of factors, including different fee markets on L2s and what's called the 164th rule. So we have a binary search implementation implemented in Solidity to help streamline some of these things.

And there is a four-part, 15-page blog post on gas estimation. If you guys are interested in more about that, it's crazy that that topic can be so deep. And then we have a pretty advanced bundle builder right now that optimizes for bundle size. Actually, we had a recent bug last week where it was posting transactions that would use more gas than Optimism would have available per block. So that's been patched, but otherwise pretty sophisticated.

And it's streamlined so that we can support things like signature aggregation for BLS soon. The high-level idea there is that on L2, a lot of users submit UOs, signing transactions with the BLS scheme. The bundler can aggregate all those signatures into 1 signature that's then posted on the underlying network and can save a lot in DA costs. And then it also handles all of the ERC-4337 simulation rules which are pretty restrictive and we can talk a little bit more about that later. So when run LERT, so we're currently actually sprinting to open source this.

It's still not yet been open source, but it is in a private beta managing Alchemies managed user operation endpoints on Ethereum, Arbitrum, Polygon, Optimism, and now actually Base. We have this checklist for open source, And you can see from some of the, like, we actually powered an airdrop for this team called CyberConnect about a week ago, where the Rundler handled super smoothly. So it's been powering live production use cases. So how Rundler, We're still waiting for benchmarks. Most of it is going to be just a proxy to the underlying node layer.

So writes are theoretically constrained by the best base network gas limits. Reads, too, are constrained by fan outs to things like eth logs and an underlying node layer. There is some low-hanging fruits for performance optimizations that we'll get in, including things like native tracers that we want to build into Ref to support user op validation. It's currently a current team of 4 Alchemy engineers, but we'll have open source soon. Cool, and looking forward, we're cutting the public beta release in early to mid-September.

We've been working with a few folks who are writing their own bundlers and the Ethereum Foundation on the P2P mempool specs, which will be a key component of this to make it more censorship resistant. There's also general designs for what's called alt mempools to work around the restrictions in core 4337. So the idea is bundlers can subscribe to execute user operations that violate 4337 rules, and in exchange for taking on that risk, get compensated higher fees. We want to build, as I mentioned, like a simulation tracer straight into the REST binary, which currently we rely on the JavaScript call tracer, which is not super efficient. Using the latest and greatest from the EF and the IPFS team for the P2P stuff, following REST lead for Rundlers and SDK, kind of having some prototypes around AA REST, where top of block can be the user operation batch being posted from the UOs it receives.

And yeah, a lot of other performance style improvements using all the great tools that folks have mentioned in earlier talks today. Cool. So yeah, that's it. High level. We're really excited to get this out to the ecosystem soon.

Been just load testing it and running a few experiments in production to make sure that it's all good to go, and cleaning up for everyone to be able to onboard and contribute to it soon. But yeah, if you have any other questions, check out our website at alchemy.com slash account dash abstraction. Or I'm happy to chat about these things at any time. Thank you.

See all Paradigm transcripts on Youtube

Rust x Ethereum Day - Rust ERC4337 Bundler