Ethereum Sequencing and Preconfirmations Call #10

Transcript

okay welcome everyone to the sequencing and pre-confirmation call number 10 uh today we have uh an exciting topic uh namely um commit boost and there's going to be three different uh presenters uh Drew um uh QB and three Ram um but before that I want to give you a quick a super quick uh update on the the B ecosystem so I have updated my my slides uh which I will share in a moment okay so a snapshot of the based ecosystem there's been quite a few uh

changes so first of all we have uh the the rollups that have committed to become base rollups uh we now have a new um player in the scene puffer who is uh committing to build a base rollup in addition to uh coinbase with their key Value Store rise and Tao and actually another piece of news here is that Tao is now live and since yesterday is actually technically a base rollup um we have various chains existing change that might migrate to Bas sequencing in the future these are the ones that are most actively uh considering um becoming a base rollup for various reasons uh we've had Aztec

give a presentation in one of the previous calls and ens is very interested as well and this mystery top rollup um which uh hopefully will be announced at some point we also have uh gateways that are uh interested in um in helping out with pre-confirmation so uh Estus on the last call um signaled that they want to run a Gateway uh I guess in addition to Titan and ultrasound on the startups side of things uh we now have uh six projects uh that are helping out uh build infrastructure for for pre-confirmation uh chainbound espresso Luan Mona Prime Inspire um so two new names here um

Luben uh which is basically a Rebrand of chi protocol it's the same team I think they're rebranding to uh to to focus on on uh on pre-confirmation and Mona is a team that was in stealth I guess until today um and they are also working on on pre-confirmation and uh I also added Prime F which was I guess an Omission on on my end in the previous version of the slides and then uh on the R&D side of things uh we have the two consultancies here lime chain and nevermind and the exciting thing with nevermind is that they have now a dedicated team uh sub team I guess Within nevermind called

switchboard so it's uh switchboard nevermind. I believe for for more information and this sub team is dedicated uh to to sequencing and and pre-confirmation and we also have yet another team uh which was inst stealth until today which is commit boost uh which we'll be uh doing the the presentation uh uh today so without further Ado I guess I'll open the floor to to Drew uh to uh talk about commit commit boost awesome thank you Justin and it's awesome to see all the new names getting added every every week and I'm personally very excited for zuin next

week which I think a lot of you will be at um to to dive for full almost full two days on these topics um and workshops and everything so I'm excited for that um before we get started on what commit boost is just wanted to give a bit of background my name's Drew um I love ethereum I been in involved in it in different ways since 2016 and 6 weeks ago I actually quit my job to uh work on something in ethereum I wasn't really sure what it was going to be had some ideas ended up being down the rabbit hole of commit boost and here's here's where I am and part of how I got here was I don't know if it was Justin told me directly or if he said it in a

podcast but at some point he was said something like if you want to work on something interesting in ethereum you know find new ways to use it and ever since this post around Bas sequencing like many of you all started to see you know more broadly for me potentially the unlock around um proposers making commitments and uh you know that that really unlocked an Avenue for me so I had been writing research while I was in my previous role and just speaking with the community more broadly and uh it was fortunate enough that Ian ler when I left was willing to gave me some short-term funding um which I'm working with and then I had also known KUB at Titan for some time and you they just a great Dev shop and so he was willing to

lend some resources to kind of take this this idea and framework that we've had in mind to to start putting in production and putting specs around it so we'll talk about what commit boost is but I do want to give Shri RAM and Kuby an opportunity to initially talk about their motivations and thinking behind the initial backing of this but before they start um just up front commit boost is in intended to be a public good uh it is intended to be open source um that's the direction we're headed and I'm super excited about that well we started sort of with these initial folks the idea is to get many more people involved and rally behind this um you know we we see propos your commitments as a huge unlock but some risks which we'll talk about and commit boost is our attempt to try

to mitigate those risks but still see the Innovation happen on the proposed or commitment side um so with that I'll kick it over this ROM to give a a little bit about motivation vision and and everything from his side and then pass it over to KU and we'll get started uh thank you drew uh thanks Justin for putting this call together um proposal commitments has been one of the um one of the directions we've been uh interested in at i l from pretty much um the very early days um I gave a talk at Stanford in 2022 uh on me boost Plus+ which was a mechanism

to split um you know to split auctions for me using restate commitments so we think of proposer commitments as a broad unlock to the ethereum ecosystem because now proposers can make promises that uh they follow a new set of logic when they build their blocks and I think there is a lot of new innovation to be unlocked here pre-confirmation is One Direction but there is I think uh even more things like block space Futures things like event driven actions where like proposers promise that if a certain event happens they can actually go and trigger a series of

actions uh you can have um many you can have things like um uh Thresh should encrypted mols you know where a proposer promises that they only include encrypted transactions I think all of these create like a Swiss army knife of tools to expand uh ethereum more broadly um when you think of these different kinds of proposal commitments um there is a complexity where there are definitely multiple clients multiple middlewares and how all of these act I think this is a big question and and many of us all are

hearing are here building different pieces of it and the the vision that we had and when Drew uh wanted to start something in this area we were excited because the structure of this is comit Boost is focused on bringing together multiple teams to develop an open-source public good that is agnostic of various dimensions so agnostic to proposal commitments agnostic to precon the type of preon agnostic to restating agnostic to relay agnostic to the particular transaction flow and it fits in with our vision of actually expanding the scope of innovation in the ethereum

ecosystem um the why are we involved we are you know as Drew said a short-term funder for you know Drew's independent work but broadly the reasons we are inv involved are number one we see this are a major Innovation for ethereum uh we have had this Vision that you know and there are different ways to modulate and contribute to the me ecosystem we wrote papers on you know other kinds of U uh mechanisms to address me like for example using how do you get consensus protocols which distributed first in first out

commitments for example so this is a direction we've been interested in for a long time on a research uh basis and finally commercially you know if there is a broader Suite of standards that enables proposer commitments it helps Igan Lair play a small part in it in in proposing restate commitments so that's you know clarifying our interest I I'll stop with this and hand it back to tr yeah maybe kby too if you can give your nich perspective thank you shiram and it's 6 am his time so I appreciate you triing get cool I'll try to keep it short um so I probably know a bunch of you already

but for those of you who don't I'm Kuby I'm one of the co-founders at gataka and we are probably most well known for our block Builder Titan which is one of the larger block builders in ethereum um but we also recently launched a relay um I guess gataka more broadly is really focusing on building highly performing neutral ethereum infrastructure um which is uh one of our endeavors with the block Builder so we are the only larger block builder for example that's not a trading firm um and as I mentioned before we Rec recently expanded into running a high performance relay and actually developing a new relay from scratch and just as part of a effort to sort of um expand and develop

different kind of ethereum infrastructure um we naturally also came across um the meth's clients um we had been thinking about proposal commitments more broadly in general have been part of obviously the pre-confirmation calls uh pretty early on um and I've known Drew for a while so when he got really excited about it and asked for some engineering resources um given that that's one of the things they really good at um we I guess we're willing to to lend a hand so yeah that's where we're coming from awesome thank you kooby um let me uh share my screen here and we'll get into the

UHS that go full screen in one minute all right should be full screen now yes perfect um nice stock photo from the EF uh website but um you some of the agenda we'll talk through we already got through introductions um talk a little bit more about like from my personal perspective what I see around proposer commitments um the potential challenges I initially saw and I think others are starting to see around even just within pre-com and then how commit boost tries to help uh unite folks and um you know still see the Innovative Vision but maybe create a safer environment for proposers themselves um some of the Divine

principles that we have um when we were thinking about this initial framework and then uh some more boxes and arrows um that Kuby will go through and then just open questions in Timeline um that we we have in mind um you know I will say not all this is baked it's it's early um there's advantages and disadvantages to fully baking things and bringing out I think our main mission was to engage the community as early as possible so maybe a lot of the questions we won't have answers for um you know a lot of the designs is still an open thing this is just an initial framework and um so just if folks can keep that in mind we're keen to engage and get feedback from the community um this is how I kind of see proposer commitments um got a nice meme

I'm really bad at memes so I feel like this is a top of my game that I've got but sort of three quotes that I've seen recently in Publications and even outside of pre-ms just more generally um you had the first one from Barnaby who I think paints an awesome mental model of it's you know can we potentially give the proposers back some autonomy to create a template that others fill I think that's like a very powerful image of at least how I personally see proposed commitments and then Julian touched on this in his uh publication where he says you know maybe they can just specify some portion of it in in some way and then the last quote is from italic one of his recent posts little more of a leap but it's again it's kind of this this uh mental model shift of

can we think about the block itself in a different way um and that's how I kind of see proposer commitments uh enabling some of that Vision um yeah that's how I view it here are some examples of today's proposer commitments uh obviously uh from Austin so got the cowboy hat around pre comps because I think it's where a lot of the focus and energy is around but we've already had proposed coments things like PBS we've been talking about inclusion lists which I see as some form of a proposed commitment um you but there's other things out there Beyond this I think shiram talked a bit about this but there's going to be at least in my view um and I I hope others share this a broader set of ideas that come out that we just aren't thinking about and some

of them actually may have nothing to do with block construction U maybe make proposers Mak commitments for other things uh yeah it's a longer term Vision but still some of the things that I've thought about but when we dive into just um hyperfocused on pre-ms and many of you have been on these calls um there are quite a few teams building all the pre-s different standards that they're pushing different ways to think about how they connect with the proposer and with this what we started to see was uh potential risks for proposers specifically and the ethereum network more broadly number one fragmentation which you know can come through in a couple different

flavors uh one being proposers running multiple side cars that all support these different pre-ms or proposer commitments more broadly um we see some risks around this or at least I I personally did number one um po devs already have a hard enough time uh if they're then going through upgrades and hard forks and having to um think about you the five different implementations uh it may be difficult uh yeah number two it could be very difficult for proposers themselves to manage all these cyar I think sophisticated actors I'm sure will figure it out particularly home stakers and so it was you know how we thought about is how do we kind of unite that into at least just one side car where they can opt into all these things and then number three is just uh

potential lack of transparency around what's actually happening in network you know when things go wrong um how do we responds and even proposers themselves you know tools and uh standardized uh out of the box um you know engineering things that help them have transparency into their own box so you let's say a one proposer commitment has an issue spits out a bunch of logs overloads their box and they miss a slot it's um creating standards around how uh proposers interact with the outside world to reduce those types of risks um so these are the the things we saw and so with all that in mind we came up with this concept of commit boost and um there's quite a bit of text uh still forming this probably will create into

some kind of you know Mission vision statement for what commiss boost will be but um in essence it's standardizing the last mile communication between the proposer and the proposer commitment protocol and the focus for commit boost is to make it as seamless as possible for a proposer if they choose to opt into any proposer commitment so like sh was saying up front it is designed to be agnostic to anything the entrepreneurs and Builders want to design it doesn't limit that design space it just is the interface of how proposers interact with those teams and provide different things and and with that what we're thinking a lot

about and talking with validator Des on is what types of tools off the shelf would you want to monitor what you're opting to what you're opted into is doing how you're opted into it when you're opt into it you know how your signature is provided a whole host of things that we're we're trying to think through and so this is really a middleware for proposers to interface with the outside world or proposer commitments more broadly uh and that's the main part we're trying to standardize and think deeply about and then have unification around within the community so the design principles that we've sort of at least initially thought about this framework from we've p on this a lot but this is going to be a public good open source you know I think broadly the vision is in some way for

what commit boost becomes is like a client team um it's a good and bad analogy because Acquisitions in the past but that's that's kind of the mission and vision is it'll be Grant funded non-vc funded type of structure well there'll be a couple people all they do is fully focus on this middleware and support things around upgrades es and flows of ethereum as they come and go and think deeply about that um the other thing we thought a lot about and I emphasized this was optionality so we don't want to design something that immediately eliminates some path for proposed commitments we just think we're really early and we don't want to you know enshrine a certain uh full full uh transaction flow of like let's say pre-com so trying to leave that open uh the latter four on the slide they're all kind of tied together but a lot of it I

hit on which is around safety and just obsc but making it easier for proposers to understand what's happening uh within their and what they're opting into uh how they monitor that uh you know event Loops to ensure their safety and soundness and and these are the types of things we're we're hitting on I won't go through all these but you'll see modularity observability and transparency as a as a key thing throughout the design so I'll pause there um I'm going to hand it over to Kuby to actually go into the the meat of what this is before we uh take take questions um but yeah let me uh sharing here

kby yep um just before I get started just wanted to say again that this is um like an initial high level spec and none of it is written in stone and generally also from an engineering perspective the question we are kind of trying to an ask ourselves is like how do we move or how do we evolve the current proposal commitments that we do so um I guess the subset really as a proposal committing to a header by a MF boost um how do we evolve the current infrastructure to something that's more generalized so we can support new forms of proposal commitments I.E pre-confirmation for example and can we do that in a way

where in the short term for example we don't need any consensus layer client changes or things like that um so just to keep that in mind um I'll share my screen now and let me know if you can see this yep okay perfect nice so I guess just starting from a very high level the idea is that commit boost is essentially one side car and this one side car can basically instantiate multiple modules now each of these modules would essentially represent a propos a commitment protocol

and for example a proposal commitment protocol could be Mev boost so vanilla Mev boost or it could be let's say partial block auction uh it could be a preon confirmation module and each of these modules basically could also be implemented by different kinds of teams so the idea is not to um enforce any standard of specific protocols but more create a generalized platform for developing these kinds of protocols um then the other part is um I'm just going to switch to the other slides before coming back that as part of developing Comm boost we basically Envision developing an SDK uh so from a

developers perspective and in order to build a commitment module um you have a tool set of certain Primitives that are standardized that on one hand make it easier for the protocol to then interface with the proposal but on the other hand for the proposer or the node operator also to have more confidence to actually instantiate such a module um and um I'll go into some of the specifics um which Drew also covered um what that we are thinking about now so for example one of the key things is um Telemetry and logging so um even think about uh let's say me boost today like if you in let's say you instantiate a module that implements the

M boost protocol you you you would want to have some insight into let's say what kind of Geth header requests you're making who you're making them to what is the latency for example um when you're getting responses from the relay and a bunch of things that basically um can be nicely abstracted away from the developers of the module and then um on the Node operator side you can Envision them just simply running something like promethus um plugging it into a grafana dashboard and you have realtime insights into what your side car is doing what kind of specific modules they're running not just um what specifically the modules are doing but also things around resource us like CPU um disk and a bunch of other things um the other

part is um some of the other Primitives would uh include um requesting a signature because at the essence of making a proposal commitment is basically the proposer committing to something via sign some signing something and so a lot of the thinking will be around how do we require the signature how can we do that in a safe way and um abstruct it away nicely so that like multiple um different kinds of implementations of protocols can actually tap into that and then there'll be a bunch of other um just Primitives around like responding to certain events so you can think about like a get header event that might be exclusive to a specific uh module or a get payload event and things like that um so then

going back to the cyer itself um now there are other two key components so one is um something we now call a system manager which will basically be responsible for instantiating each of these modules um and as part of that um some of our research conversations um with some node operators um revealed that they for example really really care about use resource usage so specifically thinking about a context of instantiating modules that might be newer and less proven there there's like a lot of concern for about around there being bugs and you know it going out of bounds and I think one of the examples

that Drew mentioned which is actually very common is U like too many logs are being printed saf to disc the dis is full and the entire node goes down and he misses Lo um just simple very like operational things around operational security um then the other key part is um the signing manager and as I um described before this is going to be the interface of how these different uh modules will request signatures and again this is one of the key parts that we really want to engage with more people about and get insights into how we do this in the safe way so um what kind of things can we sign what kind of keys will we use like will it be proxy

keys will it be the direct private key that the proposer uses um so there are lots of questions around that but uh the idea is how can we move towards the world of more standardized proposal commitments how we can we request signatures for things without doing any consensus layer client changes and currently after having had a few conversations um a lot of the node operators actually use remote signers in key managers so uh some of these widely used ones are with free sign and Durk which are there an example um but basically this the signing manager will be able to provide interfaces to request signatures to these key managers today

out of the box and um this way we would be able to not have to go through the current consensus client and force any kind of changes um like a key part of this is basically that it's fully backwards compatible and in theory could get like 100% adoption while still for a subset of proposal that have a more sophisticated setup U with these key manager um actually request signatures for any kinds of commitments like pre- confirmations and that should hopefully also get us to a stage where at a certain point we have enough learnings of how we actually want to do this in a safe way and potentially even push a CL change um then I think the final bit um

I want to talk about is as part of this commit boost effort we we also working on developing a testing Suite so as Drew mentioned one key resource or one part of this uh Endeavor which usually Is Res resource intensive is when hard Forks or upgrades happen to make sure that nothing breaks and everything works and so the idea is basically when you have multiple teams building on top of this like common standard um that there'll be tools and test Suites that the base layer will uh be fully supported um as the test Nets will for example start upgrading and then um as long as your module logic is compatible with whatever the hard

fork or the upgrade um actually affects um you can just plug it into this commit boot S car run the test suite and you're you can have enough confidence around being compatible and supporting the change um so let me see yeah those are the final bits um back to you some things could be let me just share my screen again sorry some Logistics here all right awesome thanks SC hope that gives folks a little more context

to the abstract we're talking about and you know that I've been talking about and again our goal and we'll get into this is just we're early stages we don't have all this figured out we are working on some de Nets to even put more context around this and trying to get you know as much documentation around this out it's just practically like trying to meet people aggregate research think through things and engage with folks this is kind of the stage we're in um open questions that I'm continuously asking myself and you know welcome others to add questions SL help answer these slash you know provide their own answers but um are there any added risks with commit boost and the way I see it is it reduces risks versus the direction we're headed but one of the core

questions I think we as a community need to ask ourselves is are we comfortable with the current route we're going down which is a lot of teams building these things which again I personally don't think is the right uh route to go down but rather create a platform that all of them can build on that standardizes it but there are trade-offs with that and fully acknowledging that and um you know that's that's one Avenue um standardization is not always good um sometimes it does limit Innovation that can come it also can create things like Tech debt U Down the Road um hopeful we're able to learn from historical things and think about this but you know it is one of one of the downsides uh centralization uh the one thing I'm asking myself is can we actually use

this as a way to uh promote and improve standardization uh and in particular are there proposer commitments that find ways to reward home stakers and can this enable that and can that unlock that for them and make it more seamless for them to opt into that that's one of the key things uh challenges with current design emphasize this we early and keing to get feedback uh one of the core questions uh you know I wake up in the morning when I'm sipping my coffee staring out the window I think about is you know would vitalic run commit boost I think that would be you know the dream Mission we would have and kind of the North Star we're we're heading trying to head towards as we we think about this and would encourage the rest of the community to to challenge it in the same

way um next is timeline this is kind of Jus in the same timeline just to change the wording uh you when he talked about this in call number seven uh we got you know started to think well maybe we can align with that and help support these shelling points and you know push the product Community as well um so that's what's here Zub Berlin next week we talked a bit about this but we will have a devnet and we've been working with a couple promps teams um for initial stages of that engaging with folks like what Justin had a slide you know chainbound um Prime Mev uh espresso like all the guys I can't name them all but you know these these people on the slide and uh hopefully we'll have a couple

modules actually live and um the goal in Zuber L at least from my perspective is to try to understand what every team's doing we have a lot of presentations on that I know this is you know Justin's Grand Vision too but have a lot of teams present and then understand the differences in how they're approaching things and then the second day have a lot of workshops to discuss okay where is there overlap where can we standardize even outside of commit boost but commit boost being part of that conversation um post Zuber Lin the ECC we're hoping to do a lot of iteration actually write more code get more specs out there um engage with a broader set of people I think is really important so helping others contribute to the code uh the effort testing things and Dev Nets a whole host of things and then post that

ideally by end of summer actually have audited uh commit boosts ready to go and testing and production and hopefully we're Landing pre-ms uh by the end of the year uh that that's kind of Justin's vision and we're here to try to help push that forward with that I think that's all we got happy to take questions here's the initial post we have uh there's going to be more coming particularly in the next week week and a half we're just sprinting towards uh Zubin amazing uh thank you so much Drew for the presentation and as well as QB and three we already have a question uh from Ben hey there hey uh first of all I think this work is awesome as you know

um uh Drew I I wanted to maybe just Reas one of the questions that we talked about in our call the other uh week um and also maybe before I ask the question since you did mention it also here advertised that after Zuber Lin there's going to be another workshop on this that Drew is going to lead at uh at e CC sequencing day so um for those of you who will be attending East CC sequencing day uh there will be an opportunity to Workshop this or anything that wasn't already answered at Superland um so the question that um that I have is you know one of the motivations of standardizing this stuff is you know as you as you said at the beginning is to not have you

know a plethora of different sidecars that validators have to choose from uh and that's going to be really inconvenient and annoying and I think that the the question that I have though is that is it enough to standardize the part that you are talking about here which is uh sort of uh um you know a protocol for signing commitment when there could be many different ways of enforcing those commitments that we see many different proposals from enforcing things with collateral that will be slashed to you know um potentially some form of insurance that a user can collect from to something very different like building a suap or just using sgx

to enforce the commitment and I'm uh not to mention that there's many different types of commitments and ways of formulating those amendments you know um sort of a language for uh user intent that the proposer is promising to satisfy are we inevitably going to end up with many different implementations that uh you know that proposers will will have to run all of them you know in order to be able to support the various wallets that are being built that's um that's my sort of open question or challenge for this work yeah I think that's fair and if I'm understanding right I think you're

saying there's there's a whole host of standardization Beyond just the last mile communication uh that the ethereum ecosystem and many would would benefit from uh yeah I don't I don't have a uh strong answer to that other than I think commit boost isn't focused on that specifically but I am committing myself to work full-time with Justin and as independent in a way as I can I mean ideally again sitting a bunch of people are supporting this through grants and can help Drive um Community overlap and Alignment around that I think our first initial take at this is is Zuber Lin and then probably something between Zuber Lin ECC and then ECC um to get some of this going I don't know if Justin has

more but that's that's kind of the best I got is to try to um you know understand what are the differences between what all the teams are taking at least identify those initially where is there overlap and Alignment in how we do this and then at least use that as a starting point and the more contentious Spots I'm sure will take a bit of time um and yeah I don't know Ben if it answers your question or Justin if you have more but yeah I don't think there's a perfect answer for that today and maybe Kuby can also share his his his intuition but like my model is that um what is very very difficult to change is the consensus clients and so for the for the time being we're just going to assume that the apis of the consensus clients are not going to

change and so the question becomes how what can we do with with with the signatures that we already have um and I think the idea here is to be like maximally unopinionated you whatever you can do should be expressable within commit boost uh now it is possible that in the future there will be some commitments that require changes to the consensus clients uh at which point we can either you know try and Lobby the consensus clients to do the changes or I don't know iess I guess that's a bridge to be crossed uh then um and I think one of the things that uh that commit boost is trying to to help with is this idea of containerization so I I think about

it a little bit like um um damn the word escapes me um Cy you can help me the the name of the module this Docker there you go thank you so it's a bit like Docker right uh it's Docker for for proposer commitments um and I think the idea is to try and shield you know accidental bugs where you know there's a one of the services just uses too much memory or too much dis or whatever it is um and maybe if we want to be like super paranoid uh we can also think about um a model where the the module is like actively adversarial right like the model wants to try and sign messages and access access the secrets from other

modules and and and may maybe uh Docker Docker containers can can help help there U but yeah my I think what we're trying to do here I mean I'm not trying to do this is this Drew and and QB's project um I think what they're trying to do is um to do as much as possible with the constraint of the consensus clients I will say it's not ku's project I've just suckered him into help so it's definitely kind of my mission of leaving and focusing on something in ethereum and trying to get community to rally um as a previous consensus client Dev uh you can uh change things at the consensus level but

um you need to fix the issues uh or ensure that the issues that happen following me boost don't happen anymore so if you want to read more you can read about um what POTUS mentioned uh regarding epbs and those kind of things um so yeah but uh with all the uh uh 2D kzg for EIP 7594 and those kind of things they are quite busy with very novel cryptography uh and now if you add risky protocol changes uh it indeed become uh quite ordal to convince uh uh and push

change deas you have your hand up hey yes yeah just quick question uh and apologies if I missed this because I came in a bit late I was wondering where like the code is living for these like efforts just especially because I hear like a you mentioned there being a de net coming up soon yeah I think next week we'll be ready with that we're just trying to get things going tested at least idealized um as I don't know when you joined but um you know it's there's no devs devoted to this um and initially what we had just or at least what I had gone through and done is tried to create a framework to start engaging with folks early on you there's a trade-off between engagement early and engagement late like if we came with fully baked code a

whole host of you know solutions that that isn't the intent of what we had so the trade-off we made is we just don't have that ready right now but Zuber Lin will have it I don't know if you're going to be there I don't know where you work hi there sorry but uh you know hopefully someone from your team's there and we're gonna have a whole hackathon go through it we'll have a presentation for about 30 minutes where we'll actually do the the demo of it and then you we're putting together repo and things like that um for people to go through so apologies is not ready today but it's just part of community and open development I think yeah just a few more days um we're going to have some uh you know devops and testing people at Zubin so for example paros uh devops lead and testing

lead uh will will be there and I believe Kuby and his team have and Lorenzo have been doing a bunch of of leg work behind the scenes and chain bound as well and maybe even other teams so I think the ideal outcome would be that we have a test net uh and we have multiple pre-confirmation systems that are built on top of commit boost uh and then we have these um you know nice projector screen with all sorts of Terminals and we take a nice picture and we we declare it a success and then a few weeks later at ECC we actually have a a a a long stand testnet um as as the next step okay cool I love the I love the

vision the terminal screens um just a following question is is there a reason not to like develop it out in the open from the start or like what's the reason against that I think that's what we're doing on this call um is you know we've got this framework and we're trying to get feedback and and thinking and Zuber Lin is where we're going to be developing open source and talking about it there'll be a lot of people there to all sit around we've devoted I think it's like 13 14 hours of zuin to talk about not only this but what everyone else is building around it um so I hope yeah that should answer the question but that's the way we've approached

it at least we're following Justin's timeline and and trying to work towards it I guess yeah and there there's gonna be a dedicated GitHub repo right yeah SL commit boost yep perfect so I don't know if your name's Daniel but I I will find you and I will as soon as it's ready send it to you directly apologize Alex you have your your hand up yeah hey um I think this is more of just a comment um but yeah I think this is super exciting um I'm still getting up to speed with a lot of the pre-confirmation stuff everyone's doing but what I'd really like to avoid is having you know tin Forks of me boost

where everyone has like their own little sort of idiosyncratic ways they're doing all of these and apis and interactions and you know all of that um so yeah I think commit boost is a way to move forward here where we can kind of have this common layer and yeah the obvious tension is making sure that commit boost doesn't privilege or Advantage like one set of people over another but as long as it does that seems really exciting so looking forward to seeing how this develops than Alex Connor yeah I guess maybe this is a general question but uh any intuition

why this hasn't been done before why there's been no Forks of M before oh there have been Forks like in use in use yeah so as a Relay operator you know we have visibility as to what the various um you know um staking operators are doing and there's many Forks of MEF boost playing all sorts of timing games doing all sorts of different things um and uh yeah it tends to be like the more sophisticated operators um and I guess part of this effort is to try and lower the barrier

to entry to be sophisticated uh to be able to to earn the full yield uh and try and and make the the playing field a little bit more fair also with this go ahead uh George I I I don't know if anyone else was speaking can go ahead I wanted to say something I just wanted to say that with the Rec and looking into Bas sequencing prec confirmation and proposal duties I think it has been more and more um noticeable of new use cases where MF boost uh extensions might make

sense whereas previously I'm not sure whether too many such as cases were plainly visible as uh I guess the group here and leaders in this group here has made it so obvious now Justin you mentioned that there are lots of people that have that are running different kinds of forks of me boost and are interacting with the relay I was wondering whether um there has been an effort in standardizing those changes because you have a different interaction between the

proposer M boosts that are running and the relay I guess that some of those changes are not timing changes uh timing differences but rather changes in the apis so uh something that uh we think that would accompany the commit boost initiative and trying to standardize what uh such a software would do for proposers is to uh standardize the interaction between the proposers and the relay basically the Builder API so we have a draft Pap on that uh which is related to commit Bulls because when you give commitments Etc you would need to communicate that with the PBS P pipeline

Etc so um I guess we'll we'll discuss more that next week uh in Zu Berlin uh and my question was uh have you seen such requirement for standardizing or updating the Builder API B based on those M boost Forks that you are seeing so I think the idea is that um we preserve the apis um to the consensus client but everything else can be changed so in particular the the communication with the relay could change if if that's what's required um

and I I think you know one one mental model that I have is like okay who sophisticated in the pipeline the relays are sophisticated the builders are sophisticated the gateways are sophisticated they can change you know from one week to another like the the apis Evolve the strategies evolve all the time um on the other hand like the consensus clients they're just super slow there there's all of there's five of them and they all need to change in unison and we have to go through the the allal devs process or a similar process um so that's what I see as very very difficult to change um but on in terms of apis with you know in terms of communications with the relay or with a

Gateway or a builder directly or whatever entity it is uh I think that's that's totally open uh in the design space uh kaido you have your hand up yeah uh just two question the first one is for everyone but very curious is there any uh these so-called met boo Fork uh that are maintained were mainly maintained by entity that's not Venture funding backed and uh the second one is since Havey Drew here do you have any plans in the future to make this a full profit business and think about Venture funding

and things like that yeah we didn't I I probably should have touched on this a bit more uh the the latter question I'll talk about first the former I think is for everyone but um yeah this is the the mission of this and goal is it to be a nonprofit I I don't want to call a foundation because I don't know if like that's the best legal entity but I think the best Motel I've got is like a client team and so ideally independent um the team itself fully focuses on this uh fulltime it becomes maybe part of the the core dev's like meetups like all these things um that they do I don't know all the intricacies of those things yet but that's sort of my mission and Envision that I've gotten to and this has been

through a couple Journeys to get to this point but think this is what's best for both ethereum and the most likely opportunity to get adoption and succeed and help um you know reduce the risks that we discussed um initially around fragmentation and all these forks and everything like that so um that's that's the idea and I'm open if the community supports it like I'd like to devote a couple years of my life to this and doing it um doesn't have to be me also you know uh but at least some effort around this and get getting it started I think is you know is an awesome awesome thing to do and then the former I don't know of any nonprofits uh I with that pleas but um certainly not to the whole flash Bots team in the community and their ability

to you know stand it up and you know support this with the resources they've had and really push ethereum forward so in terms of alternatives to meth boost um there is vouch which in some sense has reimplemented MF boost uh and they actually handle the logic slightly differently so I believe they do two get calls as opposed to one uh they do one at second zero and then one at second one and then they you know they take the the highest values something like that um there's also a blocks route that uh used to have a an open source uh you know modification to MEF boost where

they they play timing games for validators that uh pay uh blocks route for for that privilege I believe it's no longer open source um but it's basically a modification of of me boost um this time you know from from a relay uh but I'd say most of the modifications have come on the operator side of things there's maybe half a dozen uh or maybe 10 uh different sophisticated operators uh that that have made modifications to to me boot so there one of them for example um that's making a request every 200 millisecond or something like that so instead of calling get head once within

a slot they call it you know many many times um and one of the things they they observed is that uh the the IP address gets banned because they make too many Geth head requests and so they they have even more sophisticated infrastructure where they they split the IP addresses um and so yeah it can get really sophisticated and I think it would be good to add transparency to the whole thing add competition and uh and lower the barrier to entry to be sophisticated William you have your hand up uh yes uh great presentation guys thank you um given all of these Forks of me boost that we've seen um and just the

PBS road map broadly um how are you thinking about concerns with like one just getting validator parody for this over time if that is really a concern and then also things like byass ability and people forking you know their own strategic versions of this on top of what the plans are currently for commit boost yeah I um not sure I fully follow the question but let me add a bit and maybe let me know if I didn't answer it it all the way but yeah this isn't a fork of met boost commit boost is not

that it's a different way to think about that it's um you know PBS would be a module on top of this um the way I've I think you're you know I don't know if you're getting at like how do we um not have additional Forks of boost out there and and standardization towards it uh don't really have a strong answer around that specifically other than the ideas is you know if we unify as a community at least initially get all the proposed commitments to build to this standard so at least then no matter what there's the standard of how nearly all proposers will interface with proposer commitment protocols and um you if we have a crack Dev team sort of pumping out open source software that has top-notch features um

it will at least help reduce the barriers of there's a really sophisticated team that Forks commit boost and you know does their own running of it I think that's one of our um you defense mechanisms are thinking around that uh to help ensure that the open source version is used by all does that answer your question will sorry uh yeah definitely M me um so the FM Foundation sponsored uh last year a Pepsi boost for uh um protocol enforce proposal commitment and I was wondering if commit boost would

cover um uh the same um uh goals as Pepsi boost as well I think uh it somewhat does at least the initial expressions of what I understood Pepsi boost and efforts to be uh I think Pepsi boost is is also a lot more focused on um the enforcement mechanism like the the protocol being aware uh and and this is agnostic to how that is as as we discussed like we're we're agnostic to the enforcement mechanism so some nuances there but I don't think like Pepsi boost is a bad mental model of of somewhat what we're uh we're thinking through here I should note we're gonna apply go

ahead Koby but we're I'm gonna apply for like EF grants for this this thing um this entity this nonprofit so hopefully maybe get some additional research in in and thinking around Pep boost in addition to commit boost and trying things out there too so that that is in the thinking as well um at least initially yeah was just going to add that um Pepsi boost would be like a module that you could build on top of commit boost because again it would be like a subset of a type of commitment that you can make Stefan uh yeah hi um so I work on Teo one of the coo

clients and uh yeah first of all thanks for the presentation and I've been wondering well first for it's good to hear that we don't have to do uh anything for now uh and is the idea of commit boost to be a separate sidecar I mean listening to a different port and then then stakers need to install this software or M boost like the current software would be extended to support the new apis and everything what is the or it could be either I guess like what is the current idea maybe it could be so I don't butcher this I'll let you walk through

it yeah so like from a technical perspective um it will be a different side car and um I guess the way to in like think about it is like meth boost is a protocol of How To Source blocks like through like the current PBS supply chain and this the current meth boost client is the side car of how to talk to that protocol and what commit boost is trying to do is create one site card that could instantiate different ways of making commitments and so MEF boost conceptually the protocol could be implemented as a module on top of commit boost if that makes sense okay yeah yeah I get it thank you

tin now all right well I'm super excited to to see I feel like uh so much excitement around this middleware uh stack and finally some movement so um um I'm currently putting on my head of a um as a contributor to the PBS Foundation as flash is a pretty small party there and I massively failed my job in terms of like being on some of the committee so uh I feel like I wanted to kind of share some of the things that we mentioned um I think PBS Foundation um this is commit Bo is definitely an effort that PBS Foundation uh should I hope it can uh support on a funding um perspective this

is exactly the type of um upgrading and leveling up that um and standardization that we need in this space I love the clarity of the positioning of the med boost as a protocol and in fact I think the failure of the M boost protocol development as in community when the intention was set out uh after the merge to um um have Community co-creation has in fact uh staged but precisely because it wasn't we weren't none of us were thinking uh of it like a protocol we were oftentimes confused ourselves whether it's like core maintainers on the meos community call or like you know is Flash BR itself which one are we talking about the side car or uh or what so um so this is a really great I think

next step um I think one of the things that uh uh we had our first meet up um in Berlin last week uh I think some of them uh some of the folks who uh came by is also on this call I think one of the uh one of the direction we would love to see and I is um we would like to direct funding to comparing the trade-offs of the various um um um epbs designs um and we have identified a couple teams to uh granes to actually uh work on that and separately is comparing the different Forks um of B boost as well as a uh like clicking uh on the standardization effort and I think one idea mentioned was that uh like Stoke mentioned that maybe would be a good idea to kind of uh

keep me boo lean but um you know Upstream what is needed for uh uh what makes sense so I think that's something just ideas out here I don't want to put words into folks mouth many of them are literally on this call but I just wanted to share the ethos and I uh like I'm very excited to see what comes out of this next amazing thank you Tina for the support uh George oh I think you muted mine is comments rather than questions so if you want to close the public uh part I'm fine with that okay perfect let's do that that's

the end of the public part of the call next up we have the private part of the call uh which is more open discussion session and it will last up to half an hour