ePBS Breakout #17

Transcript

all right so let's make it quick because everyone is I'm sure on fire with the with the hesy stuff so we need to decide on what actually goes into this spec uh because there are some things that are going to break our current definite so we are now stably finalizing uh Prison still doesn't have H proofs for for blobs but that's independent of epbs so it's not going to be an issue and PTC attestation is working fine with the current design so it's it's it's not an issue uh so I I think that the devet is stable enough without the features that we have that uh we could in PR principle

um add the missing features like the builders API and these kind of things before changing the spec but I think since decisions on fusaka are going to be made soon it's better to just uh change the spec arrange the things that are going to be minor and then let's arrange what is the next devet with the changes that we want so unless someone opposes this I want to go over the list of things uh that I want to add on the Cs spe all right so terus already graciously went through their calls and found all the instances of things that we wanted to change one of them is the slot to the payal envelope this is all

already in place and this is already in the in the defet uh and that's fine removing the payload withheld from the payload attestations is something uh that we've already done to uh I'm sorry from the payal envelope not the pation uh and now we need to decide on what to do with the payload attestation itself because if we go to a for Choice as Francesco suggested which uh uses proposal boost and the and the Builder counting attestations before submitting if we go with something like that then the payload attestation is uh

it's useless for the payload envelope to have this withheld message and then the payload ad station it's usess to have that status so if we go with this for chice which is something that we kind of committed already by uh removing the payload withheld from the from the pay envelope then the PTC attestation should be just a Boolean it should be uh present or not instead of a UI uint8 uh keski caught me in the middle of this uh of this week and then I didn't really have time to review for Francesco for choice to see if it's equivalent to to mine with different

boosts I actually suspect that it's equivalent to mine with different boosts and this is the reason why I'm worried because I thought that I computed explicitly the system of inequalities that proved that the boosts we had are optimal so if franchescos is equ equivalent to mine without with some different boosts that'll mean that francesos is non optimal uh so this is a worry that I have uh I will post if I find something around this but I think it's better to just commit what we already have working which is removing the payload withheld from the envelope and making the payload attestation just a Boolean that's a

bigger change for us like that the serialization is not an issue because it's still a u8 so it shouldn't break networking uh but treating the the the variable as a Boolean instead of a instead of um an numeration is uh might be an issue so that that can't some time okay so switch Francesco for spending audits yeah the audit I I missed it uh track attestation vote in the Bon State uh what does this mean Terence so in franchesco's Spec he has this condition

right so they look whether they're a block has 60% of the vote then they does a payment later just to ensure that 20% of them is dishonest then you can do the payment just ensure sometimes say it's 39% vote the Builder doesn't get screwed about like or like sorry I think his proposal doesn't get screwed about like having to pay something but later sorry wa wait sorry there a build that doesn't get scol for having to pay something that is a weak block but then later on gets reor so it does def the payment yeah so this is the this is the problem with Francesco fortras that it makes it hard to do the processing of the payment because you need to Quee them uh that

will take longer to write in this spec and um I suggest that we don't do this payment mechanism for now uh until we have a full audit so I suggest we keep what we have now which is remove the payal witheld uh track from the current spec as it is and let's hold on on the payment mechanism uh from francesos because otherwise we're going to have to like as you say like start tracking the votes on Stat or compute them later on I mean this is a this is a deeper

change to the spec um what is the next proposer building an empty block cannot determin retrieve withdrawal from the beacon State yeah yes uh so this was an issue with withdrawals but I think this should be solved at the client level we should just cash them this should be an an implementation detail and not uh and not a not not in the spec the alternative would be to put the withdrawals instead of the withrawal fruit in the state but I don't like this yeah I think the spec just need to

mention that because I think in the validator spec there is a bug there is some there's a line that says get expected withdrawals through uh that helper function I think that might work that might not work yeah so if that's yeah if that's there then that's yeah so to the validator client that you should just correct the that sentence saying that that you need to just cash them right because it is the it is get expected withdrawals but it is get expected withdrawals of the previous state of the pre-state of the of the block um all right so what else so that's yeah so I think that's

that's fine how to solve the taking pool transfer problem well uh we said that we just need a new prefix and that that was the I think this is a blocker for for puts so and that's not a problem for the devet either uh we can just start all of them with that with that prefix is that right all right so I don't see any complaints so that that is not so complicated so I can actually add it uh just adding a new prefix is not a

problem um so we we'll just add a new prefix and Builders are only allowed to be from that prefix uh and then the problem arises of how do we have so Builders can be you can either self build or be from that prefix because otherwise you're not going to have on boarded Builders at uh when you start and self-building I think it doesn't break um self building doesn't break pools uh anyways now at the fork I mean serious Builders I assume they're going to

deposit before so that's not an issue um we can uh enable withdrawals and everything I mean we can just consider them Consolidated for the builders and that's it so that shouldn't they should be Maxi B Builder maxb validators anyways so that that should not be a problem okay so the engine API for retriving payloads by hash and range this is uh this is already uh Implement I mean this is already specified by Rico and no one complained and uh adjusting the intervals I

don't I don't want to do this now this might go if if it goes into production we are going to look into these numbers and it shouldn't be too problematic but yes I assume that we're going to have to like put the PTC both near six seconds if we go purely PBS and probably later if we go with fossil at the same time um but then there's the actual bug of the Rand out what do we do with that uh so it is it safe to process Rand out afterwards or do we cash

it so there's there's two options like move that when we're procing the r mix let just pull that up uh where is it process R mixes is in processing Epoch uh um and the process random mixes reset is what uh the function that is relevant let just put it up here no mixes updates so this is the function the set set this is in Phase zero but this hasn't changed in forever and the question is what would

be the what would be the risk of moving this to the payload this this will um I mean if we do this B payload this will change the behavior if the proposer uh I mean it would allow the Builder to set the random mix and this is dangerous so so or we can just shift it by one slot but I I don't see that as um as a good mechanism so I think that yeah I don't

know the there are two solutions we move this to the post payload and then that means that we don't we just consider the the mix is not revealed when the payload is not revealed or um or or we cach the Rando mix on the state when we get the block we cach the previous one and then the pay we use that one to match up the payload I think this is easier but this adds one extra root to the to the beon state any

takes takes all right so then I'll go with uh with the following um so let's I I'll go with the following if no one if no one complains I'll go with the following so the the proposer proposes we update the mixes but we catch we cat the last one uh before the update so we cach it uh on the state as a latest Rand mixes whatever it is and then we use that one to validate um to validate the payload the other thing would be not to validate it at all but I think that breaks Rando on the

execution layer or I mean we could Del we could move Rando on random on the execution layer to one slot later but I think this like this presumably this could even break contracts so it's safer just to cach it on the on the CL it's just one rout on the state it's not a problem so that that one is easy also to add so the the big question here is do we want to go with franchesco's for choice that uses uh this accounting mechanism to to to pay later in the epoch in which case uh this will add an extra queue to when

we process this payments uh we can overload the deposit queue or we could just keep the payments in a in in a queue and then when we we finalized uh well it doesn't matter when then we just keep the payments for every block for on EO so that's going to add a list of 32 uh values and then we just process these values um on inut transition it's not so hard but it's awkward the other one is to keep the current boosts but then Francisco doesn't like the current boosts uh so I was hoping to prove that they are equivalent

but I haven't there criet all right so then okay so I'll move on with the following changes I'll I'll we'll we'll have as we have now in the in the in the devet we'll remove the the payload with held I'll move by to put the PTC at the station to be a Boolean I'll add the slot I'll fix the randow bug I'll update well actually uh Justin already updated the pr uh so I need to review Justin's changes to see if we we can pass test from previous Forks if you can merge

that that's going to be awesome and then and then I'll add test for um for static tests after this changes uh Justin if you're still here I am would would it be easier if if we fix your changes we merge that and then after that I make the changes um 100% yeah let's not add more to that here so so that so if I if we fix all test and we merge that then I can just open another one with the changes that I'm mentioning which is like adding a slot it should be minor changes but but they pile

up yep trying to keep it as small as possible um I do have one question do we need to update like the the generators to add the E 7732 module so that they get output in the consensus back tests or no so so this is just for old just to make it work with old yeah the pr that I had opened was to make it work with old I mean of course if we're going to if we're going to have a chance of like shipping this then definitely we add the generators but what I would like to have is at least the generators for the static tests okay the four choice is going to be an nightmare but the static ones should be easy isn't

it I'm not entirely sure but I think so relatively because that that really helps a lot when we're doing definit like our first bugs were we we didn't agree on hashing yeah so if we could have like stat I mean test vectors for like how to Hash a state and these kind of things that'll be awesome um but I think that that doesn't need to be part of this PR that you're fixing so so in principle all all you need is for me to review that PR merge that and then I'll start working on another PR to make the changes right yep and I acknowledge that um the current like spec test PR is not perfect like there are some to-dos but

we can try to figure those out later and I just want to unblock us right now okay that's perfect thanks a lot Justin all right so then the two dos are in that order review Justins merge that make these changes that are the small changes uh well no open a PR with the small changes and then uh finally um making the big one which is the accounting mechanism for payments if we go with Franchesco for choice and if we don't we're going to be in problem because we're gonna have to like put back again the the payload with heal thing so I'll I'll work on this this week this next week and we'll scheduled to have a different devet

between at least EO and prism after we open that PR sounds good far it's been any change that I made it still stable all right there no no questions nothing sounds good to me okay okay sounds good then then we could just adjourn and be ready for the peski Fiasco in half an hour yeah all right talk you later see you guys bye bye bye