Rust x Ethereum Day 2023 at The Foundry SF

Jacob Kaufmann presents on "Reth MEV Builder"

I work at the applied research group at the Ethereum Foundation, and this is something that I've been working on For the past few weeks With a teammate of mine Alex Stokes.

He's also here And yeah, let's get into it a few preliminaries First I want to say thank you to the RET team for really great support.

I could say a lot more, but in the interest of time, let's move forward.

So I'm going to talk about local block production, Map Boost block production, Why is open source block production software important?

And then we're going to talk about Evangelion, or AVA, as I'm calling this block builder.

And then we'll talk about some ongoing and future work.

So in Ethereum, we have this separation of concerns between the consensus layer, or the CL, and the execution layer, or the EL, and they communicate via the Engine API.

So the CL will periodically notify the EL about updates to its fork choice state via engine fork choice updated.

And when it's the validator's turn to propose, it will also send along these payload attributes, which contain information that the EL needs to build the payload.

And the EL will return an identifier called the payload ID, which the CL can use to retrieve the corresponding payload.

So in Meboos block production, validators auction their block space to this network of external builders.

And relays broker this interaction between the validator and the builder.

And both the validator and the builder rely on the relay to sort of provide some guarantees about this exchange.

So builders are these specialized entities that have advantages that allow them to build higher value blocks.

The main sources of edge or alpha are information or order flow and algorithms.

So for example, builders might have a vertically integrated searcher or some other exclusive agreements with searchers to get bundles or private transactions.

So why block production open source software?

This chart is from boost.pix, which is maintained by another teammate of ours, Tony.

You can see that essentially 4 or 5 builders have an overwhelming majority of the block share.

And so we really want to lower the barriers to injury for builders.

And so what we try to do is we can't really solve the information edge, but we want to minimize the algorithmic edge as much as possible.

And yeah, we want to allow builders to specialize.

So instead of having to spend energy and resources maintaining a fork, we would rather allow you to spend time building more advanced algorithms.

And it would also be cool to have academics or other researchers implement various algorithms.

So in Reth, there's a crate called the Reth payload builder.

And within there, there's a trait called the payload job generator.

And essentially what this is, is you call it with some payload builder attributes, and it will give you back a job.

A payload job is essentially a future that will eventually resolve to some payload.

And I've omitted some details here for brevity, but you can also periodically pull the job for the best payload.

This is important because transactions and bundles are always flowing in.

And so over time, you can assume that the more time you have to accumulate transactions and bundles, you can build more valuable payloads.

So we have this implementation of this trait.

And then also, Georgiou has talked about CLI extensions.

And then that's essentially all we need to do to interface with Reth.

We also configure the consensus layer to continuously trigger payload jobs.

So by default, it will only trigger a job when it's the validator's turn to propose.

But you can configure Lighthouse to, for instance, trigger a new job for each slot.

And then also, the other bit is that the EL and CL are not MevBoost aware by default.

So we need to build some extra machinery around it so that we can, for instance, query a relay to see, this proposer, are they registered with MevBoost?

And then we need to get to their registration information so that we can do things like send the fees to the proper address on the execution layer.

So with not so much code, you can have a custom builder without maintaining any forks.

And this is a huge improvement over maintaining a fork of geth.

And yeah, we've built some blocks on Sepolia.

And for ongoing future work, we need to build some better abstractions in the same way that REST provides these powerful abstractions.

We want things like a bundle pool, block packing algorithms, and bidding strategies, as well as some other optimisations, and then I will quickly say that we have this other project created by Alex Stokes that's in the same way as an open source builder, it's an open source relay, also in Rust, and, yes, we would love to have more help on it.


Speaker 0: I'm Jacob Kaufman. I work at the applied research group at the Ethereum Foundation, and this is something that I've been working on For the past few weeks With a teammate of mine Alex Stokes. He's also here And yeah, let's get into it a few preliminaries First I want to say thank you to the RET team for really great support. I could say a lot more, but in the interest of time, let's move forward. And then a disclaimer.

This is experimental software. Research purposes only. No liability. All that stuff. Quick outline.

So I'm going to talk about local block production, Map Boost block production, Why is open source block production software important? And then we're going to talk about Evangelion, or AVA, as I'm calling this block builder. And then we'll talk about some ongoing and future work. So in Ethereum, we have this separation of concerns between the consensus layer, or the CL, and the execution layer, or the EL, and they communicate via the Engine API. So the CL will periodically notify the EL about updates to its fork choice state via engine fork choice updated.

And when it's the validator's turn to propose, it will also send along these payload attributes, which contain information that the EL needs to build the payload. And the EL will return an identifier called the payload ID, which the CL can use to retrieve the corresponding payload. So in Meboos block production, validators auction their block space to this network of external builders. And relays broker this interaction between the validator and the builder. And both the validator and the builder rely on the relay to sort of provide some guarantees about this exchange.

So builders are these specialized entities that have advantages that allow them to build higher value blocks. The main sources of edge or alpha are information or order flow and algorithms. So for example, builders might have a vertically integrated searcher or some other exclusive agreements with searchers to get bundles or private transactions. So why block production open source software? This chart is from boost.pix, which is maintained by another teammate of ours, Tony.

You can see that essentially 4 or 5 builders have an overwhelming majority of the block share. And so we really want to lower the barriers to injury for builders. And so what we try to do is we can't really solve the information edge, but we want to minimize the algorithmic edge as much as possible. And yeah, we want to allow builders to specialize. So instead of having to spend energy and resources maintaining a fork, we would rather allow you to spend time building more advanced algorithms.

And it would also be cool to have academics or other researchers implement various algorithms. So what is Evangelion or AVA? So in Reth, there's a crate called the Reth payload builder. And within there, there's a trait called the payload job generator. And essentially what this is, is you call it with some payload builder attributes, and it will give you back a job.

A payload job is essentially a future that will eventually resolve to some payload. And I've omitted some details here for brevity, but you can also periodically pull the job for the best payload. This is important because transactions and bundles are always flowing in. And so over time, you can assume that the more time you have to accumulate transactions and bundles, you can build more valuable payloads. So we have this implementation of this trait.

And then also, Georgiou has talked about CLI extensions. So we pass in this custom builder. And then that's essentially all we need to do to interface with Reth. We also configure the consensus layer to continuously trigger payload jobs. So by default, it will only trigger a job when it's the validator's turn to propose.

But you can configure Lighthouse to, for instance, trigger a new job for each slot. And then also, the other bit is that the EL and CL are not MevBoost aware by default. So we need to build some extra machinery around it so that we can, for instance, query a relay to see, this proposer, are they registered with MevBoost? And then we need to get to their registration information so that we can do things like send the fees to the proper address on the execution layer. And yeah, that's really it.

So with not so much code, you can have a custom builder without maintaining any forks. And this is a huge improvement over maintaining a fork of geth. And yeah, we've built some blocks on Sepolia. Here is the link to the GitHub. And for ongoing future work, we need to build some better abstractions in the same way that REST provides these powerful abstractions.

We want things like a bundle pool, block packing algorithms, and bidding strategies, as well as some other optimisations, and then I will quickly say that we have this other project created by Alex Stokes that's in the same way as an open source builder, it's an open source relay, also in Rust, and, yes, we would love to have more help on it. So thank you.

See all Paradigm transcripts on Youtube

Rust x Ethereum Day - Reth MEV Builder