ePBS Breakout #12

Transcript

uh okay so welcome to this is uh the breakout call number what 11 or 12 12 uh there's nothing going on on the on the EIP so far but it's very likely that some changes are going to be coming uh and Franchesco is going to tell us about precisely that he has a different Vision to how to implement 7732 in a simpler way all right uh yeah can I screen share yes okay um one second okay uh do you see the Hakim D

thing yep okay so yeah um I kind of just go do like a high level overview like not go to in depth about things uh but yeah basically I guess the motivation for for this document um which okay I'll just link it in the chat later or maybe it's already be linked um yeah basically is that um well it's a variety of things I guess on the more epbs side of things uh is that I I just don't really like super much adding for Choice complexity um and I I I feel like this kind of design with the other boosts the like withholding and and the reveal boost um seemed

somewhat hard to to like uh um wrap my mind around and I guess for other people as well um and just feels like the kind of thing that you know later on makes it harder to um to think about new for Choice changes because you always have to think about uh how does it interact with the security of these things and proposer boost is already tricky as it is so I kind of wanted to try to think about something that is as simple as possible um not in implementation sense but in the sense of really like uh making sure that it works and you know being able to then later uh put things on top of it if we if we need to and things like that um so that's one motivation and then another motivation was kind of coming more from the fossil

like inclusion list uh research side um that basically was looking at recently at the the four Choice part of fossil um and uh there is basically if if you think about fossil without epbs uh there would be this uh a testing uh part that's that's where essentially the enforcement would happen of the inclusion list like the the whole thing is it's called away because it's like for Choice enforced um and so it would be enforced by attestations and this basically boils down to this uh kind of for Choice construction that we've talked about a bunch of times in the past which is maybe some people know it by the name of block slot attestations but it's basically the concept of being able to vote against something like an

attestation that does not vote for the current proposal actually actively voting against the current proposal and possibly making it easier for it to be fored out which is kind of already we have that today in the sense that if you don't get enough votes then you can be proposer boost reor but it's a bit different it's not like really the default uh behavior of the four Choice it's more like or well I mean it is in some sense but it's it's more of like a local decision of proposers to do this or not and it's easier to uh to go away from it if if it causes problems um but yeah basically like really putting this into the the um the normal or like in this like key part of the for choice

that determines whether or not uh even we have Beacon blocks uh in the first place seems uh just a bit more daunting and like maybe we we'll still do it but uh basically I was looking for okay can in the epbs thing where we have this in some ways nice separation of uh Bon blocks and payload maybe we can do the enforcement on the payload side uh since that's anyway the part that actually um you know deals with transactions um so that if something goes wrong uh you only maybe start missing payloads and not uh really also Beacon blocks so that's another part of it and then a final part of it is also that um yeah there's also kind of considerations around Das as

well uh like pias or or other forms of this uh that also have to to do with this concept of like um basically wanting to vote against a block like if if a block is unavailable um it might not be like attestations might kind of show that like people will not attest to it um if they've actually people have actually done sampling um and so based on the votes you might want to not extend that block uh for example if you're a proposer that does not have a full view availability like you don't download all of the data so you yourself might not know that it's unavailable uh so it's actually good for you to have this kind of signal coming from the for choice that says like don't uh you know don't build on top of this block because

it's dangerous like it's it might actually be unavailable this might be the reason why it didn't get enough votes so there's also this like enforcement aspect uh that's very similar to the dasas um and so yeah kind of similar consideration of fossil like it would be nice to just do this on the payload basically so the proposal roughly is for the uh slot structure to look like this um if you just look at to propose a test release and uh some kind of committee vote it's pretty similar to the epbs slot structure like with the PTC um basically of the current EIP um I guess some differences is like here because we then later need some other small phase

some things are a bit more compressed um but yeah I anyway just going through the flow of the slot like someone proposes a beon block um there's a stations just like today but at this point the payload still is is unknown um here it's still meant to be like there is a commitment to a specific payload um then basically in this time between 3 seconds and it doesn't have to be like an exact deadline this would be like the Builder can kind of choose when this is but basically at some point between three and seven um if a builder observes a certain amount of attestations uh it's going to release its payload if it does not then it doesn't um and so basically the Builder like Gets a Clue from

attestations um about what to do like whether to release or not um and in this case yeah you would have to um basically actually listen to attestation subnets like this would be like non-aggregated attestations at this point um and yeah I mean I guess one thing that's not here in this slot structure is there is still aggregation and like propagation of attestations like here for throughout the this rest of the slot from 3 to 12 or 3 to 9 or whatever it is um but yeah that's kind of overlay on this uh but the Builder would have to like actively listen to to nor to the the subnets and not just to the global topic and yeah basically the idea would be that it releases if it gets 40% of

attestations uh 40% comes from proposer boost uh basically if you see at least enough to beat proposer boost then you cannot be proposer boost reor like it kind of the block becomes safe from that um and this is all assuming like the chain will stable up until that point which I think is a fair assumption because a builder can take this into account into the way it bids it could just bid less if it thinks that the chain is is not safe to kind of uh bid on basically because there could be like reor I mean it's already forked or things like that so anyway yeah the Builder listens here to sitations if he sees 40% it determines that it's safe enough to uh to release it releases um then by this point just like in uh the PTC kind of proposal there is a

committee vote uh that's called PTC here it's called availability committee or AC uh and the reason to change the name is just that it's not just voting on the payload timeliness it's it's kind of has a few uh roles uh I mean effectively it's it's it's voting on the payload but like with u a couple more things that that he needs to think about and and like things that we care about coming from this um and then yeah basically the the next thing uh that's yeah and I guess at some point here um it wouldn't yeah so iils are sent at some point it doesn't actually have to be after the payload we could also do this in such a way that you don't need to wait for the uh the previous payload um this is more of a decision to to be made within the kind

of fossil research that's not super important here um but yeah and then at the end there's this basically freeze deadline where basically what happens is that um people stop listening for new or like they they do listen for news but they basically the ones that come later than this deadline they don't really take them into account they don't enforce them essentially uh they don't put constraints coming from these ILS on the next block uh and then this freeze deadline also applies to these AC like availability committee votes so you know I don't know here there's going to be 500 people voting uh 3 seconds later you've seen most votes if some vote comes late you uh also will not kind

of take this into account in in in the way that you then use the votes which I will talk about um and so yeah basically now maybe let's let me just go through the the various kind of actors that are in this uh Pipeline and like what they do with this in these various phases so the Builder I kind of already talked about um b i here like B is always going to be the beacon block and P is always going to be the payload um assuming there's like just a beon block and a payload um but yeah basically the Builder like um the first thing it does is as soon as it sees the beacon block um so this could be like any time here essentially uh it already propagates

blobs so this is without waiting for any attestation it just does it this is kind of assuming I guess this already apparently relays do without uh um you know even waiting to like validate the the block or something you can kind of already propagate blobs uh because you don't really care about blobs they're not they don't have like sensitive information I guess at least normally um so yeah you propagate blobs immediately so there there's more time for that um and then basically you only well I guess okay I guess this part now on the in the light of this discussions around G blobs and and the effects of that maybe we would have to rethink but I don't know this was here basically to say like uh in principle if needed you can propagate

the blobs earlier uh so that it's basically the timelines are not it's not just this amount of time to propagate blobs like in in the if you really need it you could take more time um and then yeah once you do see for 40% attestations you release the payload because you think that it's not going to get reor at this point um and you don't release it otherwise now the one thing one thing that's quite important that so there's this 40% number which is um again proposal boost like if you see more than that all good like it's not going to get reor Reed um it's uh like there's no way for uh the proposer boosted the next proposer to be

to to to do something to it uh but the other the flip side of that is like what if you don't see 40% so in the case where you don't release like if you go down this path uh because you've seen I don't know 35% or something then basically what you want as a builder is that the payment is not going to go through like if you don't release then you don't want to pay um and so the idea there is basically to have this payment rule um yeah there's no diagram here so you can well yeah I'm just going to say it I guess uh yeah the payment rule is basically that uh you need 60% of the of attestations from the committee um for the payment to be processed and this basically is just going to happen on so

I guess there's two cases like one case is everything works fine the payload actually becomes canonical then the payment just goes through there's everyone is happy there's no problem and there's no need to wait for attestations then the other case where this does not happen where um for example the uh this Bon Block B um becomes uh canonical but the Builder is not released so we're kind of down this path uh because it did not see enough attestations then still the payment will be kind of held up um C is that some like more specific uh design of having like a Quee of these bids um in in state and uh or or like keeping like a cash basically in in state of these bids and basically uh accumulating attestation weight uh over time as as a ation come

um in in the in the successive beon blocks and then once it gets to 60% it gets processed one caveat is like we would actually not want to process it if um we would actually want to wait to be sure that there isn't an equivocation for reasons that I'm not going to discuss um that like here you can see there's this no equivocation kind of C yet uh but anyway like basically the point is like we're going to wait to process things for some time basically like an epoc could be like a good uh rule just wait wait until the the end of the next EPO or something like that in the Bad Case um so when the payment does not happen immediately because everything is fine we wait until the end of the next EPO and we only process is if we don't have

equivocations and we have at least 60% of attestations um and like basically the reason is like um if you did not see 40% of attestations the block should not get to 60% unless there's like 20% that's late or malicious or uh something like that um which is basically like a decent safety margin that we've been kind of we've sort of been okay in these designs to to give the Builder like even the other um DC design like the the way the for Choice worked did not really protect the Builder up to a stronger adversary than 20% so that's that's where 60% come from is just 40 plus 20 um so that's the Builder and then yeah

you can prove that given these assumptions and these numbers then kind of everything work works fine up until uh certain adversary uh and yeah but I guess I should flag like this payment thing is something to kind of think about uh carefully like how the how this would be implemented and yeah see a hand up go ahead yeah um so a lot of the complexity of this or like I don't know a piece of complexity in this design even if it's simpler uh was that in state q to keep track of attestations to know whether or not there was enough attestations I guess um it one thing that actually now strikes me as strange is that like we we already have this concept of

inclusion uh distance I guess and like if there aren't I I guess it's weird even if we wait to the end of the epoch in order to even if attestations can be counted up for the next two epochs it's weird that we would choose whether like make payment conditional up to two epochs because the Builder made a decision during that slot when those attestations may very well not have been available I I right but so the the issue is like we cannot know whether those U so let's say that we decided okay let's just make the decision immediately let's not wait um the issue is for example the

next proposer might just be or let's say the proposer of slot n and Slot n plus one might be the same proposer and it might just decide not to include um or actually no this is more of a case well okay let's say let's say that the proposer of slot n plus1 wants to screw the proposer of slot n then it might just not include attestations for the payment not to be processed like collude with the builder or or just I don't know out of like malice just decide not to include attestations in order for the payment not to be processed and like from the chains perspective you can't really know whether or not this happened versus attestations were late um so that's kind of the issue um it's like if if we don't wait some time it could always be that the attestations did not

get onchain just because people decide didn't decide to include them so the the extra distance is really just about increasing or like making it less probable that someone would have so many blocks in a row more or less yeah basically something like that I mean any it wouldn't necessarily have to be the next EP book but it also feels to me like there's very little um like there you know this extra delay um doesn't really do anything too bad like neither to the proposer I mean the the person that might end up being delayed is the proposer but like I don't see what's the difference between getting payment in apple versus apple plus one and like from the protocols perspective keeping

track of you know 30 uh like uh 30 payments that still need to be processed versus like three payments doesn't feel like it's that different but um yeah put yeah so I want to make a comment on regarding this my first impression when I when I read this uh this proposal was that we were shifting complications complexities but but actually in fact we need to delay anyways and and and I I think we might need to delay even in the happy case uh because there's this this attack scenario in which the Builder since the Builder is a validator that someone is getting slashed it has a lot of money and they want to transfer to

someone that is not slashed and if we allow this large transfer of effective balance quickly then I can just hold two validators get slash for a lot of St on one of them and transfer all of my money to somewhere else so that is no longer slash so I think anyways on 7732 we need to implement such a cash cash uh uh so I I I feel that even in the happy case we're going to have to delay the payment uh and and have this cash on state I mean I guess one question is does the Builder need to be a validated or like couldn't this balance just be um I mean maybe that's simplest in some way but then if if then we actually have

have to deal with this kind of edge cases of slashing and so on then maybe it's easier to just have Builders be some other that's an that's an extra level of complexity like if we have like we thought about this like having new validators that are not really validators they don't have any duties uh and they just are uh Builders without any duties and then this leads to a lot of gaslighting over WEA because now these these people have to be heavily staked and they don't get any money out of their stake because they're not earning anything and then you need just like have two kinds of Builders ones that are validators and others that are not validators so that you allow them to earn any any interest rates on on their

state capital uh it just goes on forever so the simplest option is always to have them as validators and I spoke to builders and they I mean the main Builders don't mind and and and if we are going to implement this cash anyways uh then it's it's no change to to do this in the happy case as well so it's just the same when two EPO later you just process all all payments and all all bits that you have in this cash it's just a quick it's a quick processing right um I mean I guess one question that comes to mind uh is like is TW if

we're thinking about this like slashing escaping things like that is too enough because uh I mean today I guess we have like uh uh a 24-hour period or or something like that um for for withdrawing where like slashing evidence can go on chain um but like I guess we really wouldn't want to have a 24-hour queue um right well anyway I mean yeah but I think it's fine right so if you if tox

should be fine because we can always uh we can always add this condition that after toook if the Builder was slashed I mean if the slashing happened would happen immediately so if if when you're processing this the Builder was slashed then you just don't process it and you keep it yeah I guess it's more in case um Builder gets a slash but you only find out much later like I don't know if I mean I guess this this is more the really bad case of I don't know there's a separate private torque or or something like that that only gets revealed later with like double finality or like this kind I mean I guess the

really worst case thinking why we have in the first place this 24hour uh withdrawal delay uh but anyway I don't think it's makes sense right now to to hung up on this too much um but yeah anyway I guess it's something to think about um okay so that yeah so I think this payment processing is definitely generally something that you know it should be written down um like a proper respect for it and like edge cases should be thought about and implementation complexity and so on um but at least like I try to like motivate why I think it would be good to to do it this way um and yeah uh so yeah so that's basically it for the Builder for the

proposer uh basically everything up to here is the same as today like you want to extend the head of the chain uh you so here B is like the thing from the slot before uh so if it's not the head of the chain you don't care you just extend the head of the chain if it is the head of the chain then uh you basically might still propose your Boost reorg it if it's less than 20% attestations um so again up to here like nothing different than today um then what's different is that you now basically require the payload to have uh at least 50% of this availability committee votes um so it's basically like this 50% will kind of enforce the various things that uh available committee is voting on um and

like it's partially for you like if you're a builder or sorry if you're a proposer that's um that does not download uh all uh like columns like all blobs um then this like listening to these votes and this majority vote is kind of a signal for you it's basically an availability signal that tells you okay like this actually should be available so it's it's sort of safe to extend it so partially it's just for your own protection potentially as a as a proposer that's not uh subscribed to to to all column subnets um and another part of it is like because you basically don't want to um like if this block was late or if it was um not respect in the uh inclusion

list uh conditions which would be determined by this like availability votes um then you would basically not want to extend it because people will not uh want to vote for it like ATT testers will also take a look at these availability votes uh so that that's basically the thing that's added like you require a majority of availability votes in order to actually extend uh something but it's only the block from before like if you're at slot n plus one uh you care about the availability votes from slot n Only uh once you go past that slot like for example if slot n there was nothing and uh the head of the chain is from slot n minus one then you don't care at all about these like payload votes uh you only care about the regular for choice so you basically

would just run things just like you do today uh so basically it's it's like I guess one thing one way to think about is that this availability votes they're kind of transitory like they only last for one slot and then things get solidified by the for Choice um yeah pus yeah I wanted to ask about this U so let me see if I understand why the the the need to freeze the the you set up for a testers that will need to freeze their view on AC votes at 10 seconds or whatever time before the slots ends there's a freezing time and it's kind of clear for me for for the El perspective but it wasn't I perspective but it wasn't so clear from the da perspective

but I assume that it's something similar if the proposer uh wants to hasn't seen the data available and uh will not build on top of the payload Because he believes he hasn't received enough votes from uh from the AC committee uh then he'll reveal uh he'll reveal his payload uh he revealed his blog based on mty and this freezing before is to protect that situation that uh the votes from the from the AC committee the AC might have not come in time yeah so it's it's yeah it's basically all exactly this um or or I

mean I guess the more General um making sure that whatever the proposer sees about the AC votes like the proposer is just making a majority determination like was their majority in thec votes or not the testers are making the same exact determination um this other is again just a majority determination I haven't talked about it but that's what it's going to be and so we want them to fall on the same side like both of them have to see greater than 50% or less than 50% so let's make like a a simple example let's say that the U I'm the proposer here and I see uh 49% votes um or or like I see basically maybe I some votes are missing but I see like 49% for the votes that that I that I have um and so I decide not to build

on this payload but then let's say there was no freezing more votes come in or the votes were there but I just haven't seen them because I I'm a bit of the edge of the network or something um and so they keep coming at a tester see them um and now they see 51% or like 55 or or whatever they see more than majority uh and so that's bad because then a testers are going to say like why didn't you extend the payload you were supposed to and flip case like can can be like the opposite that you extend something but then uh more votes come in and now it looks like it's not a majority because this would be like a a relative threshold so if more votes come in the the you know decision can also it can also go down like it can start being 55

but then becoming less than that um so yeah basically either one of these two cases where in in some way the proposer and ATT testers end up being on the wrong side on on different sides of the majority decision whereas by doing this freezing we can basically ensure that whatever the proposer uh decides the testers are also going to decide um and like basically the way that it's going to work is just that the proposer includes the 500 or whatever votes in in its block just like it also includes at stations but it's specifically going to Al also include these AC votes and testers will basically um take into account all of the votes that they seen by this deadline like I mean they they'll just

keep listening to votes but then put a time stamp or something like that and they only care about the votes that they've seen before 10 um and then they will also consider all of the votes that they've seen in the beacon block H and so that that basically makes things work like in a way where basically all of the votes that a tester see the proposer will also see um and once you put in the votes from the beacon block everyone has kind of the same view so it's like this like vaguely like view merge thing that I've kind of like talked about some other times but in like a slightly simpler fashion because it's literally just about this few under boats here um yeah teren and or poers no no it's fine I'll I'll ask you l so I think there's

one another reason that probably didn't mention is that there's also this equivocation case right so as a validator at the AC say if I send uh like because there's no slashing condition right so if I send an ac1 ac2 to a tester into the proposer then proposer include ac2 but then the attester sees ac1 then this also allows Pro proposer to have the final say right so in that case the attest of the next slot will will basically have to respect proposes AC that is in the block yeah exactly so like yeah this is basically what's uh here like the kind of we have very simple rules that like um you only ever propagate the first AC

vote that you see for someone basically the same rule that we have for like every gossip thing um but then when you receive the beacon block there's going to be more votes that the proposer has put there and you might see some equivocations and then if you see an equivocation you just go with whatever the proposer said so like you know you see uh vote one and vote two both from the same person vote one you got it from Gossip vote two you see it in the beacon block that you receive you just throw away vote one and just go with vote two like basically just you know if there is an equivocation you just give the benefit of the doubt and just take whatever the the proposer saw um so yeah that's also part of this like uh kind of merging views mechanism

um yeah and I mean yeah basically this kind of section it's just all about arguing that this leads to both the proposer and testers seeing the same thing um and and then making the same decision about majority or not um okay so that's uh that and I guess uh maybe let's go to a testers quickly um so yeah basically a tester is like this is going to be this like merge part so what you do is like you run the for Choice uh kind of normally but then if you need to make a decision about the payload so you might might be that you don't have to in which case this everything else here

kind of just after the first one just goes out of the window like if for example the head of the chain is from slot n minus one like it's in the past there's no payload decision to be made you don't care about the AC votes whatever if you do happen to need to make a decision about the payload because there was a beacon block from the slot before and it is the head of the chain uh by running the for choice in a normal way then you now care about the AC votes so now you kind of at the the final you know you need to make this one last decision about empty or not in your for choice and now this is what the only thing that AC votes do basically and so now you do merg your view of AC votes which is this thing that I was

saying like take all the AC votes in the beon block and kind of uh always agree with the proposer like whenever there is a conflict like two equivocations just always go with whatever the proposer says and if the proposer says something that you didn't see like a new vote that you didn't have Just Go With It also add that vote um so you do this process you end up with some set of AC votes that you consider uh now you do like a majority uh you know you just see like is a majority of the votes saying yes or or no um if they don't say yes like a majority then you enforce that P is not extended which means like if the proposer extended it you vote against them like you will vote for b instead of P um and so this can lead to like for

example a um um well anyway like yeah basically like this this is trying to make it so that uh the the proposer Choice uh ends up ends up not working out um and yeah and then basically you as as usual in I guess pios or whatever when it's going to be you do a da Check so you by yourself even though there is some kind of Dack that's already hidden uh here because the the voters are also voting on on da um is as I said before this vote on da is more for the proposer itself it this is more like of a hint for the proposer uh you don't just trust the The Da determination of the of the AC votes you just do your own dhx so

like you just download The Columns and and if some columns are missing you don't care about what the AC says you just still vote no so you your your personal DH needs to be satisfied and not just this dck um and then the final thing is that uh there is some kind of an uh inclusion list uh check that's made also here by by the AC voters but you then it kind of gets solidified here and I'm going to if we do have time I'm going to talk about that as well so anyway yeah so you do this da check this IL check and now you again make this determination of like okay do I enforce that P is not extended meaning do I vote against P if the proposer has extended p uh or do I uh just I'm I'm I do I enforce that it is extended meaning like

if the proposer has extended P then I'm okay with that and vote for it uh and if the proposer does not extend P I vote for some like I I'll just vote for p basically and so against what the proposer said uh yes so when you say that enforce P not extended that means the attestation is voting on the Block but without the payload um yes I don't know how to do this without changing the attestation format so are you including the block hash in the attestation now or something else no it's V for the current block it's not voting on the on the Block that is coming attestations are only on blocks so the new proposer just proposed n plus one and ATT testers will vote on

N oh I see I see um but I guess doesn't the I mean even just in in the current T isn't there a way to still vote on um like be with the payload or without the payload or like how do you as an tester so so so that's the thing so I believe that this proposal doesn't really make the implementation of for Choice easier it just makes the theoretical part of it but the Implement most of the complication of for implementation is remains there because you still need to deal with empty versus full blocks that's the largest part of the problem and you still need to uh force reor of situations like this like the the the

block is coming the testers don't want to have this block and they want to reorg it and uh in this particular case it's easy because you're going to go with your parent and the parent uh is is going to be empty for anyone so yeah so I think the implementation details of this of this statement like how to reorder the incoming payload that is bad is exactly the same in both uh in both eips so here the for Choice store will also track all the AC votes right just similar to how we track the PTC votes today yeah so the difference is that in

current right so it's only one slot it's the same as for us we we we sort of like are stupid in keeping it on every Noe but but we only need on one because anyways the we also are doing the same thing the Franchesco suggesting which is that the proposer can only include votes PTC votes from the previous block um but um but the the biggest difference here is that we we only use PTC votes to determine a boost and Francesco is using PTC votes in the merge in merging The View so I think the biggest philosophical difference here is that is the way that we enforce the safety of the Builder in 7732 the safety of the Builder is given

by this uh the situation where the Builder for example sends a message that says I am withholding because I think this block is weak and we use this message we are using the the message to not to avoid payment but to force the beon chain to reor the pay the block and this mechanism here is a different mechanism in saying I don't need to send a message that I'm withholding I'm just literally withholding and I'm not going to be charged for it and I don't care if the beacon block becomes canonical or not so so that's what makes a for Choice much simpler and that's what the beauty of thiso it's uh it's also like you don't need to give for Choice weight to

this actions that the builder takes which is the part that I'm really like somewhat uncomfortable with because it's I mean both just feels wrong kind of conceptually that like Builder gets for Choice weight but also just to me at least it's quite hard to like think about so yeah it really for me I think what you said is right it's not it's not so much about um making the implementation simpler it's it's about uh making it kind of theoretically simpler or like not not just simply because again as I said I do feel like giving foress way to builders is um just really feels like the wrong thing to do um but yeah so for me it's really more about that not a simplification in in that sense of like um thinking about for

Choice security and and and things like that is like kind of I mean I guess partially is that goal and then also just like trying to like um as part of that also like harmonize everything with these other things like fossil and D but I think yeah that you would probably do as well with the with the current uh PTC approach um I would agree that the current spec is difficult to reason about in terms of for choice and that even if it was difficult for implementation that I don't know it's still valuable to have a

conception you can reason about easier yeah I think I mean the nice thing here in that sense that I mean now you know it might I don't know if like anyone's going to leave this uh call thinking oh this is so simple but probably because I I went through like a bunch of stuff relatively quickly but really in some sense it's just here like this is everything that I mean this and the payment mechanism like there's not much else going on um so it's just this like majority vote um and then this mechanism of you know if you see 40% you reveal and um 60% is the payment threshold so that basically tells you everything about the um kind of yeah basically what's going on with uh the

behavior of um Builders and like why we they they get safety and other than that they don't really influence the the for Choice much um so yeah it's it's in a lot of ways like more similar even to the current for Choice yes yes so the other tradeoff that that is a real tradeoff over 7732 is the timelines I mean the fact that we're we're freezing um we we we have stricter timelines uh gets me a little bit on e um because we were already sort of like a at the edge of what we could handle so it'd be nice to know know if we can actually do this prising at 10

seconds for example uh perhaps it's fine if we do it at 11 uh but then that squeezes the IL satisfaction for the Builder so it I mean there's always a stress hoold the the problem that I see is where you put this 10 seconds number uh between nine and 12 it could be essentially anything and and and there's these two different forces that are containing there right so I guess I should also say uh one other way to do this that does not have this um is that you would say have two different thresholds one threshold here for the proposer would be uh 25 and then for testers would still be 50 um here and so that kind of then

you don't really need um this merge thing um I mean you would you would I guess for the IL but not for this uh availability committee thing uh because basically you would just say if the proposer sees um a kind of a similar argument as the 40 and 60 like if the proposer sees um less than 25 then it's it shouldn't get to 50 and if the proposer Sees at least 25 then it's fine um so it would be more like yeah 25 would be for being allowed to do something and 50 would be for enforcing it as opposed to being like the same 50 for both um I mean in principle I feel like it would be nicer to have 50 because

it's like that's um like for example it would mean that you know having this 25 and 50 thing would mean that if you have uh 20 plus something uh a testers you could make something look available to the next proposer which I mean is not the end of the world um but yeah if we can avoid having these like weaker assumptions it's nice but I guess it's not if we really need to uh not compress the timelines then we could just do that um yeah I guess what else oh yeah I guess let me just quickly say what the AC is doing um yeah it's not doing anything super complicated it's just

saying is p do I see a payload so just like the PTC here I mean it says matching headlocked like you specifically would have locked on the first beacon block that you saw um if there is an equivocation like this is just to deal with the equivocation case yeah and uh then you vote on like you kind of do the da Check like you you'll be doing sampling at this point already like downloading columns and stuff so here you already vote on The Columns and again this is just for the benefit of the next proposer in case it's like a basically it's like if the next proposer is not someone that downloads all columns and uh here it's not just if they're a local block Builder like this could be a proposer uses me boost as

well um but this is about you know the the fourth choice and this deci deciding which beacon block to to build on and or or sorry if to extend the payload or not so even if you're using M boost you're still the one that's in charge of deciding what to build on uh so you still kind of need this hint if you're if you're not someone that's downloading all columns so this is the only reason why this this check exists um and then yeah this is this like I kind of thing um here I don't want to go too in depth about what's going on here but I guess the only thing to say is like this does not require execution the payload at this point um there's like a small little thing that's that um you're voting on that's basically just like a

um like an inclusion check like a small inclusion check that does not even require you to look at the transactions it just require you to look at um some small additional information that's going to come with the payload um and yeah that that's basically that so you at this point so to just to recap like we are at this point here in the slot you just got the payload and you have to vote um it still preserves this property from the PTC that you don't need to quickly execute the payload so in principle payload execution could take like up to here or or whatever in the in the worst case and this would not influence the availability committee votes um and yeah and that that's that you just vote on the I satisfaction um and that's it and then

um in the next slot um ATT testers will vote on another kind of I satisfaction where now they actually need to look at the transactions and execute things but they'll kind of use this um yeah basically it's kind of like a twep thing where like the AC is enforcing is doing some some kind of check and the and the the next check Builds on top of that and actually looks at the transactions but I think it doesn't make sense to to now go into that um but I think it's fairly simple um yeah I don't think there's anything else I here it's some whatever for Choice thing but I don't I think it's different from the current EAP uh yeah so I guess I don't know I think that's that for me um I don't know

if there's more questions thanks a lot Franchesco this is this was great Terrence has questions yeah thanks Francesco this is great so I guess I question maybe to like you and everyone else is just like we have been working on death net for the last few months right and sounds like this is a better approach it sounds like this is something that we might want to move forward so I guess I what's the plan right now right it's like like basically I presume there will be spat changes if we go this rout and yeah just curious for your thoughts can I can I check that one but later uh I

wonder I mean sort of like instead of like trying to make decisions now are there more questions for Francesco and on this presentation let's let's have clear what are the tradeoffs before if there are no questions for Franchesco then then we can discuss this how to move forward but I have a concrete proposal um which is the following um I I I wouldn't I wouldn't want like a group of 10 14 people here making decisions of like the direction of thep I personally prefer uh this approach uh much more than what we have today I feel much more at EAS with the without the boosts uh I

think it's it's a good idea and and what personally convinced me is that this biggest trade-off was the implementation detail of enforcing the payments and I am convinced that we need to enforce them anyways because having Builders not not as validators is worse uh and I think we need to have this this this gash anyways so I think it's it's a good idea to move forward to this but let's decide this later in terms of practical changes there aren't that many actually uh the spec if you forget about ILS and and the and P D because that's that's a that's actually a big change but um from

7732 to this kind of for Choice what changes is the structure of the PTC attestation because it's no longer has this uh this withholding message the the payload envelope also doesn't changes a little bit because it doesn't have this withholding message anymore it can just not be there the PTC attestation will eventually have more data like the ilil availability and the da availability uh but but for 7732 without p and without ILS nothing changes there um the timelin so the the the validator guides the honest Builder guides all of those Behavior gu do change quite a bit uh but

those are like always optional and four Choice does change but it's I think it changes for the better and it's not that much of a change because anyways you need to do this filtering for empty and full so my proposal would be that we I personally would continue writing the current defet for prism as with is with sort of like an empty for choice because what we want to prove with the defet or with interrupt is that we can handle separation of the payload and we can handle the slot time we we want to prove that we can handle 12 second slots with the PBS that's the biggest unnown and that's fine with any kind of for choice so it doesn't matter and uh once we have that I proposed that we open a PR to

change the the spec repel to this proposal by Francesco uh only 7732 and then have the people that are working on IL and P last to rebase on top of that if it if it's just 77 if it just 7732 do we still want the freeze deadline in 10 second because that's another change you didn't mention right it the freeze deadline is some it's only important after I and Pras without Pras any validator is just uh the proposer knows about da already at the proposal time yeah so if there's no objection and that this

goes specifically to Francesco I would like to write the spec C the CL spec PR uh changing from 7732 to this because I think I have it fresh you will also add the beacon State changes as well right that is to track the 60% of the yeah yeah so that cache I more or less have an idea on how to implement yeah I mean I guess as far as I'm concerned I just want to say that I've not been uh Super Active in in the whole PBS development um effort in the last few months um I kind of gone back

into it with this almost by accident like while doing something else and so I I don't want to really like I don't know I'm kind of okay with whatever people that have actually been working on it um feel like it's the is the right way to to move forward so I think it's a small it's it's a smallish PR because U as I said I think it doesn't really change as much it doesn't really change much from the current of limitation so I don't think it's even going to derail the the definite efforts that we have but I I think it's probably better if we just like sleep on this and next call or during the next days we signal this on on Discord and as I said I since

I already knew about this project for a while and I've been like thinking about this uh I do feel like I've made a a decis a position at least that this is better than what we currently have for [Music] 7732 um to be clear do you have in mind also to Target this and to have something where for for Devcon already in this change with this change no no no so actually I I won't even write a CL PR until I finish the implementation of the prism inter the the current okay yeah so I'll do the current one but sort of like

with an empty for choice because it's kind of irrelevant for choice for what we want to prove see this this this the the main difference in Francesco's proposal is on the payment mechanism that becomes harder and un for choice and uh the payment mechanism we already have it implemented in in prism the current one and for choice we don't really need to implement much detail because we only care about like in the happy case we can handle uh blocks being PR payloads being present we can handle the separation we can attest to them in 12 seconds I think this is the purpose of having an interrupt and I I I really think that I want to have this before that g so that's that's still my priority yeah yeah I I agree

so now that we're talking about implementations I could share what's the current state uh in Te so we are we have started working on on WE Stefan uh has started working on uh Fork choice and um we think so if we are kind of confident that we could have something for for for Devcon essentially maybe next week maybe the other week maybe more so Stefan is confident for next week but he might requires some

help this means that probably having something more confidently working would be for the next week as so seems like uh we could even try pris tech but it won't work asking this yes so uh for choice is kind of irrelevant because it's not really measurable on a on a definite anyways uh so what I would want is the separation of the payload and the and the Bon block no no propagation of

bits even though we have that implemented if if anyone has it implemented is fine but no need to subscribe to to beid propagation on the P2P uh uh Network even self building not even contacting a builder so no Builder spec so what we want is epbs with self building and of course being able to handle empty uh empty blocks because that's the new thing I don't understand how you say no Fork choice though I don't well you you can you can use the current for Choice uh you can do

something minimal that doesn't have slot that doesn't enforce uh Builder safety for example Builder safety is where we differ in Francesco's approach and our current approach so we could have a Dev net working that proves that we can handle 12C slots without assuring the Builder that he's not going to uh that that his that the payload that the block is going to be reared if he withholds and that that I think is fine for me okay if if we have a a a death net that

splits on four choice but that everything is working it's just that we we are split because we consider some blocks heavier than others that's absolutely fine that's much better than I mean honestly what I would expect is that we have any defet by defon we're going to be broken in like a Genesis so if we are broken only on for Choice I'm I'm very happy so there's there's still a PTC commit I don't know I I guess I yeah yeah PTC has to be there the PTC vote is there like handling all of the network the networking part of that requires that epbs requires besides the bids should be there the PTC attestations have to be there

I kind of sorry t uh over recent times like I I got busy with some um Electra devet for stuff so I hasn't had much time to continue to dive into Fork choice so I don't know it's just I don't know if I'll be able to um parse out exactly what needs to be implemented that's all and time for Decon um about the BTC I guess one thing is the votes for the BTC can just be completely ignored like people vote but then you don't actually use them in the

first choice so in that sense correct that doesn't correct have to do anything so you just I guess if you see a payload you just take it and if you don't you don't without caring about the votes yeah so in the current 7732 the PTC vote is only used to construct the Boost so you can just not implement the Boost and that's fine you can just keep for Choice as it is the only problem is that you still need to implement for Choice with empty and full blocks you need to keep track of these nodes that are going to come like based on a if if a payload is missing you need to be able to handle that situation in your chain that you may have some blocks

that came without a payload and that are still canonical so this will have to have a for Choice implementation in whatever client you're writing and that's the part that you cannot avoid all right guys we're over time it's true um it was a great meeting thanks a lot Francesco and I think we can really move forward with this and I'm I'm I'm very bullish on this um I'm I'm I'm I'm very happy that it also seems to be making ILS easier so dusting is separation of payload and beon block no for choice

because irrelevant self-building no Builder correct no one need to subscribe to propagation uh of of the bid I assume and yes epbs with itself yes correct that was always the idea for EP except that we wanted to have full for choice but I guess now it's kind of irrelevant okay good good to understand I just want to kind of um kind of get it fairly focused in the limited time remaining um so yeah given what te said I'm gonna have to spend some long nights in the next few days but yeah right right thanks guys right thank you

thank you very much everyone bye bye bye