ePBS Breakout #18

Transcript

all right so welcome to call number 18 uh it should be just like the last two or three calls it should be just very fast uh is just a recap of where we stand and what are the changes that we're going to make um we were requested to have the full up to-date CL spec uh in the CL spec so we so luckily Justin has informed last week he merged my large PR updating the tests so that was merged last time he changed it he put it up to date and and merged it which was very useful so now the 7732 Branch actually does have all tests

up to the previous um Fork at least so we are in a situation where we can add new test vectors uh so the two Chang changes that uh that we want to make and I wanted to comment on them are uh for Choice well it's just for choice but the thing is that this induces an extra let me describe yet again we had this described by Francesco not long ago uh but I want to make a again a quick description of what uh these changes to four Choice are because they're actually minimal the current pack or at least the sign notes

for the spec they re so we rely to give um safety to the Builder we rely on this mechanism by which if the Builder decides not to reveal a payload because the block is poor that is it's not attested then our for choice is made in such a way that we will reorg the full block so that's the way that we have of giving the Builder safy um for this we change the way of accounting weights in for choice so that if you see a block say late and you vote for its parent then your vote counts uh counts against the block that was late

so not only doesn't count for the block but it actually counts against and then the next proposer uses that weight to reorg the block so that that is just the the current design and this is this has names as block slot voting uh Francesco proposed something that is less invasive to for Choice which is let's rely on the same mechanism that we have today let's not reort the block the next proposer is allowed to reor the block if it's very poor by using proposer boost but even if the next proposer decides not to reort the block what we can do uh so is not is allow the the Builder not

to reveal by if if the block is poor poorly voted then the payload doesn't need to pay the fee so so that's the mechanism is much simpler from the point of view of of for choice because now you don't need to be accounting votes for the parent block against the block that was late so that's that's an advantage it's much simpler in the sense that the weights are essentially same as we do today uh so let me let me describe the changes we so as today nothing changes in the way of accounting

votes except the following if you vote for a block route and that block rout is based on a full parent or is based on an empty parent then your vote can only be uh supporting one of these two branches like either the empty parent or the full parent so whenever you lock in on a on a block route you're only voting so you're already locking in on the status of the parent payload so that's the change and this is already included in the current uh C spec so essentially the only change that we need to do to the current Sal spec is to remove the weights the is to

remove the the boosts and that's what I will do however there is another change that is on the blockchain itself which is as follows since now uh so let me describe how how is currently the the mechanism so this is something that gets actually more complicated because of Francesco's for chice change so today the the current PR and and this is the behavior we have now with tech on the dev net is that when we process a block it includes a bid it includes a header from the from the Builder and then it immediately deducts the payment from the Builder and it gives it to the

proposal now this is safe in the current mechanism because the way that we have to enforce this safety for the Builder is that the full block will be reared uh if the block is weak and therefore the Builder will not pay because the block will not be even included however if we go with franchesco's for Choice uh the mechanism now will be different we will allow the block to remain there and still if it's poor we don't want to uh enforce the payment from the Builder to the proposal so how do we do this now we will have to change this in the following way when we process a block when we process a the the block

the the consensus block so we have a header we will deduct the payment from the Builder but we will not give it to the proposer we will put it in a queue this CU will be just a circular buffer of 64 slots these are going to be the last two EB Bo worth of plugs now when we process a payload there are two different ways of doing this I'm going to describe the easiest way when we process the payload then that payload by definition has to be the payload for the latest block that you have so you canot feel a missing payload that you have in previous in previous slots that just uh in previous blogs that's impossible

because then you will just change the remainder of the of the chain so you can only include a payload for your current head of the chain so when you do this then you remove the payload from that queue and you give it to the proposal so you just empty whatever you had the queed payment and you give it to the proposer so the the proposer immediately gets paid and this is fine because the block is included and the Builder uh well the Builder already was deducted this payment however what happens if we never process the payload that means the Builder has um has withheld the payload or the payload was late or whatever it

is then what we're going to do is at the whenever we process transaction attestations coming from block for a given block rout we will add the effective balance of the validator so this is ADD process attestation we will add the effective Valance of that validator to the Q element so this Q will have this last 64 blocks it will have the value that the Builder was deducted and it will have the weight of the Val validators that attested to that block route two epochs later when we are processing Epoch trans we're going to grab this 32 blocks of the full Epoch that we're just

processing it doesn't need to be finalization or anything which just processing impo transition it has nothing to do with finalization this because this this follows the includ ability rule for the attestation which is exactly so this is the only the only thing that matters here is that you can no longer attest to these blogs so therefore you already know what the weight is and that's precisely the case so this is no no interactions with FFG which is the problem so then but at that transition then you know that this block what is the weight with respect to the full committee and if the block has more than 60% then you give the payment to the proposer and if the block has less than

60% then you return the payment to the Builder so that's that's the change so it makes blockchain slightly worse we're going to have to keep this buffer of 64 um 64 uh elements in the state whenever we process a block we're going to have to modify process attestations so that uh we grab the balance and we give it to the we we add it to this particular uh spot I think it's safe to have it as a circular buffer it's going to be over written in every single slot that's fine and uh so I've done that design and it seems to be robust and I think it's fine for clients and it's not so

invasive because when you're processing attestation you already have at hand the Justified state to get the balances because that's that you need that state anyways to process the attestation so I think uh it should be a simple change uh and these are the two changes that if it's all right with you guys here uh I'll just open the pr immediately and then we just can move on and have the have the full the full I have just one comment here so now this 64 slot uh validity for the attestation is tied to a specific length of the Ring

buffer in the state are are these two things actually the same thing from from consensus spec and I'm not remembering remembering in my head now so if we end up changing that 64 uh length for the attestation is this anyway um a consensus change in by itself or then yes so if if we change the validity of the attestation for I mean I'm not sure if I understand the question but if we change U the includ ability of the of an attestation to be more than 64 slots then uh that's a hard Fork but it's hard

Fork by itself or just now because we have this ring buffer that is tied to the that length no no I think it's a it's it's it's by itself today right so the yeah okay I just want to make sure that introducing this is not adding uh a consensus change I can double check but I believe that uh an attestation actually is not includable if it's more than and it's a is a is a consensus rule so the state is invalid we can check it but I think so in in in either case if we if it's not then it wouldn't be a problem because uh this still becomes independent I think it

doesn't weaken the the Builder safety if you just decide to pay if the block has 60% in the next two can do the calculation anyway in 64 in 64 slot length even if is not really aligned to but it's less exactly so so the thing is that it might be the case that the Builder could delay attestations for more than two EPO to not to pay but um yeah so but that's that's sort of like a like a farfetch attack that doesn't doesn't say much right

because it is a builder that doesn't want to produce the block by definition cannot be included so it's it's a grieving Vector that is silly yeah uh so this this is only the path when the payload actually is not even uh produced so what what can happen is that someone wants to grieve the Builder by um by by like withholding attestations for a long time and then it may happen that well yeah I don't know I don't I wouldn't know how to exploit this after two ebook so it doesn't work okay so these are the only two and

all of the other stuff we already discussed and I think it's we we sort of agreed let's just keep it simple uh no no payments for for PTT attestations um there's uh there are some things of view merging that uh I don't know if yeah probably should describe here um there's this extra change that that that that is U sort of like off the protocol itself it's this off chain which is the following is you are gathering PTC attestations and um so they they start coming in let's say at at nine seconds or whatever deadline we

put then at 10 seconds uh you need to not consider any more attestations so when you're going to do the analysis in for Choice uh you are going to include the PTC attestations that you only observed up to 10 seconds plus all of the attestations that come in the incoming block so this is to give a slight buffer for the proposer to merge The View with the rest of the attest so that's a a minor change should be trivial fores uh and this it doesn't need to be included in the seal spec uh well probably is in the honest validator spec there there should be a comment

about this oh actually on on PTC attestation I need to change this so that you don't includ in the for choice if it's not coming from a block and it's coming after 10 seconds then that that should be there and um so this thing of like not paying for a testers or ignoring the second attestation if it's an equivocation all of those things we've already agreed so I think it's uh it's useless to continue discussing them so are there any questions about the changes that I'll just I'll push uh either today or Monday all

right that's it I think C wanted to know about the status and we haven't changed we were we were loged on these changes for the last couple of weeks uh we had a finalizing defet which is quite stable and we're going to iterate again after including these changes and we're going to try to like have the next one already fully fully featured anything else oh okay this this um has there been fur thought how 7732 works with fossil uh yes so there hasn't been any new study as far as I know the tradeoffs are like

well known the fossil makes the timelines in epbs slightly worse and but at the same time BS makes the timelines for fossil to be slightly better so so fossil like worsens slightly uh epvs and epvs uh enhances fossil slightly because it gives a better timeline for for to check the satisfaction of inclusion lists uh and Francesco's four choices s like is is adapted it it's simpler than the than the version that I had in a way that it makes it easier also to to

verify the to use to overload the PTC to so that they can sign not only for the availability of the committee but also for the satisfaction of the inclusion list so you can overload the PTC to to do that that's in that sense is that it's slightly worse for epbs because now the PTC members they need to perform a task that they didn't need to do before are there any more questions Justin just logged in I don't know if you guys have any questions from the El side nothing specifically bud I'm just

kind of lurking for now um I'm trying to learn more about epbs and fossil in general specifically in the context of Anders um design for steal transactions so just so you know why I'm here I see yeah so I I think I complained with with aners uh that the design as it is today is not compat strictly not compatible with the PBS uh so let's see Caleb had a question this uh the cpvs considered changes spec design for pier D are they good to go in the same Fork

uh no so epbs is definitely not ready to go in the same Fork as P does today uh um we are basing our branches on top of Electra not on top of P D um they are both compatible P epvs makes Pier Das easier U because it also gives much more time for propagation of blobs columns and again Francesco already took care of like uh adjusting for choice to be compatible with pias by also overloading the PTC so that the PTC now it would signal not only availability of the committee and of the payload not only a

satisfaction of the inclusion list but also uh satisfaction of Da so if we do that then again it's the same situation as with fossil pieras makes epbs slightly worse and epbs makes uh p d better and and for the same reason because now the PTC members they have less time to perform more duties so I'm not sure what else um can we do can we say

all right so is there no more questions we can go have lunch and on with our lives uh I expect that the next meeting that we have is going to be more intense or at least we're going to be planning at an actual test net again uh because this the CL spec should be ready by in two or three days I'll ping you guys to review the pr all right I see a thumbs up from enrio it's good enough for me until we have other clients I'll only focus on pris and Teo having this definite all right guys thank you very

much and I'll see you in a couple of weeks have a good weekend thanks P see you bye guys bye my