Ethereum Sequencing and Preconfirmations Call #12

Transcript

okay welcome everyone to the uh sequencing and pre-confirmation call uh number 12 today uh is demo day we have four different teams uh doing four different uh demos I guess before we get started I just want to uh give a little bit of a a progress update since uh last time uh one piece of exciting news is that there's two new base rollups on my radar uh number one is a Japanese team called inmax they're building a really really interesting ZK rollup that is specialized for payments uh where the onchain um overhead is is five bytes per transaction so it's uh very very small

onchain overhead and they building it as a as a base rollup and then there's another base rollup from The Tao team called gwf um and I'm not sure if it'll be run as two parallel chains or if one will update the other but uh exciting nonetheless uh another update is that we uh we now have a uh a repo on on the ethereum um GitHub organization so it's etherum precon um the role of this this repo is basically to host uh the the credibly neutral code uh in particular the the registration contract where we really want everyone to uh to agree on

on on one canonical registration contract which is Maxim credibly neutral so if you do want to work on the registration contract and and you're not part of the registration contract telegram group to to get in touch with me I guess um since last call we've had the sequencing day at ECC uh a lot of people have been talking about uh uh pre-confirmation uh I feel like uh the word is really starting to spread out and people are getting comfortable with the concepts uh and in addition to um doing the education and spreading the word uh I think there's been a lot of uh actual development on on test Nets uh there's a new test net the the Helder test net

which is dedicated to pre-confirmation uh and and propos of commitments uh and today is where we'll see a lot of these proofs oft Concepts uh uh live so uh without further Ado um let's start with the very first demo from the G team could and Lorenzo the floor is yours cool uh can everyone hear me all right yes okay nice I'm just gonna share screen the screen okay perfect so um hi Kuby and Lorenzo here from gataka um so we U

mainly focus on infrastructure structure around pre-confirmation so we're now actually building a pre-confirmation protocol itself um and um I guess we have been sprinting towards uh various uh improvements uh since Zin so we're just going to talk just very briefly about what we've built and then actually run through the demo just to set the scene a bit um second yeah okay so um if you guys remember back from zuin um the main focus there was on um inclusion pre- confirmations which was a very good sort of foundation to work towards actual L2 uh execution pre- confirmations and the

main Milestone there really was that there was some consensus that was reached uh across different teams um to basically um make some changes to the existing PBS stack so across proposa to the relay to builders to actually enable uh inclusion pre confirmations L1 prec confirmations for that matter um in Zubin and this was actually like an important sort of stepping stone to work towards the next stage um and then um just this is a quick refresher um the is the notion basically that um L1 proposes can opt into being pre-converted and um The Proposal can either be the precon convert themselves

directly so for example the B protocol enables that but also there's this notion that these proposal can delegate the right to be or to issue pre confirmations on behalf of them but no matter uh whether the proner is the proposer themselves or a delegated preon through a Gateway um there's basically this notion of a look ahead where um even if not every proposal actually opted in to being a prec confair um essentially The Proposal is next in line has um exclusive rights to to issue prec confirmations during these Gap proposes um so just as a quick refresher um and then what we have actually built now on

Helder to get to L2 execution pre-confirmation is the following and so um basically you have um a pre-confirmation RPC router um and this is also open source um and the idea is basically that the users or wallets can directly request pre confirmations through this RPC endpoints and the router RPC is responsible for um by looking at the look ahead basically identifying who is the right uh elected Gateway or uh could be proposed directly but uh essentially who's the entity that can issue pre-confirmation based on the

look ahead and essentially make sure that um these can be issued and whenever there's a transition then uh switch to the right preer accordingly um and the way we got everything to work U on Helder specifically um without requiring any changes on existing wallets so we actually use metamask here in our demo C process uh sorry oh okay I think that was a mistake um then um yeah so we basically um will be able to respond to current RPC calls that will is already used in order to um

give the user the same experience that they already used to without actually requiring any changes on the wallet front which is actually quite nice uh because that will help a lot with adoption and so like some of the standard like RPC calls like you raw transaction get transaction receipt transaction count um are basically um exposed via the RPC and then redirected to the router uh the Gateway and this is important because the Gateway actually maintain State and Advan the state and so the Gateway can actually um return the exact correct data at any point um even though the data might not actually be on chain yet which is important especially given you have gaps

uh across multiple proposals but even when you have single proposal or multiple proposal in sequence um you don't want to be constrained to the 12C blocks block time and so um what the Gateway essentially does is it can respond and issue pre confirmations really really quickly so when we are running our demo we had uh pre-confirmation responses in the the realm of 20 milliseconds or so which is really really fast um and then then can also provide answers uh in regards to um specific queries on like what the state is or um getting transaction receipts and all those kind of things which is quite nice and here um we also somewhat separated the role of a Gateway from U the act of actually maintaining uh State

um just so that um the Gateway potentially can actually also be operated by um entities just like the Rel for example that actually don't need to maintain all the state and everything and we'll also um open source uh version of the Gateway that actually that we're working on and so the idea is basically um I said before you have this notion of a schedule and for that specific point in time a specific Gateway can issue pre-confirmation and maintain State and as um the pre-confirmation are being issued and the number of transaction reaches a certain uh threshold the Gateway can then basically create these patches and then post them onto the L1 and the um these can be viewed as L2

blocks so to speak and you know can be included in L1 transaction actually um then enforced when it's actually time for the gateway to um or that specific proposal to build the L1 block um but in the inter again they can make that state available um I think there was a question somewhere let me see the question was do you guys support L1 uh pre-com as well um just inclusion not execution so um in theory you can provide execution precom for L1 as well

but um that definitely um it puts a lot more constraints and the the sequencing itself um it it changes significantly because there's already a status quo on the L1 and certain kinds of returns that are expected because of the IM auction and so if you change that and do everything like on a first com first based surface um that will massively change the rewards if that makes sense that makes sense okay cool um so now um we're going to actually show you how this works in practice all right I guys um can you all

see the metam mask everything yes would you mind clicking hide on the the zoom message that's in the center nice thank you um so here we have um the Gateway that's uh running and then um from metamask I already set up the RPC so that is going to be routed to the to the Gateway yeah so now the yeah the Gateway has okay that was too fast but um so basically

the there you go so the this is kind of the what we think the ux could look like so the user sends a transactions and then for a certain amount of time the Explorer still shows it because the Explorer is connected to the Gateway so it receives this precon state ahead of time um and then it shows us preconiran-food.com you see the time stamp 493 so we yeah it took around 22 milliseconds to be sequence and then

it's ready to be queried by the by the wallets or the Explorer um and then what happens is that we create this um L2 batches which are right now there was just one transaction so we created a block with a single a single transactions and then that's going to end up on chain uh so after a while when that's landed on chain the this prec confirmation was s s which means that now the um L2 block containing this transaction has landed uh in an L1 block so essentially now uh this block enjoys the same kind of L2 L1

guarantees um yeah that's more or less the the the okay super cool uh very very low latency I like that um are there any questions from the audience on the demo is it relatively general purpose I know you guys were doing it on Tao there I believe that but I would assume it's relatively general purpose to apply that to any of the different alue Frameworks yeah exactly yeah so um yeah for for this uh for this demo now the we we worked with Tao but we actually also worked with a bunch of other teams and

um yeah this is trying to be as agnostic to the L2 as possible that makes sense thanks I am curious about the integration with with metamask can you talk about how that was done did you use a snap or did you mock mock the blocks or something like that yeah so um so this demo now mocks the blocks um so um I think we discussed this before we essentially um built this in such a way that the Gateway is responsible to make State available to whoever needs or wants to have access to

State until it actually lands on the L one so you have actually have this nice and smooth transition although we also spoke with metamask and currently um experimenting with uh developing a snap to have some better uh ux changes there and what are the the main next steps in terms of uh getting towards uh production and Main net yeah so from our perspective um we need to solidify some of this infra um and we're also going to open source um a version of the Gateway as well so for

now we only open source the RPC but we also want to make a Gateway version available um and then um most of the work is actually around um so working with the reg the teams that are working on the registration contract um so we integrate the look ahead that's implemented there and also things around slashing and things like that so we integrate that properly because this is currently and this demo also not enforced okay fantastic uh thank you so much Kuby and

Lorenzo uh next up we have the bolt team who will be talking about uh L1 prec confirmations yep let me share my screen all right can everyone see that yep cool um so yeah in this presentation we we also mainly wanted to give an update since our last presentation and our last status at Zu Berlin um so let's yeah let's start with what's new um so obviously we've deployed on Helder um alongside an initial uh registry for proposer Discovery so that's the same registry

that that Kuby was talking about uh We've also deployed a minimal bolt RPC which actually also does kind of the same functionality as uh as the Gateway in the sense that it provides a translation layer between what what language wallets speak and what language the uh the the precom apis speak in a sense um it also takes a look at the look ahead to proxy requests so that's that's also similar functionality uh on top of that we've been working on uh local fallback block building so as you know we do pre comes on on L1 um and we are compatible with PBS so in the case that PBS fails to deliver a valid block uh the side car

will actually build a local block that adheres to all of the commitments so that there's no liveness Faults um or or safety faults that that come from a failure Downstream in the PBS pipeline we also added uh support for blob transactions so type three transactions um and bundles uh so you can flash BS bundles with uh relative atomicity guarantees uh but uh alongside uh you get a pre-confirmation and we've updated our commitments API uh which you can find at the link here I will share the slides in the telegram right after um so yeah let's let's get straight into uh the demo actually um so for our demo we've decided to do uh an eth transfer

with an L1 inclusion precom uh showing a possible way to to also integrate with metamask uh we did not go the route of mocking the receipt and and so we took a different approach and now we send the signature request to metamask uh and then send the transaction actually to our RPC so let's go over there right now we'll send some eth to a random wallet request a signature from metamask and then we get an instant uh confirmation let me just it's not as quick as the GAA one you can see it's uh godamn 132 milliseconds so not as fast um and it will provide a link to the to

be proposed slot um so now we'll quickly wait uh for it to be actually included so that we can show it was uh successful sorry this is not easy okay okay there we go so we got a a Blog Scout link uh showing that the transaction was actually confirmed uh and then we can go to Dora the Explorer and actually see that uh the block was uh built by Chain Mount uh buil by bolt sorry with the bolt Builder so that was the the quick demo um and in terms of what actually goes on

on Hood we thought it'd be useful to show uh an excerpt of all of the logs um so the first thing is that the uh wallet sends a request an inclusion request to the sore uh the SAR will then uh read from the look ahead uh and proxy the request to the correct proposer sore uh it reads this this RPC endpoint uh from the onchain registry uh and then sends the request uh to that sore um the side car will then validate the transaction so it will validate the base fee the nons and the balance and as soon as it's pass passes the execution uh State validation it will uh respond with a commitment um it will also turn

these commitments into the constraints and send them to MV boost uh which will in turn send them to the relay and the Builder uh the Builder will then store them and as soon as it is time to start bidding uh we'll actually create a multi proof for it uh for the constraint proofs and send that block with the proofs to the relay uh the relay will also verify these proofs uh to make sure that the bit is actually El eligible for the auction um then as soon as uh M boost or the the modified M boost receives the get header with proofs request it will forward that to the relay and the relay will deliver uh the bid with the proofs um in turn bolt boost or Mev boost will also verify uh those proofs to make sure once again

that they're all valid uh and once that's done it will return it to the to the beacon client ready to be signed and broadcast um so yeah that was that was a quick demo in terms of next steps for us uh kind of divided into research and development so on the research side we're really look looking a bit deeper into all of the potential use cases um and also potential economic modeling and a bit of forecasting like what would this benefit proposers who choose to run this um what do penalties looks look like so slashing and freezing these are these are problems that are being widely discussed as well um Fair exchange is is an interesting one currently we we kind of

used the RPC the bolt RPC which it's in the middle as sort of a Time stamping Oracle which Can U Tim stamp requests and responses and make sure that these responses actually happen in time and in case a user is not not happy they can go to the RPC and request like um some evidence of of misbehavior um and we're also exploring other commitment types so bolt uh in general is a proposer commitment protocol of which which inclusion preons are a very good example of but there are potentially others that are very interesting um we want to move to heski by the end of September uh but before that on Helder we first want to finalize a couple of things uh so uh the commit boost integration we want to make sure

that's very streamlined uh provid easy ways for for validators to run these side cars through commit boost um also integrate their signing manager uh for exess security um we want to collaborate on the registry mentation which is not finalized yet uh there are a lot of open questions there um and also obviously it's it's uh it's a topic that that needs a lot of scrutiny because it's uh security depends on it um and then we want to finalize a constraints API which is uh how the Bold protocol interacts with the uh PBS pipeline to communicate constraints and and verify proofs uh there's also a discussion uh going on on GitHub in the link uh there and then

finally yes we want to we want to move to to holeski by the end of September with a more streamlined MVP that implements uh things that um come closer to an actual production deployment of proposal commitments and inclusion pre- cost on L1 um so that was it thank you uh if anyone has any questions I think we have time oh okay no questions I I have one I saw you guys added bundle support how is the bundle support working are you guys like essentially simulating the bundles and then essentially you you're guaranteeing adamy at the time the request is made but the adamy could be broken by later request is that kind of how it's done or

how are the bundle support done yeah so uh we provide atomicity not in the sense that uh actually yeah I made a bad analogy so in in the sense of flash BS you get atomicity on execution as well we just provide a guarantee that your bundle will if it's included it will all be included in the in the same order but one of the transactions could actually fail because we don't provide you with execution guarantees we only provide you with inclusion guarantees um so it is strictly just an extension of inclusion precom um and yeah the the execution guarantees are are U not implemented so that was that was a mistake on my part that makes complete sense that's

kind of somewh the guarantees you get round thir sequencers then in bundles got it okay did I understand correctly that the the pre-confirmation notification happens at the app layer not at the wallet layer yes so uh in contrast to uh the previous demo we couldn't get the mocking working uh so for now we use sort of like a more of an intent structure where we request a full signature from metamask and then actually forward the the the full sign transaction to our RPC using send draw transaction and then we use that response to create this popup uh that

you saw on the front end um but since the signature is requested from metamask and not actually sent through the metamask RPC uh we don't get a confirmation inside of metamask um and we are also thinking about how we can potentially improve that because the ux is is obviously not not great and metamask actually uh gives you warning when you try to sign transactions with uh which makes sense um so we're also looking at snaps and and various other options are you guys also looking into L2 prec confirmations or mostly focusing

on L1 so mostly focusing on on L1 right now there is in the research there is some overlap uh which I think is is great because we can tackle the problems uh for both L1 and L2 at the same time or at least the ones that overlap um where we do overlap is like some um other protocols might rely on forcing inclusion of a sequenced batch uh and that can be done through both uh but we are not not focusing on the actual uh sequencing and and pre-confirmation and can you briefly talk about the other

commitment types that you guys are looking into yeah uh yeah so I think one that I find interesting is uh sort of a Blog space claim type of commitment where you can get some sort of um blog space reserved for you in advance even though you don't necessarily know what you're going to put in it yet uh so this can be useful for protocols I want to offer things like gas Futures uh and stuff like that um we we've just started doing some research on that so it's not there obviously the fair exchange problem is very much more outspoken in that situation because the user uh gets a signed a commitment for a sort of blog space claim but then actually has to

deliver that uh payload so it's similar to the PBS Fair exchange problem um so it's it's kind of a a more difficult commitment type but we're we're definitely um interested in figuring it out okay thank you so much any other questions from the audience before we move on to the next demo cool thank you very much Jonas thank you so much um next up we have the switchboard team from never mind can you hear me yes okay

cool okay so this is a tao pre confirmation demo in Helder testnet we are switchboard of subsidiary of nethermind focusing on pre confirmation research and Engineering next SL please so this work is in collaboration with and funded by Tao previous slide yes and so huge shout out to Tao next SL and Sh shout out to the team ahed andu Mari mik small corner for making this all possible I am Lani presenting next slide

please so first let me give a design overview of what we are implementing so the PLC design our PLC design works as following first we split each 12C L1 slot into three for example uh four 3C Subs slots and at each end of each Subs slot the pre-c confer who is elected from the updated L1 proposer will build sign and publish an Tao L2 block to the network in other words they're preing the whole L2 block next Tao users will listen to these pre-con L2 blocks to know the result of their L2 transaction without waiting for the L1 inclusion of their transactions next side please so here's a sequence diagram of what I

mentioned so first the L1 proposer will call an L1 contract to register as a pre-c confer so they opt in next L1 contract will have an election mechanism to choose who the pre-c confer for that slot should be now next when the L1 proposer it comes to the L1 proposer turn to actually be elected what happens is that first the users will submit del2 transaction to The Tao Network specifically to the tyo mle next the L1 proposer will fetch these transactions from The Tao mle locally built and signed an L2 block then propagate the signed L2 block to The Tao Network next um full nodes that are listening to these pre-con

several times within one slot now at the end of the slot the proposer will submit an L2 block to the L1 and then the L1 contract will check if it's like the expected expected elected pre- confer and accepted and then later on a distributor who's like monitoring the network can look at the pre-com L2 block and the L2 blocks that were actually submitted at the end of the thought and provide fraud proof if they contradict with each other next SL please so like one of the unique features of our PC is that implements batch pre-confirmation what I mean by

batch is pre-confirmation is that we provide pre-confirmation at a batch level so here at the L2 Block Level for example this is what optimism provides with their 2C block times on the other hand there's continuous pre confirmations where the pre-con provides pre-confirmation at the transaction level in a continuous stream for example AR Prides next slide please so why do we batch so the issue with continuous pre-confirmation that it is hard to incorporate a pricing me mechanism this is because a pre-con needs to decide to pre-con a transaction just by looking at the single

transaction in a tip or a very limited number of transactions now lacking a ping me pricing mechanism is an issue because first the Searcher will Searchers in the network will optimize for collocation Network latency because the faster you read the pr offer the higher chance of inclusion you have so there will be a Laten Series this mean that value is not caed by the tip but it's rather leaking out of the system in terms of like these collocation costs or these like Network costs another issue is that Searchers might just like choose not to participate in this sling series and just Spam the to the netork L2 block with problemistic Arbitrage transactions so as a result this drives

up S Fe for end users because the L2 block will be filled by these transactions so if you look at like the ultra low latency blockchains and rollups that you see right now like Arbitron polygon and salana they all faces face this Laten series and these spam issue so the nice thing about batching is that batching enables pricing via auction within the batch so by being able to run an auction this mitigates latency Rees and spam because the Searchers will be incentivized to participate or like expressive preference in terms of tips rather than like paying for the lat like reducing the latency or collocating or be like just spamming the

network and another thing nice thing about batching is that opens doors to PBS for these pre-com L2 batches or blocks more on this later however we do lose speed of light latency precept is for example seen in the other demos so we'll be like two seconds or three seconds latency next slide please so that is it for the design part and the reasoning of the design next Marie will present the demo of what we did for H orer yeah thank you ly uh so at the beginning I want to uh give you a few few words about our ABS note which you

can see in this diagram in the center H this is our core component which is responsible for interacting with Tao clients so Tao proposer and Tao driver uh what's more it has its own dedicated peer to-peer Network so ABS nodes can share information about P confirmation s it also call L1 smart contracts and use Mev boost modified M boost for uh forcefully including blocks and here as as you can see those labels this is the flow for

the pre-confirmation so first we register as a prec confirmer PR prec confer then we we need to take transaction from the L2 men pool using tyo proposal and later we commit uh to this transactions and we uh we share information about the confirmations between notes and next we uh we want to advance the head of local L2 chain uh and after that we can sub me to block using blog proposed smart contract and and

finally if uh uh until the the slot of the prec confer the block is not included yet we have to forcefully included uh so we use M boost in this case uh not to be slashed yeah and uh for what we achieved on H the network you can see those highlighted labels yes so the development is in progress and we are able to AFF for now to to provide those free operations uh so we we were able to take L2 operation L2

transactions uh we Advanced the the head of the L2 Network and we sub Ed a block and here is the screenshot of the uh logs from from all those modules I mentioned and let's look into it this is first our script to create some uh L2 transactions three transactions in this case and next one we have a logr tao proposal it just uh gave us three transactions which we

created and those transactions uh went to ads node this this logs are came come from the AVS nodes the the main piece of software and uh what's interesting here is that we uh after taking transactions and advancing the head we just call this proposed new block smart contract at at the bottom and this uh this piece of logs is from Tao driver and uh at the bottom again you can see new L2 block inserted this is

this is what we ached on the heler so we are able to to have it on chain and this is a screenshot from block Explorer where we can see this new blog proposed transaction uh executed yeah that that's it okay thanks um next I'll give a current what where we are and like future directions side can you go to the next slide please uh so the current status is for the smart contract we've implementing implemented

an election mechanism based on an optimistic look ahead submission design he also implemented the pre-confirmation disputes for the so the slashing logic right now we are actively working on uh ecdsa to BLS mapping design because like the pre- confirm pre confirmations will be signed by the ecdsa but in the look ahead we have BLS and how do we map them it's kind of like the active private designing furthermore for the AVS node we are working on implementing the interaction with the existing contract that we implemented also we implemented AVS P2P uh for future directions we are thinking of addressing first addressing

the fair exchange problem so we have some ideas but it's not implemented yet we want to improve the election mechanism so we do not rely on an optimistic look at at submission and also one interesting direction that we're looking into is L2 PBS so like in the design that or like diagram that we've seen so far the L2 pre-com blocks are built locally by the L1 proposer but the one propos is not like optimized for building these L2 blocks so naturally they would want to Outsource the block building and how do we do that one way that we think that makes sense is that we can piggyback the L1 PBS Pipeline and build and let the L1

PBS pipeline build and preon L2 block so like split the L1 slot into like several of these rounds or these sub slots and run the PVS pipeline multiple times to get the pre- confirmations so this way you get pring and you do not introduce any external actors to the system that's it um yeah thanks everyone for listening oh not yet okay sorry yes fure reading um first first and foremost please take a look at our Tao PC design doc it has a lot of the design to see around the card dra and slashing and look ahead where we did not discuss in this talk and strong maning B pre-confirmation is a research post that

I written more about like the negative externalities of the continuous pre-confirmation and Bas pre- confirmation with multi moost is about the idea that I talked at the end of pdb and L1 PPS pipeline to provide right l2p confirmations okay that is it yes thanks everyone for listening and yeah let me know if you have any questions thank you so much very interesting to see three completely different uh approaches to prec confirmations and one question I have is on um arbitrum being continuous my understanding is that they have 250 Mond

slot time so they do batching uh but I guess it feels continuous and so maybe The Sweet Spot is like somewhere in between where we have these these batches but uh still very short slot times okay yeah thanks for the information I mean one one thought on badging is that uh if we have you know 10,000 TPS for example the overhead of dealing with things on a transaction by transaction basis might be too high and so batching might be just be necessary uh for it to be practical um but one thing that I you know you mentioned is is on on the

searches you know potentially spamming the chain the way that I think about it is that the the Gateway has the last look um and so it will it will basically be adversarially picked by if the Searchers keep spamming they will always be be losing money because I either they they're kind of offering a price that the Gateway is not willing to sell at or you know they basically sending a stale order that now the Gateway can can just pick and abuse and so um the way that I think about it is that pre- confirmations is really for users that are willing to pay this this ux premium it's not for Searchers because they will just get picked by the uh by the Gateway yeah that

well yeah I think that makes well let me think um so yeah I think so you're saying that the Gateway can filter out these field transactions that kind of the well the Gateway is only willing to sell the block space at Fair Value Plus Epsilon where Epsilon is like the the ux premium let's say but the the Searcher is only willing to buy at you know fair price minus Epsilon so by default you know they won't agree on the price but if they do agree on the price it's because the Searcher you know sent sent a request a pre-confirmation request and now the request is stale and so now they actually are paying you know

Fair Price Plus Epsilon and so they will be losing money as a as an arbitrager yeah I guess so but I do think that these kind of things are like kind of happening in these L Toc blockchains and then like there are spamming and I guess the issue is like whether this spamming results in like the users fee increasing or not and yeah as long as that's not happening maybe the spam is not an issue like Searchers are just missing out on value and not an issue but yeah that I'll be interested in what actually happens I mean as Connor wrote in the chat the the sellers of blog space on on

platforms like Sol are today are unsophisticated and it's kind of interesting because we're we're probably going to see you know pre-confirmation tips happen on Solana before they happen on theeran so we can reuse a lot of the R&D that salana will have to go through yeah completely I think Solana is kind of front ront in pre- confirmations or based pre- confirmations right I just had a quick one is uh Mr meth boost is that a fork meth boost um I think it will be a for Boost but we haven't started implementing anything so yeah You' be curious if there's something Advantage wise you get

over something like commit boost you know I'm kind of Shing my own book here but just would be Keen to explore that with you guys yeah definely a Justin in your Searcher view do you see Searchers waiting at near the end of the block to put in their transactions then after the use ones are cycle it would be as part of the the block building cycle at the at the very

end of the slot and they would be working with Builders just like they they work with Builders today and and what about like ofas where like the user transaction is part of the bundle for example right so um so here I have a new name which I call prices so the we do need to price the pre-confirmation tips and this is something I've I've talked about at ECC and the basic idea is that um the the user sends that transaction to the Gateway and then the Gateway Shar it with various prices and then the prices

are taking on the me risk for the Gateway so the the basically the Gateway is is always making a profit by giving out a pre-confirmation and then the the various Searchers are competing against each other to provide the the smallest pre-confirmation tip to to to the user so and and in addition to that you know they they would be solvers in the sense that they'll be solving the intent of of of the the user so so yes there is like this uh per transaction OFA going on uh which simultaneously solves the user's intent and also prices the the the pre-confirmation tip to be as

competitive as possible and from the P perspective of the Gateway SL proposer um they're guaranteed that they're making money by giving away this prec confirmation so it kind of Acts in that sense kind of like an OFA for we're thinking about doing something similar in that sense on that actually could be helpful for some of the preon projects where we have a super Builder called javalin and we're going to have a Gateway for it where users subit their request to this one RPC and then you have other you essenti builders that all compete for it and because they're all cross roll transactions where the Builder has to generate the second part of it because you can't give every single user mint and burn rights for tokens so you need to have like a list of builders that can move assets across

different chains for this in this case they would be able to compete for that and that was kind of how we were think about using an NOA but they could also compete to get the best precom on different markets as well so yeah right and specifically competing on the pre-com tip yes right so in that setting then that let's say the Searcher wins the OFA then is there bundle precom um so so yeah the the Searcher can add their own transactions that you know help fulfilling the intent of the of the

user um so yeah so so long as the the user's intent is satisfied you know the Searcher is allowed to insert the their transactions as part of the bundle okay so then the pre-com are for Searchers too it sounds like yes uh but um then they're not consumers of pre-confirmation they're they're they sellers of pre- confirmations they provide prec confirmations okay fantastic go so in that case the Searchers are essentially

saying I own X number of block space um I'm going provide the user the lowest amount possible so then they could use something like a block space future to price it on the precom slide so the Searchers are basically trying to price the most efficient preon possible by efficient I mean lowest price to the user with the Searchers don't make profit exactly so the the Gateway owns the block space and then they try and allocate it as as efficiently as possible they want to guarantee a profit for themselves and then they basically open it up to the market of prices SL Searchers SLS solvers uh who as you said provide try and provide the best price for users that still gives them uh an

edge okay perfect let's move on to the very last uh demo uh from Prim morat the floor is yours thanks J um I'm going to go over uh a very basic system setting uh we have a CLI demo um momit live on holky so if you want you can go Hands-On and get your own uh execution pre-confirmation um so momit places execution pre confirmations by default these are on L1 so it's kind of a Searcher oriented or solver oriented thing so if you imagine somebody let's say using something like metamask or a wallet essentially um they would go through some sort of process C like the one that Justin just highlighted whether

it's an OFA or something else and uh the the pricers or the service providers in that case would use something like M commit to kind of source these commitments right so um anyone can join using a bidder node uh the wallet itself could theoretically but we don't anticipate that uh to happen we anticipate more sophisticated actors to do do it and then they can communicate with providers of execution services this can be L1 L2 um and it's it's agnostic both to to the chain and the actor uh but essentially um this provider is able to make the decision on whether they want to commit to an execution uh of a transaction or a bundle uh so it has um kind of bundle or Mega bundle support and if you're

looking for inclusion or you want to kind of delineate your risk between execution and inclusion you can add the transaction hashes that are allowed to revert in the bid payload so what happens is once you send a bid you uh receive a commitment from uh a provider or a set of providers depending on your setting and that commitment goes back to the bidder in real time optimistically but it also goes to the me commit chain which will then um you know at settlement time check for its um you know whether whether it was sent in a acceptable time frame and it will also process things like Decay if it was not so uh the bid is able to Decay and everything here that you see is basically um you know fully uh invisible to anybody else uh they would only see a

hash up until the set time that comes on after the block uh for which the pre-confirmation is for has been already confirmed on chain so um and and really what happens is uh to provide the execution pre-confirmation the the provider underneath has to do a series of actions in order to deliver it right so in the case of ethereum what they would do is run kind of a simulated block with this transaction uh and you can name that like ethereum prime or something and then um they would essentially build blocks or try to deliver blocks that conform to uh some version of this transaction executing right uh and and they would essentially send that over to the proposer whether the proposer does it relay does it block

Builder does it doesn't matter um uh but uh then that um block would make it onchain and then currently there's an oracle that's implemented that is um you know uh centralized but it's becoming an AVS and we're also working with some proof teams to um you know make this into a full-on proof so that there's no centralized dependency but today this Oracle looks at the L1 block to see whether the commitment was delivered or not and then uh Rewards or um punishes um or slashes the providers so um that's generally the the setting what I will now do is is show you a brief video um of of how this works in the CLI essentially uh you're able to um you know specify a bid so in in here I'm

pasting a bid that I've preconstructed but uh you're able to basically specify excuse me which time uh frame that you want this bid to be valid in through uh setting these Decay start and end time stamps so you can you can effectively create your own fill or kill order by making the Decay end time stamp very soon or you can make it at the end of the slot so that uh you know you have basically more time for uh receiving a commitment so you have this optionality and and and the fair exchange problem is solved in in the most kind of economically efficient manner in this way because the chain acts as the coordination agent between the provider and the bidder so uh once you send this you uh receive a commitment um and there's a digest in there so that you can look at it um uh I

think I made this video when I was in Brussels and the only provider at that point was in North America so as you can see the speed is a little higher than some of demos that I've seen uh but you know you can collocate or you know as more providers are on there that are geographically distributed you'd be able to get um different latencies um but yeah everything you need for your pre-confirmation is in this commitment um including some of the details around uh decays and whatnot um and you can receive also multiple commitments from uh different actors depending on the settings so if it's an L1 you'll want all of the registered block Builders to commit to you um if you have a marketable price on your pre-confirmation this should happen because they're rational actors but in

the case where you don't have a marketable price you might have situations where uh some block Builders do come in and some do not and then that's uh gives you some information uh so again these are uh execution pre-confirmation so as soon as you have this commitment you know that your transaction will be executed by that committing provider which uh in in most L1 cases will be an L1 block Builder um now the last thing I want to highlight here is um uh essentially I'm sorry um so we we recently had a had some analysis on some of the bids that were done uh and some of the execution pre comps that were delivered um this post post I I posted yesterday on the on the group that you can look at but

essentially there's a number of Hol sky blocks in there that are pretty interesting to look at we're seeing pretty erratic um bidding behavior from biders this is mostly because one there's not much State contention to you know test net eth is easier to come by than main net eth but what's really interesting is that there were 807 uh pre-con informations that all added to the block value to some degree so here we're seeing the distribution between prior fees and pre-com bids in blocks and uh it's very interesting to see this distribution I think people are experimenting with going 5050 or going all in on their pre-com bid depending on their transaction um and uh you know our next steps is obviously to uh bring this

to a more closer um environment on mainnet so that we can actually get real data and and collect uh how execution pre comps work in um you know State contentious setting um so yeah um that's mostly it amazing thank you Murat any questions I guess Drew has been asking everyone uh whether or not um commit boost is being used are you using commit

boost in any way or do you have plans to use commit boost not on this well you know the validators that have opted into this are on Holi um but we do have we're in touch with the commit boost team and the Helder efforts we have some early efforts on Helder so as um you know as things progress we'll have more on there as well uh we're agnostic to Mev boost boost or maybe I guess Mr Mev boost um so we're happy to work with all of these um yeah uh we're compatible and then we're also thinking of some special modules for um uh something like commit boost but that might be a little bit more medium to long term also for folks who are interested

in doing ofas or um are looking at maybe more on the consumer side of things uh where you know the OFA could leverage something like Mev commit please reach out to us um we'd love to kind of collaborate on those and um you know again uh you know we've developed this chain that has very specific uh you know additions around you know being able to read milliseconds instead of the ethereum GU which is you know second based uh which allows you to kind of launch contracts to kind of help a fair exchange problem that some some projects are dealing with so we be very interested in working with you in um kind of leveraging the map commit chain uh to solve it for you and you can have your own contracts on there and use some

of the primatives that are available I have a question about the the final data that you presented like who are the biders in this like this test net like I'm interested in like what their intentions are are for recording confir um Searchers and solvers mostly today uh there are a few researchers uh but the majority are Searchers and solvers that are kind of testing the um the network uh and then they have like requirements on how they want the bids expressed Etc so it's helpful for them to go Hands-On

and get familiar with um you know how uh execution pre- comps work on map commit I see thanks yeah in the L1 setting it's you know the the the bid expression is at least oriented a little bit more around um like bundles so you can like pass let's say three transaction hashes and one of those transactions could be uh an end users transaction let's say it's a you know a sandwich of some sort right um and in that setting you could also Source the um pre-confirmation for the end user too so you could run some sort of OFA and the winner of the OFA uh or even you know during the bidding process could use uh Meb commit bids to actually

get a price on uh what that should be and and and deliver it to the end user all right thanks again uh we're just on time at the at the hour so we're going to close off the um the public part of the conversation and open it up to the the private part of the conversation where anyone's welcome to uh give us an update or ask a question or bring up a topic that's on their mind