ePBS Breakout #2

Transcript

so I I propose the following uh since we're hopefully client devs that are here instead of like having uh instead of having a discussion a high level discussion how the market is going to be and these kind of things uh I want to move to some implementation details and some of the things that change on the timing of block of block uh processing I've had some slides that uh I presented at flashboards which I think are actually good for showing the the the the structure of the of the block and how it

changes so can I just share those and then go over the timeline of a slot again and then we move into what sort of things worry me on the implementation or do you guys think of this in a different way sounds good sounds good yeah works for me good so then let me see how do I do this though uh mostov probably I need to do this like this move this guy out and then do this guy as a slideshow which is good okay so let me share a window [Music]

this one so hopefully you can see something yeah and you can even probably see my yeah can you guys see the the slides yep yep okay good so this is the ATT turn slot today and I want to remark on just the the difference in slot validation which is I think this this important change which is uh typically blocks are being broadcast at two seconds uh to get the block to be broadcast there's already a couple of hops between the Builder and the relay the proposer and the relay and then there's the validation at the level of

the re or at least there's an optimistic validation at the level of the relay the block is produced and it's typically arriving to noes at about 2 seconds and validators have 2 seconds to execute that block check data availability uh execute the transational consensus and attest to it and after that we're essentially done for the slot we don't do anything so our CPU is consumed in those two seconds essentially uh because the other hard computation that we do which is a slot transition we all of us cash it at that moment anyways so on EBS this is going to change and this is going to change in

the PO following way uh at about two seconds or let's say whatever it is we know that proposers are enticed to uh try to send their block to broadcast the consensus block as late as possible so let's suppose that that number is still to seconds it doesn't matter what when that number is okay it's going to be the maximum possible that it takes so that it's still possible to process that block and attest to it we suspect that that time is going to be much closer to the attestation deadline because now the block only needs to check the consensus transition so this is pre-merge information pre merg computation which is only check uh which is only perform the consensus transition state uh State

transition function wait hey pus yeah can I ask a question sure uh why is there any incentive to delay the consensus block here because you can still request bids as late as possible and that means that the build more time to give you a better bit yeah yeah okay makesense so this doesn't change this sort of timing game doesn't change but it's actually kind of Irrelevant for the network now it it may cost more rears uh just exactly as as as they do today but actually uh we're going to go over purchase perhaps but uh validators are actually forced to reor late blocks anyways and the Builder is going to

force them to reort the block so if the if the proposer is actually late requesting the bid the builders are going to actually enforce that that block is is Reed um so validators will attest around three three seconds in the happy case which is today what's happening uh a builder will get all of the attestations before the 4 seconds Mark so before 4 seconds the Builder already knows that the block is there that the block is attested and he broadcasts the block this this is in no attack scenario this is the happy situation in the unhappy situation the builder needs to make a decision by six seconds but the

usual case we are going to be receiving our payloads at around 4 seconds into the slot so the Builder so now the The crucial time is CL validation that is still critical and but it's much lower time like on prism we are executing the state transition in seven 70 milliseconds uh the builder needs to account attestations I think this is something that we need to implement so I I think this is something that we might want to have an endpoint that says give me the attestation count for this current block or give me away from the bco API to so that the Builder queries it and says

this block is strong or not uh I think this is a new endpoint that we need to implement uh I I I think it's unfair to request the Builder to check Che this but anyways um at 6 seconds the Builder makes um a choice it can either send a message that says I am withholding the payload or it sends the payload and here's the crucial change we don't need to execute that payload we only need to have it executed by the next slot by 3 seconds when we are test we do not even need to check that the blobs are there we only need to have the blobs by the next slot at 3 seconds when we attest the only person

that actually has to do this before is the next proposer the next proposer only has instead of up to n seconds it has only six seconds which is up to the cut in the next slot so the next proposer needs to have already validated this payload and needs to uh have uh already checked data availability but this is still uh 9 seconds for a testers for execution and seconds for data availability instead of two for both so I think this is the critical change and this is all I wanted to go over I can go on forever I have like slides for a lots of things but this is one of the things that I wanted to discuss the timing

change are there any questions so far so I look at my note for data and currently I think the block arrival time ranges between 1.5 second to 3.5 second I think and then it's pretty like evenly like between the two Spectrum I suspect it's just one Spectrum there's no timing again and then and then the other Spectrum there maximum timing game so but I suppose they will eventually adopt to this new three second deadline and just basically broadcast at a 2.5 second or something like that to push you to the boundary right I guess another thing to note is that instead of gossiping both consensus and execution today you are only gossiping the consensus part of

block which is smaller which the network propagation time will also be shorter as well that's another note I have yeah um aren't you also gossiping the payload though no the payload is only gossiped afterwards okay you mean after the first round of attestations right so so the payload is only going to appear after after the Builder has seen all of the attestations right and just to clarify the PTC committee is attesting to availability of the payload not validity as well exactly so that's why we need to validate it up to the next uh three seconds so the PTC only says I've seen

the payload or not and the PTC doesn't even give you uh doesn't even wait for head uh except when uh you have I mean when you have a Discerning view a different view uh from the majority of the network so the what the PTC does is the following if the payload was there and the PTC voted that the payload was there you're validator you got the PTC attestations and you saw the payload and you saw the payload as valid so you need to validate it then you assign to that block to the full block you assign 40% more of the weight so that's uh that's the guarantee

but the thing is that a know is validator anyways in the typical situation would have the Builder's payload as valid and will be it its head is there any yeah I'm sorry is there any advantage to uh like delaying the validation of the payload yes uh yes is a huge Advantage uh you get 9 seconds instead of two to validate it that means that for example we are not we're going to have much less uh much much stronger astranis on for choice because there's many times that you can't really attest for a block and you attest to the parent because you

haven't finished executing the block this means that if we solve like for example the state load uh bottleneck or if we are in a stateless ethereum we can just send huge blocks we can increase the gas limit a lot because we're going to have time to execute them so the those doing PTC vote they would be validating the payload as well right no they they own when they when you vote you don't need to validate it you see the payload with a commitment which which has the right hash so you see the payload where you what you validate is the signature of the of the Builder you check that the Builder is actually sending that payload that the hash that is sending is the right hash

that was committed in the consensus block and that's it so it's a signature verification that you do and that's that's it V is about the availability of the payload that's correct it's literally payload timeliness committee so I think this is the big win uh this is the the the best outcome of epbs and it has nothing to do with actual trust assumptions on the relay uh there are ways of doing this purely on the El by changing El consensus uh which have actually better assurances but uh but this way we are only dealing with the CL Fork it doesn't

change at all anything on the El you mean like moving to a pre-state route rather than a postate route right so you you just only assert on the pre-state instead of the post state but this I think is a deeper change on the L with here this change is actually easy right um okay so that's one of the things there are two other things that I wanted to talk perhaps one is implementation and the other one is design uh let me go quickly over withdrawals because I already mentioned this before so this is Builder safety and I don't care about this uh this one this is a generic situation that I this is a better crowd to discuss

um we have and we have from time to time we're going to be adding on Forks uh more requests from the El that to the CL that are triggered by the El and these things now need to be care carefully thought about so this is one complication that happens on epvs so this is a good case is withdrawals withdrawals are completely determined today without this execution withdrawal from 70002 withdrawals are completely determined by the beon state we include them in the block and the what we currently do is we check that the withdrawals that are expected in the beacon

State they are the same withdrawals that are coming in the block so that's the check that we do and then we process the withdrawals onbs this is going to change now we are going to continue deducting the validator When We sync the consensus block so we perform the state transition at the consensus side but now those withdrawals are not fulfilled in the execution layer when we process them both together when we have the assurance that the execution block and the consensus block are locked in now we're going to process the

withdrawals we deduct the validator and then we requ we require that the payload to be valid needs to satisfy the same withdrawals that we've already paid out that we've already deducted so when the payload appears the payload is invalid if it doesn't include the same withdrawals that we already paid out so what what it means is that if there is an invalid payload but it's corresponding Deon block can will still be valid and will be part of the chain that's correct and that means that we're locked on this situation until a payload appears that is valid so that means that the next beon block that that that is processed is not going to process

withdrawals so there's a there's a hatch at the beginning of processing withdrawals that says was the last payload full was the last block full in the sense that was there a payload in the last block and if there wasn't then that means that the last withdrawals weren't fulfilled that means that we do not process uh that means that we do not process the withdrawals for this block this is this is this is actually pretty niiz in the sense that Beacon layer is now a bit decoupled from the execution layer right so we can can still jug along while that's correct the beon the beon the beon change the beon chain is going to continue moving on something s similar happens with this

inclusion lists but I don't want to go there now because that's slightly subtle but the point is that whenever we have something that is uh that is um tied between el and cl that both sides need to fulfill something then we need to check on them and there's another extra change which I said uh which I don't know I think this is an API change it's still not an El change but the point is that now the the the payload when you process the payload and you fulfill the withdrawals and whatever it is now you need to put in the state that you actually process the payload that means that processing an execution payload also carries a

state transitions on the consensus side so that means that the execution payload has a commitment to the post state of the be okay so the way this works is the beon node requests the payload it computes the it computes the the new the state transition on the consensus side and it adds the state root of that change so so like technically we kind of have like two post States one like after applying the consensus block and one after applying find the payload that's exactly correct and in for choice if you

read for Choice that's exactly how it works we still have the block states which is the post states of including the block and then we have the execution state which is the post state after including the payload so if a slot is full as in like we have the uh payload as well like is there any reason why we would want to store like the Intermediate State as well like yes because you might want to reorder the payload if the Builder is malicious and is re trying to split the view on whether the payload was available or not you may have not seen the payload and some other people might have seen the payload so there are situations where you want to base your block on your head which is your consensus block and not the

payload okay so you might need so you might need to store like two states for each slot in some way like if you're caching a bunch of that state that's absolutely correct and the the state is minimal the the only change is essentially so I haven't gotten there on prism and implementation that's one of the few things one of the next things that we we're about to do but I suspect that the easiest is to just make the processing because on the consensus side the only processing that you're doing is you're adding the the fact that the the state was full that the payload was there so I can re the payload without reing it's corresponding we can block that's

correct but you don't actually really need the post state of the payload because you just need to know at which which payload you're committing to so you could have the state second state transition even even later am I right you could do it lazily you you definitely can do it lazily yeah so that's but the state transition is there and yes you that the way that we're going to implement it is going to be we're just going to cash the fact that the payload was there and if we need to build on top of the of the postate we immediately produce it because it's a trivial change but Chang of of of the York that you actually really have to do that well

at some point you have to do that in any way yeah you need to rehash which is the issue so you need the parents the parent State yes yes so so the issue is rehashing but the change is just one or two leaves yeah for us it's it's pretty fast just doing that because everything is catched you know in our s impation uh so I don't know what you guys want to go over uh so this withdrawals is the canonical example of something that worries me uh the other thing if if you want to move the discussion to the one thing that I was thinking the people at rig uh have been pushing for execution

tickets and these sort of like other alternative designs as the endgame of this I do not know how to deal with execution tickets at all but slot auctions seem to be quite possible and an easy change from this uh I I had another question before that yeah with respect to with respect to local block building so uh so in case I want to build locally so the flow would be something like I just request my uh execution node for the payload and uh like it will go through the same Builder flow right like uh I will be basically submitting the signed uh the

signed execution payload header with like the Builder index as my validator index and I also have to ensure that I have sufficient balance on the consensus layer to be able to pay out uh whatever uh uh whatever fees I have gotten from like whatever payload whatever the payload is supposed to be paying paying me out is that right oh you can make it to be zero so so they so you would request uh you would request your own bid right so so I think that the easiest to do here is to overload the get payload uh the get payload call which when you get the payload then you're

going to get the actual payload and either the CL can build it or the El can give you the bid already prepared I suspect that we want to have the E being given the bid because I think Builders are going to be using that uh that API but it doesn't matter but the thing is that for local payloads what you can do for the bid is just put zero in you include yourself yeah that makes a lot of sense so another advantage of doing that is that you can actually gossip the payload much earlier as well you don't have to wait until 6 second to review your payload you can just C it almost at the same time because it doesn't matter and also another question that I

had was that like uh since the uh you need to maintain a balance on the consensus layer so in uh times of non-f finality like uh with the with the recent changes on the deposit uh 6551 whatever we basically agreed that we don't want to uh process topups during uh times of non-f finality so like during periods of non-f finality would it be an issue if a builder is not able to top up its consensus leer balance because of some is that a concern at all don't know well I think we're very far away from this being an

issue right validators have 32 e uh if there are very large blocks that make the Builder to run out of funds I think we're going to be in much deeper problems already by having nonf finality long enough so I I I suspect this is not an issue yeah okay that Mak sense I mean sure if if we are a few months without nonf finality and every block is just like today or just a couple of epo without finality and every

block is a 30 e block of me extraction there's something wrong with the chain already if you're if we're extracting 30 e on every block on a chain that is not finalizing there's already something wrong in the chain or with maxb you can top up your balance well yeah but you can't in the situation that uh you can't in the situation that is described which is we're not finalizing enrio you should interrupt instead of like raising hands we're only a few here I think in total we're like 15 yeah because I just want to switch the conversation to something else

actually what teren said in the first comment was a little bit worrying me which is uh in case of latency we could have a non progressing progressing chain like can you can you elaborate a little more yeah yeah yeah so that was my agenda topic that I wanted to bring up right so yeah yeah but then we can move towards there if there's yeah if that's okay yeah I guess we can just move towards there so the motivation was that um I started doing this because of p d was also working on um their for Choice back and in their first iteration not

the latest one in their first iteration they also had block s voting and so I thought comparing this two version of block SL voting between um between um p and epbs to basically see the difference and I also like I'm me Po SOS of this word right I also look at the current EP BS for Choice um analysis and then we have some sort of safy analysis right for example two slots you guarantee some Builder safety you assume that current proposal and the next proposer um trying to team up against the Builder and then try to reor the payload or try or try to make the Builder pay so we have that type of analysis we also have proposal safety analysis as well right we kind of assume

that the current Builder and the next proposal are trying to screw the current proposal by using proposal proposal so we have the analysis but something that I realized that's slightly different is that in the block slot um EP in the block spot for choice and the P side they have more of likess analysis they basically look at what is so assume the performance is under some really bad Network condition right and then your chain grow can stop if it's the block hites four seconds to reach to the other clients and I think in our case it's worse because it's 3 second right so then without some sort of like uh back up like scheme because how um P does this that say today you have some backup

scheme if you have a you have a few skip slots the backup scheme gets activated and then your empty slot vote doesn't come for the current slot it comes for the previous slot so they have kind of this way to like gradually uh recover the chain if today everything's under bad synchrony so I wonder if for our epbs case we probably need to do some sort of Life analysis I think that's one thing that may be missing so yeah I I so yeah I am curious for input yes so this is an easy change on for choice and uh I haven't added it yet but after talking to Francesco in uh in

Kenya was clear that we need the same so the situation here is that if you vote for empty then so if validators wasn't really clear now but uh so validators vote at 3 seconds and if they voted that they haven't seen the block so they vote for the parent those votes actively vote for reorg the current block that means if the committee votes for the parent block then the honest validators will take the parent as head will not take the current block ASE even though they saw it on time so that means that if you have a situation where every block takes more than three seconds to process then every

block that arrives votes for empty and empty continues winning okay so that's that was always the blocker for Block slot uh Fortress and uh the easy way this applies also to the payload right because there is an active vote of on on the withhold so the missing execution payload uh yeah go ahead I don't no I think like is there an explicit vote on missing payload well so but it's only a PTC right and that's a cheap that's a cheap statement this is the payload appeared and said I'm missing and the BTC says

I've seen a missing payload right well if if that's if that that thing um actually wins so if the majority says I I haven't seen it you're saying that it's not an explicit vote on existence is only on timing so if you it it is it is in timing is an existence are the same right it's is it's an explicit vote on the existence of a message either the message is the payload was there or the message is the payload was explicitly witheld and sure if the majority of the PTC votes for the payload was withheld then honest validators are inclined to

reor that block even if they saw it on time and that block had a majority of votes so this applies also there I mean if if if you see CL coming late even a bigger a bigger payload with even the blobs definitely will come later as well in terms of network latency I'm I'm not following uh so so the the proposer sends the CL block and it arrives late right in that situation then the Builder will not even send his payload the Builder will send a message saying I am withholding my

payload because the for the Builder the Builder will evaluate his own head at that point so at six seconds the Builder says give me the head of the chain and the head of the chain will not be the incoming block with his uh commitment because the committee hasn't seen that block therefore it attested for the parent therefore the honest majority head is the parent yeah I see I see that is a so the Builder just says well the head is not the head that I that I committed to so I'm withholding my payload so it's not something that can happen only on on the payload has to yeah so I think the payload for this timing issue is irrelevant yeah so in that sense it's Al

better CL epbs for this issue in Block slot so for pier D this is a little bit more complicated because in beas the latency is more than 4 seconds to everything like availability execution pay executing the the payload and the checking of this of the CL block here this deadlock happens if every CL block takes more than 3 seconds to to process but still we need to add a safeguard against that otherwise for choice is just formally not safe so you just add a safeguard which is very simple after four or n or whatever constant blogs you've seen empty you stop voting for

empty yeah Franchesco already has a PR for that so I was paste it to the chat anyone's interested but in his for Choice he doesn't have the notion of empty which we have empty yeah forch is complicated and I would appreciate a review of that um foras is really complicated it's easy to implement because it's just changes to a small piece of code the complication is reviewing the edge cases uh I don't know if anyone has started seeing uh on implementation I

can say that so far for us it seems that the hardest part is just the networking part like the you need to add objects for PTC attestations you need to count them you need to aggregate them uh you need to include them in blogs so you need to add all of these processing of new objects but I I think so far this has been the only thing that changes uh I'm worried about the fork itself I do not know how I I haven't even thought about it like we're going to switch from a Destin a 4 seconds to a Destin a 3 seconds uh I I don't know how hard that's going to be those minor things that are part of minor in the design itself are might be an issue Al so this is not an issue oh not Lighthouse not not an

implementing I see yeah so I have no clue how hard those changes are going to be the fork itself might be hard I I had another question implementation wise so uh like assuming that like epbs is sort of like the first stage and like later on like if we have some other execution tickets or design something like that would that like do you know if those designs also have this sort of separation between a consensus layer block and an execution layer block because implementing that itself would be uh quite a lot on the implementation side so if we like switch to this and then like again we go back to like a

place where the like consensus and execution layer blocks are combined then like it like the implementation would get really messy at that point so I was just wondering like so so I can I can answer that so there's three three answers to that so three different points uh one is uh no one has an implementation no one has ever thought about an actual implementation of execution tickets and Slot auctions and anything that is not this design of APs no one wrote any any python spec of any of this all of the discussion so far have been more about a

higher level discussion of what what the right auction or the right block spaces however when you come to think of or at least what seems to be obvious is that when you come to think about how to implement this these things uh you always keep that separation there's always a the notion of an execution payload and the notion of a consensus block and they are separated in all of them in all of these assigns this separation is always there the second answer is adding this separation actually is not complicated like if it's only on the C side this is not really implementation complicated I am much more worried about other changes like

what happens with what happened with attestations we changed the attestation type and this was a mess uh and I'm wor about this like we're changing uh the adapation time now instead of type and I suspect that this is going to be a mess too uh but adding the extra the the new state transition all of these are contain changes this is the new core function which is takes a payload and it process it it's it's very simple to those changes are really simple at least in prison's code those are very very simple uh so that's the second answer and I had third one which I oh so the third one is this uh so far I'm only

aware of uh slot auctions as a as an improvement and execution tickets as an improvement and when uh yeah that's right Alex is we would just change in a timer but the problem is that this timer happens at runtime at the fork it's not really clear how how easy is it to change that but anyways yeah I didn't want to derail what you're saying but it doesn't seem terrible yeah the same we the same at the stations that's why yeah I haven't the type I mean yeah the type because you just have to touch so much more code but you know if this is just like if Epoch blah four if Epoch other blah three you know it

feels okay but yeah it might it might work uh okay so I was going to continueing to P one but but Tony has also there is a reward uh but the reward is in the current implementation it's very simple if we feel that the the incentives really warrant a change we can change it currently the PTC member is just an attest is one of the committee members for that slot so what they get is either the attestation correct or not so they either miss an attestation or they get an attestation they get a full reward of an attestation so it's a very simple way of implementing that I try to keep it as simple as possible the the spec Chang it

I haven't made any economic assurances of whether the PTC also the PTC changes on every slot because of this design so it's not something that we're gonna have a problem if it gets uh if it gets owned for one block is there a PTC look ahead like two same of attestations it's exact is you just get the last few members of each Committee in the attestation committee uh but also the PTC doesn't uh doesn't change uh your head so if you have seen a payload it doesn't matter what the PTC told you that payload is your head so it

only affects against defending for defending against attacks it's not that the PTC is going to force you to not see a payload uh so the the the thing with all of these extra designs which I think it's actually quite nice I haven't done I mean smarter people than I are looking at this the the economics descience of slot auctions or whatever it is what worries me of all of those is the fact that if you haven't committed

to a particular payload then the execution proposer can produce different valid payloads and if you have different valid payloads so if you have equivocations on the payload the ATT testers need to vote on which one is the head and if you run an attestation scheme to count and give them lmd weight then now you need to worry about slashing conditions for the equivocations that's the reason we we have safety because we have those slashing conditions when when you attest to contending branches so this was a blocker for a long time but then we it just hit me that this is not really a blocker

because the at this slashing conditions are for FFG and the payload is not committing to a particular payload but it is committing to a particular Target vote because the payload corresponds to a particular consensus block which already specified what the target is that means that you cannot have equivocation on targets so it means that for slot auctions at least it seems that we can just use the exact same EIP and just change just not commit the do not commit to a particular uh payload and we can do slot auctions easily I haven't included this because well it seems like an easy change if

it's de save and uh for execution tickets it's different because execution tickets don't even commit to our Target execution tickets are by the by the protocol they are sold you sold you sell the right to produce a a payload in a future slot and that future slot well might be in a different neoch therefore you're not committing to a particular Target so an equivocation actually can equivocate on FFG so and this I do not know how to solve so I think execution tickets my impression is that it's impossible without increasing the slot time so in the case of epbs it it would you

can't have like equivocation but you can basically have this payload exists or doesn't exist sort of in terms of folk Choice oh well right but the thing is that attestations don't are not so there's not round of attestations for the payload attestations are only for the CL block okay Mak sense yeah so so an Adder cannot even equip Ates the how big is the PTC commitment currently is 512 validators yeah I was just thinking because this is starting to sound like the same committees and then we have honest majority assumptions and yeah it's just worth thinking

about yes so we did that we did do that computation we checked that it's uh like the average time for a 33 Staker 33% Staker to take over a committee is something like 30,000 years or something like that it was fine yeah 512 was fine the thing is that this is a global topic so it can't be too large because everyone needs to listen to this topic um and I was hoping for 256 but that was perhaps too too small no PTC commitment rotates every slot Tony no gajinder is asking

every single slot we change the PTC commitment everyone is listening to that topic and everyone is Computing the committee the beon committee for attestation so it's easy I'm not uh following guys can you speak up instead of like writing in the chat is we're not that many it's easy to have a conversation okay yeah I was um just asking whether the members that are selecting to be part of the PTC committee uh just don't have incentives to give good attestations as long as

there they are part of the BTC committee now since they get rewarded based on their BTC contribution and not on their they are not their their attestations are ignored okay the the attestations of the so they are removed from the beon committee and they are added to the PTC Committee of that slot so their attestations they only get a reward if they they attest for the right thing and uh it's a little bit tricky in the sense that um so there are a few things that are not specified well because I figured that this is not worth to have complexity but the propos

user needs to pack these attestations in the block so that we achieve consensus on whether reward them or not uh specified it that the proposer can only pack PTC attestations for the last slot and no other slot so that means if a slot is lost is missed then every PTC Committee Member will lose one attestation this didn't seem to me like a thing a bad thing to do also there's no checks that on equivocations of PTC attestations so in principle the PTC member would be inclined to sign both it's present and it's not or even three it's present it's not present and I've seen a withheld message because the proposer will include the right one and

that's it and and it wins uh if the proposer includes equivocations there's something that is added there to penalize the proposer for including the wrong thing uh but there's no penalty for proposers colluding in that way that if they see every attestation they choose the right one and they include it okay I figure this is just too little money to be worrying about and also there's no like any slashing conditions for uh PTC member equ equivocating right that's right so that's that's why so the slashing is that if the proposer includes them both then the proposer is penalized but yeah so I

haven't I I don't think there's a danger perhaps there is I don't know yeah I don't know perhaps if the majority of the network is malicious and they everyone sends like all possible PTC messages uh and then the proposer of the next block chooses which one to include it might it might have an uh it might have an issue something to think about that's that's good to add to the notes then effectively like it's the next next slot proposer who's choosing whether like the payload was seen or not in some sense right the PTZ

is completely useless in that case uh well that's only if the C so here the PTC is chosen randomly so you're assuming that the the PTC is malicious that means that the majority of the network is malicious and if the majority of the network is malicious then yeah anything can happen anyways but uh if for some reason the PC clients they are hacked on what or whatever they're moded so that they send all attestation but the network is Still Honest then it's not good enough the next proposal so this is an answer to Roman uh the next proposal cannot reor the payload or not reor the the the the blog just by looking at the

PTC commitment because the the for choice is given to the CL uh to the CL vote so why can't we have PTC slashing on PTC V location the sense that they are voting for the same block but in different outcomes uh we can uh slashings are just difficult slashers are expensive you need to add these conditions you need to add processing it's complexity that it's not I'm it's not it wasn't sure if it's worth it but in the gossip rule we could still apply the rule that we we send over the network only the first for the it's already the same so it's

already there so it means that the second option and the third option are less likely to be distributed of the network so definitely less effective also also in the case of If he if he wanted to add a slashing condition it would essentially be a double v slashing right that's the only thing that uh PTC can do that's correct but also if so this is this requires also the proposer of the next law to be uh to be choosing correctly right because I you need to achieve Quorum so you need to have at least half of the network that sent that signed for the same thing yeah the around the PTC side I'm

not not particularly worried the only thing that worries me is that the PTC vote gets on time in the happy case it seems that this is going to be easy because uh well the payload is going to be available at 4 seconds the PTC committee can vote for it at 4.5 so the current deadline is nine but I expect that on the typical slot we're going to see the PTC vote at 4.5 ah modul of something that I haven't told Rick to analyze there's the following problem this is a problem the builder of the current slot Sees at 3 seconds or two seconds or whatever the payload appears he sees a commitment to his block and he has that information he knows that block no one

else does so question does the Builder delays the the broadcast as much as possible or not I do not know wait why would they want to do that do that because it's is it adversarial because then like other people don't have information on time uh to start building the the next block exactly and I've been told by flash Bots when I gave that speech to flash Bots they told me it doesn't really matter because the six seconds that any ways by default the the the Searchers will have is more than enough to search and to build oh we're already 50 minutes I feel like I

to cover this meeting anyways uh so I've Been Told that this is not really an issue but it's it's something to keep in mind that it might be I haven't I hadn't realized this until a couple of weeks ago but I also interesting yeah sorry but it's also like I don't think we have visibility on the Builder game this something we probably will need help on talking to the builders they will be able to give us input because if you really play the Builder timing game right you can get like nine seconds to build versus the next Builder can only get 3 second because I will just delay my reveal at the very last second of the PTC deadline such that only get three second and I

suspect there maybe a compounding Advantage there if today I win the slot I I win the next slot and I can just keep playing this game and just be the winner forever in that sense it really does sound like a proposal cling games like if you play the game like all the way like you can like if everyone delays to the max then everyone gets the exact same rewards but it's still interesting to to look yet yeah so this is one of the reasons why barnab suggested that we we shorten the deadline for the PTC vote so that the Builder is forced to broadcast immediately and so we shorten the time

between PTC vote and Builders reveal yeah that sounds also kind of right because the Builder supposed to be sophisticated and well connected anyway so it's not like more like yeah and in any case anyone that is a homaker would be revealing like six seconds before so it's not a problem for haker r i I'm not against this I it seems it seems the right thing to do to do that guys we have like eight minutes uh I know you have said that you haven't started implementing it but I wonder if you have question about like or or opinions on what do you think it's going

to be hard what do you think it's going to be easy what do you think we should probably change I think one thing is that if you look at our current spec it's GNA change is our current spec has inclusion this in there and I don't think inclusion this will be part the EIP though you probably W yeah so don't look at the current stack that's po PR number two yeah yeah I promise uh I'm I'm traveling tonight uh I promise that in the next few weeks like say two to three weeks I will I will try to have the the EIP ready uh it's not really clear that's going to happen but it should be soonish that the full EIP would be uh opened and it's going to be without inion list on

the Lota side I would like to start working on it as soon as basically the spec is clear and the documents are available so so if you take the current spec so turn SI is not to look at it but if you take the current spec it's trivial to remove inclusion list so just grab the current spec and remove everything that says inclusion list the documents are completely so if you look at my hack MDS I put an entire annotated spec already like every single function is annotated in those hack and D there are two large hack and d one is purely for for choice for choice is not changed except the availability of the inclusion list

and uh so you can just either assume that we could for example Implement an EIP with empty inclusion list by default that doesn't touch the Y so we could ship ppbs with empty inclusion list so maybe if you know I can get to study I mean is there any place where those links are handy uh yeah so my my pool has everything it's just that I'm open of let me just yeah there's every every large the yeah look at the two links in that pull request that pull request has all of the

spe is it one or two which which one is the right one it's the second one I the second one doesn't have maxb and 70002 so it's easier to read the EIP needs to include them because it's going to be on top of Electra it's going to be harder to read on top of the net so the implementation you guys are doing it's on top of Electra well it was on top of the neb and now we're moving to the top of Electra because I'm hoping that it's actually going to happen on on the fork after Electra I mean of course if everyone coincides and everyone has everything ready then I'm

going to push for Vectra but but I'm hoping that this is going to be in the F for so this is three sorry I mean I just Jing that this is electr 3 electr 3 what oh Electra 3 I think it's a joke yeah yeah so okay so we have like four minutes I'm not sure one thing that you bought up I I I missed earlier is that

like for the S Community the current deadline is 4 second right does it make sense to change the S Community deadline between 4 second to 3 second to align with the tation deadline right I haven't even thought about this yeah yeah yeah it has to be the same I haven't touched the syn media okay someone take note of that I have I do have oh well Tony put a lot of questions I I can reply to what the spec say today uh who does the job beon committee members because we want the and I have a good

understanding as why this has to be the case we want that committee to be changing every slot so that not taken and you cannot own separate blocks in a in a in a row and the beon Comm already does this so you can just take the same sapling is it rewarded yes and it has to be rewarded do want it to be very much deeply rewarded I don't see why the committee is chosen at random and threshold is 50% so you're already broken anyways if you don't take 50% so I think just an attestation is fine vanilla clients are going to be enticed to attest correctly uh interference with attestations I don't know what that is PTC can easily get split viewed fine

but it doesn't help anyone so the the Builder that wants to create a split view it's useless because the next proposer already syns The View so the Builder can only damage itself it's not going to create a fork at all the payload is either there or is not there the PTC only gives a boost so the next proposer enforces the Boost and that's that's it so PTC is not really important the PTC is only there to give a guarantee to the Builder so the Builder is inclined not to overload the PTC the Builder is trying to use the PTC so the revealed payload is bundled

with the next block or not no the payload is sent uh by by the by the Builder and it's processed in the CL as just a new block a new block type so if the next proposal uh I mean it's basically colluding with the pre previous proposal and the payload is not revealed will it cause any issues I'm sorry so if the next proposal is colluding with the current proposal and the payload is not revealed to most

of the people and let's say the PTC V was not enough as well so would it have would it uh cause any problems can you repeat so you have proposer of n proposer of n plus one colluding uh and yes and the Builder and the Builder doesn't reveal and uh yes so basically n proposer gave the payload to Builder n+ one uh to proposer n+ one but the payload is not revealed to the rest of the uh rest of the validators so would that be an

issue no uh no not at all because uh all of these Cas all of these cases are analyzed in this for Choice situation like if the proposer of n plus1 produces a block on top of payload that you haven't seen then you cannot even validate that block until you get the payload it's just the same as today if you're a proposer and you hold two blocks in a row and you withhold your first block and then you send the second block no one is going to sync that block until they get your previous Block it's exactly the same as with two consecutive consens consensus blocks

another thing I was wondering it just because the idea came out in my head now is there is there a possibility to to make S committee being the PTC as well it means that you have the same SC committee that starts voting for for PTC as well instead of you don't have so new messages just change the messages and this vote for two things oh oh you want to overload the syn committee so that you remove syn committee attestations and you them to to vote on two things so they play the role of the S committee

plus being the PTC depends by when the Sy committee happens if the commit happens in in a in a in a consistent way compared to the PTC it they may could they could be moved at yeah this is probably doable but the problem with that is that sync sync committee attestations are aggregated and so PTC attestations cannot be this is the reason we wanted to have a very small committee that uh that can attest every slot and the attestation need to quickly get to every node right there is a round of aggregation in commit as well yeah and the rotation times are also not same

here we want rotation of this slot yeah I mean they they you could give up on this rotation if if that makes sense I I agree that we could overload but then we need to remove aggregation on sync committee and that I think and but also having a lan running committee like this that's takeable that that's that becomes a a a danger I see right uh someone asked uh about incentives I think this is probably not a discussion to have two minutes before the end of the meeting probably add this to the agenda

in the next breakout in two weeks yeah next breakout we could take an hour to start that question yeah there's already like a lot of literature on that if you look at my own slides there there's there's a good argument against the document by Mike and and Company on relays after EBS and I think I'm well I'm always I'm always thinking that that we have the right design all right so if there's nothing we can probably close here and meet in two weeks hopefully with people doing

something also feel free to drop the questions in the epbs Discord I think there's a few questions that we missed to answer but yeah just drop it there we'll helping thank you guys thank you very much for everything you took notes Terence right there were some yeah I will share notes on thank you very much see you guys thank you bye