ePBS Breakout Room

Transcript

everyone hello hello okay uh let me grab the

agenda we're all here for a breakout session on epbs thank you everyone for joining um yeah I mean I think at a high level we generally want to just kind of think on the STW PBS for people who haven't been following but uh would like to start and then from there kind of discuss the state of the research there's like a couple different implementation efforts R&D efforts that been ongoing um so it' be good just to kind of touch base on those and yeah just kind of see where things are and then you know I think what would be really nice is by the end of the call to kind of have a shared understanding of are we ready to move into concrete

implementations uh if not how can we get there so okay maybe I'll give people one more minute because people are still streaming in but then we'll kick things off okay the people have stop streaming into the room so I was thinking to get started I would just take even just like five minutes and kind of

like explain what PBS is and like why we want to try it and where all that leads um I think I'll just probably pretty briefly follow these notes I left it I left in this comment here this one I just dropped in the chat so you know what is PBS well proposer Builder separation and the idea is that you know validators when they go to propos blocks they somehow are producing block space and then you have these other actors called Builders who want to buy it from them and so PBS at least one way to think thing about it is that you have this auction uh to facilitate this exchange that being said um well I mean yeah there's a lot of

context here but ultimately there's a current design that we leverage uh that kind of shipped around the merge with my Boost this is something probably all of you have heard of and there's like an additional actor in The the Boost picture which is sort of an offchain PBS called the relay and the relay basically is there to like paper over um some trust issues that we'll definitely get into in this call between the proposer and the Builder so one way to think about it is that the relay is kind of like maintaining this auction or like you know brokering it in some sense uh the Builder says hey you know I want to buy um box bace from the proposer sort of with this payload the really needs to

make sure the payload is valid and then also when the proposer goes to like uh sort of solo box bace that the payment actually goes through so there's a few things that they do um however there are these like single points of failure um and then yeah what I called out here in these notes uh targets for implementation of censorship so this is a big concern that we've had with how the relays are structured um many of them are choosing to sensor um and again that's kind of a whole different conversation but what it means is that uh we sort of have this core ethereum value that's being harmed by by this protocol actor uh so this is something we'd hope to get rid of um there's also a question of funding the

relays and again this is a whole another different sort of side quest but ultimately um it's not clear that the relay system is that sustainable in the long term and so if we could get rid of them all the better so we have these relays but really want to get rid of them and this is the idea now to like enshrine them somehow into the protocol um at like a high level you could think of like rather than have Builders and proposers go through this relay actor you could imagine they use like uh peer-to-peer layer some gossip infrastructure to coordinate uh the protocol itself could enforce payment and you know this idea sounds nice um there's at this point been many work uh sorry there's been much work

over many years to kind of make you know make a concrete specification as to like how this would actually work um you still have to do all these different types of things around like you know is the payload valid is the payload available uh if I go to like pay the proposer like is the is the payment valid and you have all these questions that come up so they start answering them uh there's like a series of designs uh yeah just to start with the first one you know is this payload validated on time right so like when the Builder goes to release the payload uh you want to know that you know the thing they release again is is valid otherwise they could grieve proposers um you also to know that it's timely otherwise they

kind of miss their opportunity to get into the chain and that's not great either so this takes us to what I would probably call the State ofth art uh around this idea of PTC PTC is a payload timeliness committee and basically it's adding this extra protocol actor um or rather I'll say it's adding an additional duty to testers to attest to this payload release in epbs does someone have a link handy to PTC design spec any documentation if you do could you drop it in the chat but I think we'll be talking more about this soon uh that being said I think there's some issues with PTC at least I see um I

think a big one is essentially coming down to like Builder safety so the way that this works is that now there's like the you know proof of stake Fork Choice involved with these commities and there's different things validators could do around sort of splitting the view of the fork choice for each node uh to grief Builders and that's not great the reason it's not great is if Builders don't use this thing then like what's the point there's all this complexity in the protocol and that's just not good um but again I think we'll get into some of the details there in a bit um another one essentially like if we do move from today's world with my Boost where honestly there's like these very optimized uh point-to-point networks so

more conventional like for example HTP apis if we to more of like a you know peer-to-peer gossip style there's probably just going to be higher latency than we see today this is a problem because uh you know all these M systems are like incredibly latency sensitive it comes down to like you know even shaving off like milliseconds or or more is uh you know profitable for someone so people are investing to do so and if we present them A system that is sort of you know less precise on a lat latency basis then that's just not going to work at least that's what I think um there's other questions around payments so basically when a builder goes to actually make one of these

blocks in PPS you have uh essentially yeah the builder needs to pay the proposer and the concern there is like how do they actually do this um one option is basically when I go to pay the proposer I kind of do it just in time uh and when we think about this with like what we have today this kind of means that have to attach a transaction at the very top of the block which is fine um but it does kind of mean the Builder has to have that Capital up front uh which again could be problematic for some types of me that we see otherwise you can imagine they have this uh you know some collateral locked somewhere to be contained probably um and then from

there they sort of pay out of that with each block so either way uh maybe I'm getting a bit into the weeds here but ultimately the the point here is just to point out that there's a huge design space and we are here today to discuss yeah Danny yeah when I've been a part of like smaller large group versions of trying to align on epbs before um it's really some of these questions and other things that like it's not even clear what the right optimization path is and I think that's why we often get stuck um so either now or maybe after the call later in the call it's just like what are the features like what are the features we need here right and like you know

something that certain things come up and it's like actually unclear what the feature is to the extent we need it for example like quote Builder safety you know one what is Builder safety meaning like once they've done something the the chances their action makes it on chain um you know and and can they be griefed or can they price it in or you know there's all sorts of these things um where it's not I don't know often these conversations get to the point where like there's a lot of fundamental disagreement around these core features so at some point um you know maybe maybe post call we kind of see where we're all at maybe it's worth kind of trying to like specify those a bit more clearly for example it's like do all does everyone need to

use this you know or does this need to be as good as relays or does this need to be like within some Delta as good as relays and and what is that what is that Delta you know it's anyway right I mean I would not even just some of these questions it's like what are we even attempting to do is becomes hard in these conversations sure yeah definitely um maybe to kick us off there then like I would say that we want something that everyone's using like to me it seems not great to add all this complexity to the protocol if ultimately it's just this like rubber stamp and we don't actually solve any of these like quote offchain

ches I do well I even question that like it's not even clear to me like actually if it's if it's the the um the protocols the relay of Last Resort maybe that then provides a healthy market and sustainability and stuff on top of it because ultimately people only going to use a relay at that point if uh if it's additionally profitable and at that point then realiz potentially charge and all of a sudden maybe you have like a valuable Market where it's like if you don't the protocol is not a real Last Resort then maybe the market Dynamic is totally different so like I I even question that um but I'll leave it there I know there's a lot of things to get to yeah so maybe before we just jump

into the Weeds does anyone have any questions like I'm not sure how much we want to like you know kind of quote cover the basics versus um we could just get into things okay I'll assume that everything I said makes sense and we're all on the same page at least with respect to the design space um yeah so I mean maybe I'll take suggestions from here I was kind of thinking so I know that uh pus is here and he's been

doing a lot of work uh on sort of flavor of PTC one option would be to pus I don't know if you want to say something about what you've been working I think Terence has been also working on that although I don't see him oh there he is yeah so uh I don't know if you guys would like to say something about what you've been working on or maybe even just like start with like you know yeah sort of like along Danny's lines like what design principles are you thinking about and how are you approaching the problem all right so yeah I I agree with Danny uh I think it's we first need to agree on what is epbs versus what is PBS and what's the purpose of it and what are the

constraints that we want in the problem and I was Guided by some design choices and some dichotomies that I posted on NE research a while ago uh which led me to think that of this notion that uh builders the ATT testers for the payload should not have any for Choice weight this in itself left gave rise to this attack which you mentioned at the beginning which is this balancing attack uh you mentioned three points that you sort of like see as weak of this design I can describe the design in detail in a bit uh I'll add one extra

point which I think is very weak on the design which is so you mentioned the three of them balancing attack then the second one is about like P2P goip style and the nonadherence of of Builders If instead of like opening an HTTP point right and the third one is the way that payments are going to be handled if it's just on time on the execution layer or if it's state and they need to have the balance on front I'll add one extra more which I think is the most impactful actually for the protocol which is protocol complexity including changing the slot time which I think is something that is a just immediately a Non-Stop harder if we change the slot duration uh so I think that's uh that's another from an engineering standpoint

or like a social standpoint yeah so complexity at at the level of the of engineering is in general is a problem and within complexity the highest uh would be changing the slot time okay and when we say slot time we mean like this whole round of whatever is happening like the nego so the whole round is currently at 12 seconds I think we can keep it uh but the Des sign that I have open as a PR has it at 16 seconds just with the desire of keeping the attestation deadline at four but we can actually make it three but let's not get into these technical things thank right now uh what I would want is to argue against two and three I think those are just no no non complaints these are just

not not an issue uh and I would want to mention what is this balancing attack which is a problem that this four choice we don't have a solution for this and what I would like is that after a few of these meetings we either agree that this is a problem that we need to think and solve or we just agree that well we should shove this and try to think from scratch on a different B my point of view here is that there is one attack to this which is Builder safety and this this balancing attack and we need to find a solution to this and I would hope that we can just sit down and think of think of way of solving that problem uh so I don't know how you want me to go Alex I can just describe what is the way

that PTC is what how is that we're implementing it what how is that we're specifying I could describe what the four Choice changes are and what is this balancing attack in detail uh or I can argue against two and three of your complaints yeah um and to be clear I'm not trying I'm not trying to like uh you know block anything it was more just to kick off the conversation um but yeah so I think I think whatever you think makes sense like probably what would be helpful is like maybe you could touch on the high Lev features um like again for example you know we've brought up this issues of this issue of Builders being staked or not like how does that come in

um the okay I'll describe what is what is the the feature so what is the the weakness that this would generate for Builders this is a property that Builders have today a builder if it reveals a block if it reveals a payload and on time honest validators see this payload on time then that block is canonical it's automatically canonical and this is a feature that it seems that epbs in the flavor that we have it now uh would be lost this is the reason why we all of these the signs for epvs go in two rounds of voting a proposer Gathers the header just as we

do now with me boost for whatever means it can be on the PTP Network it can be just directly requesting from the Builder or an HTTP endpoint you just get ah header and you submit your consensus block with a commitment to include a payload from a builder ATT testers attest to this block or not if they've seen it on time they attest if they haven't seen it on time they attest for the parent block just as we do now some pointing to the the slot the Builder that has been counting attestations if the Builder sees this block on time with a commitment to his payload and it sees that say like 100% of the commit committee has voted for

this payload then he will reveal his payload broadcast is payload fulfilling the promise if the Builder sees zero attestations for the block and or doesn't even see the block then the Builder will not reveal the payload and just because doesn't need to fulfill now there's another committee that just ATT test for the presence of the payLo so right after the full round of voting happened ATT testers for the next block or the for Choice Runners for the next block T yes they do a test for the validity uh there's another discussion on that M says that that they don't need to but I think it's impossible to do

that without breaking sync the point is that right after the end of the slot validators have gathered votes for both rounds and they know what it what their head is and with respect to the current slot there are three possible options no block was included so no consensus block and no payload was included this is just like a Miss slot today the full block was included namely the block appeared and the payload was revealed fulfilling the promise that's just like a present block today and there's a new entity that should be considered important Choice which is a empty consensus block I will call those empty blocks instead of skipped this is where the consensus block has been has

appeared it was voted it is the canonical head but the payload was not on time or was not there so now the problem happens where there are two forms of grieving the Builder some new figures that appears which is the following which is the block is revealed by the proposer with a commitment to a payload but the proposer either times it on purpose or happens by chance since it slightly late and a percentage of the committee sees the block on time and a certain percentage of the committee does not see it on time in this situation the Builder that has been Gathering these attestations

doesn't really know what to do and it that it's lost the assurances that he had before epbs the problem start as follows if the proposed if the Builder sees a sees a weak block but not so weak and weak here for the current values of proposal boost means if he sees more than 30% and be below 70% of the committee has voted for the block under this circumstances the next proposer can choose to build the block based on the parent block or build the block based on the current block that is being proposed and the next proposer because of proposer boost would

actually make it both ways can't he can reorder the blog uh if it's not highly voted and he can build on top of the the block uh if if he had enough votes those numbers are thir 30 and 70 if I don't get if I didn't get them wrong so the problem here is that if the Builder decided not to not to submit this blog because he saw only 35% of the committee voting and then he says no I'm not going to reveal the information that I have I'm not going to uh reveal my my payload then the next proposer can grieve him by building his block on top of the consensus block and then the Builder because of the of what

epbs is designed for would be forced to pay the bid even though his payload was not included the opposite also happens if the Builder uh decides to reveal his block and the block did not get enough vote so for example less than 70% then the next proposer would be able to reorg it and uh if the next proposer is able to reor then uh he can't really do this unbundling attack which is reuse the transactions on the same slot because typically Searchers would protect themselves the transactions would be executed in a different slot but he can use the information that that the

Builder revealed so this is the what I consider is the problem of this design uh I can argue against the other ones uh besides slot time that I think we can fix but this problem needs to be fixed and I would want to like talk possible solutions eventually probably not today gotcha yeah thanks that was a really great walk through um yeah so like zooming out this is ultimately this like notion of Builder safety we keep circling around and I guess yeah that is this is a conversation worth having is like to what extent you know do we think these issues are relevant do we care um I

think I saw you trying to get some uh input from more networking specialists in our community um did that go anywhere um because this would be something here is like to what extent like how easy is it actually to like split views like we're talking about so this is this is a view split that a proposer at slot in induces or is attacked by because the proposer at slot in can probably pretty accurate uh it's one they induce like they're trying to split the yeah you have to assume that it's feasible like you have

to assume that the adversary uh is directly appeared to everyone and has de anonymize them and is hand delivering payloads um in the practicalities it might be quote hard but I think an adversary who's willing to like do the leg work can split views and the protocol has to be designed in such a way that you assume it whether you assume it and they do it and and maybe the outcome isn't that bad that's one thing but you have to assume they can do it protest yeah so one here is that it's not only that they need to split the view but they need to split the view along prescribed splittings namely if you fix proposal boost then you need to

know exactly the percentage of what is the next committee that's going to see it and I think this can be gained we could so I just posted something on RNG so that it's just the first idea the thing is that this is a problem that we might be able to solve one idea would be to not not have a deterministic proposer boost that is not it's only known after the Builder has revealed his payload or not and then in that way the proposer of SL end cannot gain the split the view the splitting because he doesn't really know what is the percentage that you needs to be split but is it a random distribution because it's a random distribution then they can model it right no well so so even if you do it

like a random which the Builder might influence it because he would know it before anyone else and he could just choose to reveal or not because of knowing this uh even if you model it as long as you have like enough of an error bar this this attack does not become possible do does not become um well it it depends on it depends on the value of these and whether they're doing a repeated game if they can model it and there's an error bar then if they play it you know 100 times and there's certain there's certain Delta on it then it can be profit profitable in in the single game then it's probably too risky but I I I do worry about these random distributions and whether that they

actually protect us in like a repeated game right but even even then you cannot you may not make it random by say like the the the distribution is going to be modeled by a hash on the extra data of Builder and that is not it's not random the Builder is just going to adjust and this one way of allowing the Builder to actually set proposer boost and without really giving it four Choice weight because the Builder cannot choose between two different Forks he can only like help or not boost the next proposer if he's being honest building on top of his own head can you explain that how does the

Builder choose how much they give the next one yes so let's say so there's two issues here one is that proposal boost on epbs probably needs to be gone or lowered a lot because we model proposal boost based on exanti rears and post anti reor without block slot voting but on epbs block slot v voting is sort of like a must because uh you need to be able to penalize the the proposer not uh posting the block so once uh so that's one comment and another comment is this thing that comes with other for the for Choice Rule now it's like the proposal boost is there for a reason it's like to prevent certain long-term attacks on the

fog Choice rule so we would like then like improve those attacks yes that's correct so we need to so the thing is I reading the chat also Francesco saying boxlot voting voting certainly has a problem unfortun becomes actually much more complicated than we are discussing here there are some issues like uh if a vote for slot and uh how do you propagate it along the chain that is supporting that block and slot in and there's some subtleties there we can look at what I'm proposing later uh one of the issues for example is if you voted for a block and the proposer of a child does this block can

be basing his block on top of like full or empty these are two different things do we count any vote for slot n along the chain or not uh and so the strategies Chang for Choice quite a bit and the whole thing of proposal boots needs to be studied for reorgs under this new voting system but besides all of this even if we manage to like model all of the proposal boosts what I'm saying is that the Builder has one option uh besides just giving the ATT testers of this committee uh for Choice wage which is something we didn't want to do that's why BTC what we can do is the Builder adjust proposer boost by essentially just saying this is how much proposal

boost would be was Will going to be is going to be among this prescribed values One Way hash of extra that or whatever it is I mean like as a builder proposal boost is always a risk for me right so I want to always set it as low as possible uh that's that and that might be the case uh and that might that might be fine so like I would just as a builder I would just grind that extra data to have as low proposal boost as possible always that's I don't see how that adds anything well but then you might just like we might as well forget about that thing and simply say proposal boost is always the minimum yeah so with block

slot actually proposal boost uh at zero you need 50% to build on top to do a postan reorder that's at zero and exanti reor which is the one that uh I don't remember actually the numbers for with block thought for exanti reor probably here hasn't fresh but even at zero so even zero proposal boost doesn't completely solve all problem because you can also uh use the tests to ROK like I can uh balance and we don't know like this would be one thing that would be interesting research to do on how difficult it is right now to balance committees to within 5% 1% and so on because my intuition is that it's

actually not difficult my intuition that balancing to within 1% is not hard if you like try hard enough like if you collect enough statistics know exactly where you're going to release those blocks I think you can potentially balance committies to within 1% so if you can do that then so this is on the network right so so you're saying that you can you can decide up to 1% of error when you release your block what's the voting going to be and I'd be I'd be happy if we actually get these measurements down uh whenever I talk to researchers they tell me yes this is possible this is easy and whenever I talk to people that work on P2P they tell me it's impossible it's not Tri a research I

mean it's it's a big research project because like you actually have to invest the time at like trying this it's probably like because like there might there there are many different methods to try to balance this right is it enough to Simply release your block in the traditional way at the boundary and out the best boundary probably not you probably need like to have like at least hundreds of notes no like get some statistics on which nodes I've H many validators and so on but then is it possible I mean I like I'm just saying I would not be surprised I I think that this pretty interesting research project and I think that you start with the assumption that you know the validators on each node because that is certainly doable um with

the way that PDP works today and then you run simulations from there and strategies from there I can see if I can find somebody that wants to do this yeah I mean this is not going to be an easy research project this is going to be at least months not of work and yeah yeah yeah I don't this isn't a like weekend project well maybe for somebody but the I mean if you're very lucky it might be a weekend project because you find a very easy way but most like most likely it's a longer term research project then we don't we don't know I mean ideally you want to assume the worst case right that it's fairly possible to get this within relatively tight

bounds yeah I mean it is it is the default assumption that uh kind of in tral Academia that you take that you can deliver these types of messages with these timing constraints um you know we're certainly deviating from like the assumed adversary in traditional literature if we say no we don't think so um but that is definitely the like traditional assume adversary on the P2P and you can easily imagine why it is even if it's hard and hard I think becomes a dollar amount not a and and I think hard becomes a dollar amount

like on the order of something not to the level of ethereum's cryptoeconomic security you know validator set size that's but uh I I'll put out some feelers and see if anybody wants to take it on so so I have a proposal which is I mean I'm certainly not denying that this attack exist there and I think this is the biggest problem of this design U My Hope Is that we can actually solve it that we can think of ways of solving this problem but uh perhaps let's agree that there's this problem there we can or not discuss whether or not this problem is a theorem we cannot solve this problem and then we just trash everything or we can try to move forward and try to solve it eventually we can argue about the other points um but it's clear that there's an

issue here and my hope is that we can actually fix it instead of like trashing the whole project I think nobody is suggesting trashing the whole project I think we all want to find better designs that have as few of these problems as possible we could yeah I think the point here is yeah go on go ahead Danny yeah but I think allying on like what is the threshold of agreement on these different things that it becomes it becomes like we can move forward and I do think there's some disagreement across

here if we say that we solved this Builder safety problem like we could kind of start there and then say do we do we want to do epbs given we have Builder saf safety like a builder like let's say we have the same Builder safety as meev boost today then I guess that could kind of be a way to transition into the next part of the discussion which is more about protocol complexity slot times I think some of the I guess the second round of issues that that Poes was talking about earlier which is um yeah slot time mainly I guess is there a reason why we are not at all talking about vitalic design

where both the proposer and the Builder get a boost can you explain that and then um I think there's probably some rebuttal well to me it's uh it's been a long time since I looked at these things but um it feels like it's very similar to the um PTC except it's like basically in both cases you have two blocks with two um comet um but like in vitalic design it was much more symmetrical and we basically just had a comme for both of them and um both the Builder and the proposer get a boost and in particular the Builder boost

um stops the Builder from getting reared because the Builder can basically if um they in within a certain uh range they can decide whether to release or not like if they see say between 30 and 100% of the votes they can use their own boost to like uh get over 50% and get guaranteed that all ATT testers like all honest ATT testers are voting for that block um and therefore it's solidified and can't be reor by the next block anymore and I think like the main problem we had was that people said well now we have because like proposers can select themselves as Builders so

effective you get the proposer boost twice um my intuition is that this just means you should have the proposer boost but I don't know like if that's exactly correct but um and clearly that that does weaken the fork Choice rule but like I mean also in this case we also have to like decrease the proposer boost to reduce the risk for the Builder so I'm not sure if it's that bad or at least I I feel like it's still better than the PT design so one thing about this design is that in order to actually for proposer boost the Builder proposer boost to be effective you really need I think a full committee to be attested to to the

Builder part so that it kind of solidifies whatever the Builder proposer boost has uh kind of nudged people towards and so it really becomes more of a two slot thing rather than like this you still trying to keep you one start by having the the PTC committee being small and non agregation so I guess that's one thing um that it it does kind of increase the uh complexity and and the the cost just by uh increasing SL time the effective slot time essentially and then but yeah but the other thing that uh why I mean you already kind of said it but yeah the issue of having this double boost is that basically in the current consensus protocol um the security arguments against long-term balancing attack and like this kind of

um yeah I mean essentially all this we is to try to prevent livess um basically rely on there being a certain percentage of honest proposers and yeah essentially it's if we give boost to builders um we you can basically count half of the uh actors as being dishonest essentially potentially like I think that's the right thing to do to just treat every Builder as being malicious um and yeah it it just makes the that kind of attack much worse um now now I don't know if there is simple ways to to mitigate this it didn't seem clear to me that that that's um that that can be done um but

yeah just if you literally just do this two slot thing and do not change anything about how things work just give proposer boost to builders for sure it makes all these attacks much worse right because you're saying even for honest proposers like the attacker would simply out bit the highest bidding Builder to also get propos for those slots yeah exactly yeah like basically I guess I guess the the the worst case is like let's say that there is a dominant Builder that doesn't even need to spend money because they they're winning blocks already and they happen to be malicious and want to just create chaos um then yeah it's basically becomes equivalent to just half of the slots being being given to malicious

proposers right I see oos you had your hand raised yeah so but I was to say the same thing as Franchesco uh I would add as a constraint uh so we have Builder safety as a design constraint for the system another one I think it should be keeping slot time because it's really hard close to impossible to change this on the engineer level and I think that it's but this is just a belief I think that keeping slot time is impossible if you have two rounds that need to be aggregated so if you if you are going to add a second voting that needs to be

aggregated I think it's impossible with just keeping this lot time that way so that fores has to have a small committee for the second time having said so I'm not against boosting the second committee if it's even possible being small it can we can play like the theory we can do some simulations to see if there are numbers that are reasonable originally one of the reasons we didn't want to have boost the small committee or give any for choice choice for Choice weight for Builders is because we thought this would be a very constrained set of players that we didn't want them to be choosing between ports so this goes to one of the things that danr said which is proposers can't select

themselves as builders in the design that I'm that I was working on Builders would be sted and payment would be carried on on the side and I can Define that because of just code complexity it's much simpler to deal with stake builders on protocol and just pay immediately on the CL uh as you process the header even of blog and uh in this design well the proposers can't select builders okay uh so we have about 20 minutes left

I don't know if we want to dig into any of the other points um it seems like this is it seems like we at least agree this is one of the biggest Walkers to the current PTC uh design so certainly something to dig into deeper Something Mike mentioned is worth surfacing just like self-building as that you know being a um a requisite feature of uh epvs or not um being another component of the trade-off another and and like I guess the nuance and often the rebuttal with it's not a PR Rex assumes then another feature uh inclusion list right so still being able to maintain influence on the Block without being able to build it um

often is that optimization yeah by the way we we Ser like the reason this rpr became too large is that we wanted to have like State Builders so that self-building is not is not possible then that first inclusion list on us then since this Builders would be stay that Force Max EV on us and Max itself requires 7,02 on us so most of the pr it's those three big changes yeah yeah I I see the dependency P well and so that kind of suggest maybe Way Forward is over the next like fork

or two you know we ship these PR Rex and then that gives us time to dig into this sper safety issue and then uh you know there's a path ultimately let's save that discussion for the El meeting sure yeah just servicing it I to mention actually one one sorry one second um is this call only until uh you know are there 15 minutes or does it go past hour I think it's scheduled for the hour okay okay great um it sounds like the possibly be more of this okay sorry

you're saying oh yeah so so my I want to comment on your second point which is this issue of like not using the system by like not using P2P gos Set uh I think this is a a no-brainer like uh we will never be in a situation where the P2P Network bits are going to be useful in any form this can always be bypassed and that that I think is absolutely fine this is not a requisite of epbs and I don't think this I don't I don't I don't even see that this is a problem I think of epbs as a way of enshrining the relay not enshrining the Builder uh and I think it's absolutely fine if we are in a in a place where the P2P gossip uh layer it's only there as a back as

something that we will fall back if an a livess situation where the Standard Builders are not live uh typically what would happen what I Envision that this would happen is that Builders now will not even need to do the b& they can just become relays immediately and they just open an an endpoint they just open an HTTP endpoint which they cannot do today because they are not trusted but after epvs they can just open the themo and we can just continue getting the headers exactly as we do today with me boost directly from the Builder I don't see any problems uh if this is the situation Builders become Rel layers um they are just trustless relays they're part of the protocol if Builders are not State enough and they

need to go to a separate uh I mean to to have some sort of me business with relays that are going to be the ones take and signing the blogs for them that's fine as well this is just something that is happening between the Builder and the relay but the Rel now becomes trustless which is the objective that I think is the main objective of of epvs yeah I I definitely like the mental model of in like Stak Builders is more like enshrining relays in shrining Builders I think that's that makes total sense to me I guess the issue I have with the trustless relay uh framing is that we don't know that um the full bid value will capture the payment like to a

validator so for example if if a validator is like listening both to the kind of the bid that's signed by the Builder and it's collateralized with whatever like automatic payment mechanism is there um the Builder could also tell them that like we'll give you extra payments outside of the protocol in this way and like they'll just take that higher bid if it's if it's bigger than the the trustless one so I like I think if the if the builders used the protocol as designed then it would be trustless but we have no way to enforce the builders to use the protocol as designed so that's my main issue with uh with the trustless framing I don't understand what how is it that Builders are not going to use

the protocol as the sign like for example um let's say I'm a builder and I just sign the like I sign a bid to the proposer through the protocol mechanism that's like 0.01 eth and then I tell them that I'll pay them like 0.99 eth out of the protocol and they just have to like trust me bro on on that portion of the payment like if I'm a validator and I hear you know that that they're going to give me a one e bid fully I can just trust them in in that regard and like bypass the the protocol there and like the reason that this might be well I guess it it just means that the protocol isn't being used like then

I guess it doesn't feel like it just like if we're trying to get rid of um trust between the Builder and the proposer it doesn't actually get rid of that trust that's the issue it does you're just you're deciding to trust more that's GNA happen on any protocol it doesn't matter what protocol it is I mean I can pay you to for you to not propose a block too and just keep your block and I can do this soft chain what's the problem with this well yeah I guess it just doesn't make it a trustless relay right like it's still trusted yeah I see it as like providing a baseline trustless mechanism and then the market can layer on top rather than having a zero mechanism that then we have an unsustainable Market layering on

top which is absolutely fine yeah I I mean you could argue You could argue we have that today right like um the today you have to trust someone you you really have to trust someone you can not have for you it's a matter of what that Delta is right now that Delta is huge between using yeah your the local men pool and The Trusted market and I see it as does me does epbs provide a significant Baseline such that Delta is is much smaller such that then it becomes like a kind of a uh Choice rather than right now I guess it would be interesting to see like for

example like right now if we assume we can only trust epbs up to one East blocks like right now what percentage of me comes to from greater than one E blocks right do we know that I feel like the distribution is extremely skew and people have told me before that a lot of the me comes from very high me blocks um so then it does less yeah and um I don't know what exactly that is how bad it is to um put like say like as something like a one e separator in there um but that would be like an interesting thing that would tell us something about how

valuable it really is and so maybe just to respond to pus a second ago like this is I think my point is if we add all this complexity to the protocol to like have this sort of real of Last Resort but it's used very infrequently like was it worth it and I think it's an open question but that's kind of I think really a key consideration here I don't understand why why would it be used not frequently

if it's used constantly now this from the point of view of the validator the ux doesn't change you just request a header directly from the person that would send you the block the the payload from the point of view of the Builder it becomes much better it doesn't need to trust the relay anymore he just opens his own HTTP endpoint from the point of view of like the Builder that doesn't have the money to St it becomes exactly the same as it is today he just trust another entity that would send the blocks for them so I see why is this not an immediately knowbrainer that it's going to be better in any situation I mean for example a builder might say like not a builder but like the two or three builders that actually

matter um they might just say like no like this is too risky for me I prefer the current situation so if you want to get blocked for me just keep doing it the way you're doing before the Imp protocal bit is going to be zero and you just have to that's that's Absol fine too we can open our own our own builder I mean there's zero builders that want to be part of this the Prismatic team would be very happy of running their our own builder this a lucrative Market but like I mean that's assuming the validators are going to care about these extra guarantees which like is not necessarily the case um I mean you know are like there's not that much of a cost today in in just trusting uh that a relay is actually going to give you

their block well but the point is that you're not going to be able to do so because you're not going to be able to get a block of you're not going to be able to even sign a block of say a builder can just be St and be part of the protocol but just not the BS are going to be zero but they are staked and they are allowed to be a builder or a relay or whatever you want to call it it's just that they don't communicate their actual bids through the protocol um so you're still using my Boost trusting a relay ET ETA but um the Bild they don't need to communicate the bill they don't even need to propagate the bids they only need to open their own HTTP endpoint as they do today and the proposer can request it exactly as

they do today and I don't see any problem with this as long as a builder some inal object impal entity signs the payload instead of someone that didn't produce the payload sign set I think it's fine but the the signature Z yeah like the Builder can just sign a bid that doesn't bid anything and the actual bid is off chain object and just because they don't they don't want to trust this mechanism to protect them and they prefer the the existing mechanism I'm not saying this would be the case but like it's literally up to like two or three Builders whether or not this is actually used oh I I think this is so this is fine so you're saying if the proposers decide to take blocks from builders that don't offer them any

security and they have to be trusted proposers may decide to trust someone what I don't like is that proposer now are forced to trust someone if they want someone else to build their blocks they're not they don't have the option they either build locally or they're forced to trust someone what this mechanism going to change is they either build locally or they may trust someone and actually would force them not to build locally but but that's a different discussion I do agree that there's like a moderately profound difference in those two things I'm not saying the design necessarily provides that but like the difference between those two things is is important and it's important because of that assumption it's also

important because like it then makes the market more potentially competitive and valuable like it makes entering the market you don't need trust you can use like the facility yes there's a difference between trust you don't yes you do you do need no you need trust you need to trust relay yeah but I mean I guess if if you're a little Builder and you don't have enough to put up the collateral like to be a Stak builder then you'd have to trust the the Builder relay anyway right but I don't think the long tale of Little Builders are realize is becoming vertically integrated and the difference between the two is going to is probably going to a road so you're trusting Builders at

that point in what seems like a convergence yeah I mean I think I I think I still agree with Franchesco which is that like there's three builders that are kind of relevant here and if those three Builders decide to sign zero bid and like have this like this kind of reverts to the exact same thing today where I as a local validator have to either trust one of those three Builders or build locally like you know there is this long tale of builders that like could do better than my local block but it's just like not that different compared to the value that the like three big Builders are going to provide me you know what I mean so like the cost of Alm might not and also we should not neglect what

clients do the reason we are we we have this adoption today of me boost is because we support it in our own clients this is not something that we may be forced to do and someone that wants to do some offchain work is going to have to for clients well but they can already just use me boost like that already exists the offchain software already exists that's the point yeah and someone is going to have to keep those forms I do think over indexing on the fact that there are three or who those three are today and designing the protocol around them it helps in Trine them it

helps reduce the competitive in the market helps reduce like potential changes over time by just assuming oh well we have these actors we can't do anything about it um it might not change anything immediately and they might not use the facilities but it does open the the fact that the market can become more competitive or or at least shift right but it will cost which is like kind of my point it's like if we do like we double the slot time we have these new committees we do all this stuff and then what I'm hearing is we do all this to like maybe allow this like like median segment of the market uh to you know to exist I mean I think like the the real argument here is that you need to have a

low cost of Entry so that when collusion occurs a competitor can enter like let's say they suddenly started colluding now but everyone has said only these three Builders as their relays well now you're because now you have a really high cost of entry for entry for someone new so they will control the prices and someone new can't really get in so you need like to leave this door open so that when they start colluding someone can well I mean maybe before I wasn't competitive but now that they all agree to only pay 0.01 e per block maximum now I can be competitive and I can enter can enter the market oh but you can always do this because of the b2p the PTP Network would always give a baseline of

what is the Min I'm so so I'm talking your like for an EPB I'm not I'm not arguing against you I'm just saying that this already is there yeah right right no I agree I agree this would be the argument like the danger with the relay design is that the open relays will go away which ensure like Easy Market entry um because they like aren't competitive and uh and then like the builders control the market so I think that's the danger with the relay design and that's something that even a very imperfect um EPS design could ameliorate okay I'll just note we have a

few minutes left for this call today yeah next up well I think it sounds like there many next epis so we'll probably want another breakout um a big thing was if we could figure out or if we could like gain a clear understanding of you know these Fork Choice details and like how how big of an issue this vo safety thing really is and like at least for me I think the takea away from this call is like balancing all these different concerns because like we were just you know painting this picture where even sort of a suboptimal quote epbs could actually

do a lot of good if we're worried about relay disappearing and what that implies um so even if there's not like a you know let's say perfect Builder safety uh it might still be worth the complexity so yeah I think that will ultimately be the deciding factor in this whole thing is finding the balance there I'd love if somebody wanted to take on trying to write down the design criteria okay um because then you know I think we all have this like thing in our head and we all beginning to kind of hone in on what the design criteria but but yeah I I think just somebody attempting it like Po yes you'll be very biased you'll have you have your own

design criteria but it's going to begin to then then someone can say no but what about these two things what about the and we can like have a more princip like is to what are the things that we are set and we at least agree it seems that we all agreed on what the definition of Builder safety is and we want that as a designed condition and I think we also agreed I'm not sure but I suspect that we also agree that we want to keep the slot time uh I will I wonder what are the other designs that we might already have agreed upon from today's meeting I take that those two are are are requirement I think that the second one requires you to have a small committee for the second vote and for Builder safety I think we

need to explore and solve that problem but I think we can solve that Ando yeah just a question about the the slope time so you you're mentioning that could be pretty complex to move to change the lot time uh and you said from a technical perspective not only from social perspective so what what are your arguments there for for the slot timing to be kind so the problem with slot slot time goes down everywhere like it affects tooling it breaks existing things it might break even contracts it there there's well contracts is very hardly that they're going to be broken

but the thing is that there's a lot of of things that are down Downstream that depend on the on the slot so I mean outside you mean outside our outside the the consensus yes outside of consensus even so we have we already have uh contracts that check on time stamp and that sort of like assume they they have this thing which is time stamp to slot uh which is currently a dictionary and we're going to be breaking that it's it's a very tough change to change the slot time but on the other hand on the bright side I think epbs brings us something that is great which is the fact that we can go down so the the node currently does the critical validation all at the same time on epbs you

pipeline it much better you have it you can you can attest at three seconds because your block is much smaller and it's much faster to to verify and you can verify the payload at the time where the node the consensus layer node is doing nothing so from the point point of view of engineering and pipelining epbs is much better for our CPU is much better usage of our CPU than it is today so I think it's doable to do 12 seconds by shortening the attestation time which by the way also like shortening the attestation time gives less margin for that balancing attack

okay we are at time and people I think are streaming out um yeah so it sounds like like the media next up is just having like a clear design doc we all agree to and I think we can coordinate around that asynchronously does that sound good to everyone okay got some thumbs up um great okay thanks everyone for coming and I'll see you around the internet thank you see you by thank you by bye bye thank you bye