Modular Ethereum Block Building with rblib - Jules Doumeche - Flashbots

Transcript

Hello. So today I want to present you uh what we have been working uh since uh December I believe which uh is a modular it block building SDK. Um so first so first um at flashbots we do a lot of blob bringing software. We start with air builder on mainet and we extend this on layer two with op air builder and we not uh we uh we find that it's really difficult to maintain a single database um single implementation of block builder because there's a lot of um of difference on how chain are operated. So we want to take a

step back and uh try to find a way to define block uh building for block building on Ethereum. Um and uh we can start with what is block building. Uh basically we have a block like the the tip of the chain and some are the flows which can be transaction and bundles and we want to construct the best payload to prop to propose for the for the next block. Uh so for this we need to apply successively transactions uh within some limits such as like block time and gas limits um following a set of rules. Uh it can be different transaction ordering or different way to handle uh chain configuration and we want to define what we want to maximize.

So this depends on uh like different layer two can want a different uh maximization. So you want for example maybe to retire some specific users or you want to maximize the block usage um or the fees. Uh so what we want to do with I believe is provide a standard uh simplified uh SDK that will allow you to easily build your own block builder for your chain. Uh so we start with a simple payload API which is uh basically we define a block context. The block context is uh represents the current state of the chain is not really part of the the the library. It's like what will give you the the states of where you are in the

chain and then you can iteratively apply uh different transaction um and get what we call uh what we call checkpoint. Checkpoint is basically uh like uh a step after applying some executable that represents um the pro the some progress in the block building job. Um and after after you apply like all the previous checkpoints we call this the history and it's fully immutable. you can change it uh at at any point you can just call build payload on any checkpoint and it will basically build the full uh payload that is ready to send to the to the engine API. Um what

is interesting is that at each checkpoint it's a full state provider. So you can have access to the like same as if you want to build a block at this time you can see all the states um and you can uh explore different path to try to find what's uh what's the best for you um so so as the block building is a iterative process and you might want you never know what is the op optimal solution um you might want to explore different path and also So maybe want to roll back history. So for this we introduce a concept of a barrier that is basically saving the the history like saying that before the barrier it's what

the it's called the sealed history and we don't want to modify it anymore and then you can explore and at any time roll back for free directly on this. Um I also want to say that checkpoints uh we try to design this in a way that is really cheap to clone to move around to put in different threads to be able to really easily explore um a lot of different path. Um so yeah a simple example uh so you just start from the context and then you can just apply some transaction and build the payload. So this is the simple one. Um and that's basically it for the the payload API. As you as you see it's really simple. We want to keep keep it as simple as possible because you as I said before uh often like uh for block

building software we we use some client SDK and there's a lot of complexity and it can also lead to some re readability problem later on. So with this we really want to take a step back and try to do really the simple thing because block building is more simple than running a full Ethereum client. Um so this what like before if you noticed there was block context Ethereum and uh we don't want to be only on layer one layer one we want to provide features for everything because as I said before uh we want to be able to customize every a lot of details so for this we have the concept of platform which is basically as a user of you will define your own platform if you want or reuse some

existing platform that will define for example uh chain spec or EVM configuration uh bundle or transaction types this kind of stuff and then after on you can just use the platform directly on all their uh like all the API uh with the your specific uh platform type and it will automatically work. Um so payload API is basically the way you uh to do the block building progress. Uh but um uh that we need to find a way to compose everything together and describe uh what kind of uh like uh what kind of of behavior we want. So in a way this is kind of like a framework compared to the payload API

being being like the base SDK. Um so the idea is uh often when you when you will build your own block you will want specific uh uh behavior such as for example um revert revert like remove all the reverted transaction or um ordering the transaction by priority fee this kind of stuff and we want to like being able to define this specific behavior inside what we call step and then you can reuse the step um for your own um own logic Um and after yeah so you you start with like the basically any checkpoint and you will do the progress inside this kind of step and then at the end you

will get another checkpoint. Uh and you can define this inside what we call a pipeline. Um that's yeah basically just to compose everything together and there's like a control flow um features that allow you to define prologue. The product could be like for example if you're layer 2 you want to add some sequencer transaction and epilog it will be maybe for example to add um some specific um trans builder transaction for example and um and you can run the step in for example loop if you want to do flash blocks um or specific like append transaction from the main poolool um and you can also like do some nested pipeline to do more

complex behavior so I think with this we can cover almost any uh use case. Um and a good thing is because we are platform agnostic, you can actually reuse uh we like we are providing a lot of uh standard steps. So you can reuse them out of the box. Um so yeah an example with eerum. So as I say you can define a builder log which will basically some transaction and then we just in a loop uh take some orders from the pool order per purity fee. we remove the reverts and it will automatically do the block and stuff. Um so by default we don't have any integration but you can actually uh uh modify it to your own uh nodes and um

this is an example with rest. So we have implemented the input services that you can after just add uh as payload services. Yeah. Um yeah that's it. Um so really the goal with uh with our believe it's still in the early stage it's not used in any production environments but um we want uh as fbot we have like a lot of different uh builder service for different chain and we really want to unify everything to not to don't have to redo the the implementation of similar logic uh across chain and and also we believe that opening open source this will also allow any any um blockchain network to come to us, reuse the step,

contribute and build a more resilient uh block building ecosystem. Thank you very much. [applause] >> Thank you, Jules. I'll have you move to just the center of the stage so they could frame us while on the camera. Um, there are a couple of questions from the audience here. Uh, the first question is, uh, can this integrate with any pre-MP pre-confirmation solution? Uh well you have to build your own preconfirmation uh logic but for example uh what you have like what we do is flash block so it's kind of similar to pre-confirmation and um we have some logic that basically in we have a pipeline that is a loop that will in

within a block build mini blocks and you can after uh so step is stateful so you can actually add any kind of a logic inside it. Um yeah. >> Okay. And then next question, is it possible to recurse or backtrack a step? >> Um so um if you mean like uh uh getting a payload like getting a checkpoint previously in history, yes, it's possible. So um you can inside a step save the the checkpoint from a previous execution and then you can just return the previous one. And like the step is just a way to change the the history of checkpoints. But you know a checkpoint don't need don't need to have always the same history.

>> Okay. And then once executed is that step final? >> Uh so uh first step is uh like the checkpoint return the history will always be immutable but nothing prevents you to to like save some checkpoint that will come from different uh different path in history and then just return the one that you actually need. >> Okay. Uh let's go to the next question then. Uh what about state growth? Is that going to be a problem for you in the short or midterm? >> Um by state growth if you mean like uh like saving a lot of different thing. Um it can be a problem if you need to explore a really really long like a lot of different path. But uh we try to to save

a less uh state possible. And for example inside checkpoint we don't we just uh store the state transition and if you need to request the state actually it will uh uh uh go back in history as soon as you can you know find and if you don't find the the state it will just call the underlying state provider. Okay, excellent. And then uh last question there. Any data on performance? >> Um we are doing some benchmark but we have nothing yet public but um yeah keep tuning for this soon. >> Okay. And then I saw one last question pull up in there that I think we'll end with is can flashbots offer lower latency than 200 milliseconds?

>> Um actually you can define whatever you want. You need to to tune things. uh we can build block really fast but uh the 200 millond is also because there's like a lot of network involved and we need some rooms to be able to be sure to to be resilient um to some latency jig goals. >> Excellent. Well, again, thank you Jules for an excellent pleas presentation. >> Thank you. [applause]