ePBS Breakout #9

Transcript

oh I'm muted and I've been speaking for a while all right so break to welcome to breakout call number nine I posted a link to the agenda in the chat uh I suspect that the best thing we can do is to start with Julian that wanted to have a brief presentation on issues arising with clot auctions uh should be a short call there are that many things to discuss uh but it's it's I guess it's better if we just start with Julian can you take it from here sure thanks let me try to share my screen uh is it visible for you guys nice yeah

yeah okay um so I just wanted to present a hypothesis for an argument uh that shows there's a trusted advantage in slot otions um it's very convincing for me and I've presented to some people within robust incen group uh but it's not like a I mean obviously it's very far from a fully fledge uh worked out argument so please let me know if there's anything um so first of all what is the noest advantage we want the beacon proposer to be incentivized to use the inal commitments uh to commit to the block clu so that maximizes the proposer utility so either it should be the blood producer that produces the highest uh value blood or maybe the proposer has some valuation for producing the B

itself because it wants to influence the ordering of transactions for example um whatever the proposed utility is it should commit to the person that maximizes it uh but the question is um will the proposer indeed use epvs or will it use meev boost so a way that a proposer could bypass epvs is for example toit to itself in the beacon proposer in Sal auctions uh and say I will produce a block and then six seconds later when the execution payload has to be produced it runs me boost to get other people to bid um and thereby uh like bypass the inut commitment and use trusted V and other trusted sources so that it's still out Source supp production without using

epvs and here I present an argument in why uh in SL auctions a proposer may choose to do so so consider a simple model there's a proposer that can choose the auction at two times at P0 or at 26 or you can say earli and there are builders that try to maximize theirs uh each Builder has a distribution of block values it may realize um and at time T is zero the Builder doesn't realize value it only knows its distribution and at time T is6 the Builder knows its block value what we see then is that if the proposer were to choose to O off at t zero uh and so like actually use epvs uh the Builder uh Builder should bid

according to their expect value of the block um so obviously a builder wouldn't want to bid more than their expected value because then in expectation they would lose money uh and depending on the AL mechanism they should uh if it's very competitive be close to the expected value uh and if the proposer were to choose to aution off at time T6 so at a later time Builders should bid according to their realized values um and the key Insight here is that uh the second highest order statistic of the Riz values which is what the prop may expect to receive at time T is6 is under reasonable circumstances likely higher than the expected BL value X on so if if Builders work purely bid based on their expected

value um this should be lower than if Builders bid based on their realized value because there could be some Builder that has an exceptionally high value for example or just some value that's higher than their expected value and this would mean that proposer would choose the late auction so effectively it would mean that in PBS a beacon proposer commits to itself in slw epbs excuse me a beacon proposer would commit to itself as the Builder and then six second later run me boost and still get a higher price based on the rear B values instead of the expectations can I slow you down for a second yeah just uh the second highest order statistic of realized values is likely higher than the expect uh it sounds as if that that

you're saying with slot auctions that this somewhat enables them to oh I maybe you haven't gotten to that part but um yeah I don't know it sounds like you were kind of saying that with slot auctions they get the option of of taking the later auction and getting closer to the realized yeah yeah yeah so that's a good point so in blood auctions you commit to a specific execution payload hash so the execution payor can't be changed anymore and So you you're kind of forced to aution of at the time that the protocol describes because the beacon block must be delivered in slot auctions you commit to one Builder uh and the execution

payload itself should still change later on so yeah okay um so yeah if we do block auctions then it's definitely a bid based on the realized value but if we do slot autions it's it's based on the expected value yeah okay yeah exactly and so the argument here would be in auctions um the proposer kind of has the option to choose whether it would want to receive bids based on expected value or bids based on their realiz BL value um and so it uh but if it wants to get bits based on the realize block value it has to commit to

itself in the beacon block as Builder and then run me boost 6 seconds later um and the argument here is that likely uh the realiz block vales would need to higher revenue for the beacon proposal that Mak sense yeah that makes sense um and I suppose yeah um it's it's just that I thought this was a argument in favor of slot auctions so maybe that's why I'm confused or were you're saying in favor of block auctions so I think this should be um um it's it's arguments in favor of block auctions okay that makes sense okay I

thought you were pres I thought the presentation was was on by block slot options I was confused no yeah uh yeah I should have specified that but it's an argument against f watchs um in various other research proposals such like execution tickets is used as an arguments in favor but there are some um specifics there that make it uh good U but yeah that's outside of of this discussion uh um so the takeaway is that if you choose orun later you should expect higher Revenue b as proposer uh but then uh there's a bit of a weird assumption underlying this and the assumption is that uh a proposer can use meev boost 6 seconds later uh to sell

execution payload construction rights I think this is a a fine assumption it's what's happening now and if if we were to change the current system to SL autions uh and it turns out that it's more profitable to do this then I would expect boost to still exist and yeah po go ah yeah so yeah I understood the issue have no solution to it and I think we need to think about it but um do you have any idea of like how this changes with timings I mean how accurate is it or do we have stat statistics as to how much do we expect uh the difference between the realized and the expected value to be at 6 seconds because uh a proposer that want to do this will not

have much more time I mean they won't have the time that they have today into submitting a block so today to run me boost we're already at the limits of latency that we can have and to run this thing you're going to have uh it's going to be much tighter I guess I'm not sure uh I'm not sure it might be even worse because the proposer would just immediately announce that they're running me boost they will just quickly submit their block committed to themselves at at zero so that block was going to be assured to have proposer boost and then they can just run the me boost uh auction at about five seconds and play the usual timing games

this is serious yeah I think thanks H yeah so I think I wouldn't know about the magnitude of the of the difference uh I think the difference is surely there and I believe I'm not uh super sure on these specifics but I believe that bids are coming in mostly three and a half seconds before the deadline M boost these days so you should have time doing the six second interval and yeah just thinking about that even if if you think about the the average but uh maybe uh just to catch the potential upside for for the out layers where you got very big uh

uh me thing that happen so just to be uh exposed to a very unlikely but very very big upside you're you you have this in incentive to say okay I'm playing is just another way of playing the timings here just I want to pick the very latest thing that happens any independently by by the mechanism so the me MEF boost way is the way to keep to to to delay The Cho the choice as much as possible essentially is right yeah yeah I see your argument um so let me get into it in this slide because I think it's slightly different um so maybe I I don't summarize well

what you're saying but it sounds to me like you're saying um if there is some possibility of larger value at one to8 and this sounds a lot like a risk transfer so the proposer is uh is basic either the Builder could bid early and the proposer gets to fixed value or it could wait and have a more volatile value that that it get some risk reward ratio basically I think so yeah sorry you can respond to that oh yeah I think you're you're getting right okay thanks um so I think this is slightly different from yeah po I me just quickly finish this F and then uh I think it's slightly different from a risk transfer because uh in this I assume that the Builder panels effectively resell their execution pay

construction rights so that's the second point on the slide with the question mark uh this is an assumption I make here if a builder would be able to effectively retell uh then this result doesn't exist and proposers would probably sell uh early um but then um to ensure that Builders could effectively resell it means that you have to have like a secondary n boost Market uh pop up so I think the true results here is that the whether assult opes have a trusted advantage or not really depends on the state of the secondary market and it's quite fragile so yeah yeah I I got this yes yes now I see what you're mean so part of a mitigation to this is uh I think I got something wrong so a

proposer that wants to participate in this way should not submit at zero building I mean committing to get an auction later because it might actually happen that he gets a good bit now and so at at the very least he should evaluate whatever bits he gets even if he doesn't request some bits uh whatever bits there are on the P2P layer for example and the problem is that if you do this thing then uh then whomever I mean the secondary Market is already how to say this if if the the Builder decide if the proposer decides

I'm not going to commit to to any of these bits that are out outs side already then he might actually end up losing money right because he's doing this early he's looking at bits and is still committing to himself for zero value uh not really sure I mean yeah I'm I'm just ranting ranting uh off the top of my head but but there are two problems that I wonder how much the builders can actually trust the proposer in this situation the proposer can always equivocate and include whatever block he wants uh an unbundling Pro protection of me boost would probably not hold here so I'm not really sure because the the

proposer itself is the Builder and the Builder boost is huge so if the proposer commits to himself and gets a boost he can probably reorg unbundle the Builder so if there are bits outside U yeah I I don't yeah that's that's the thing under under the current epbs proposal I think it's easy for the proposer to screw a me boost Builder yeah and this is in the this is in the context of post this is in the context of slot options after they've committed to building themselves or it's in either in either cont if if you run any sort of like me boo me boost auction because you can do a me boo auction also

for Block auctions as well uh you commit to yourself then you just put the the hash that whomever gives you but the thing is that that the system is designed in a way that the protection for the Builder is so high that if the Builder gives away this protection by allowing the proposer to sign as a builder I think the Builder can be unbundled so I'm not really sure how many Builders would be willing to play this game wait uh okay I think I'm missing something somewhat you have to trust the relayer here right because when you run the M boost option at say the 8.9 second Mark to play timing game you'll have to go to the relayer and then the relayer will be the one that's reducing the

final block basically yeah but if like if you I mean if the relayer needs to make sure that no equating block is going to come out especially in slot auctions where we're not even punishing equivocations so we're not even punishing equivocations on the payload if the is smart he canot unbundle yeah actually I don't know but it's but but then it's not same slot on bunding right this I I think this will be the next same slot right it is same slot you just if if you manage to get a hold of this payload and you submit quickly another payload that wins for whatever reason it wins you just

unbundled uh the Builder and the Builder doesn't get any protection because this key that is signing this payload anyways is going to be the validator a maybe as a validator you could commit to a relay being like the relay being the Builder in your beacon block and then relay hosting the me boost lochain yeah yeah that's true yeah that's true the relay would be there really would be uh but that actually this way yeah that's that's true so this is an honest trusted Advantage but this is something that not that the fact that that there is an advantage but it's something that we wanted to happen any ways right we want to have a secondary Market in which the Builder resells these blocks so this this I don't mind

if the Builder which is in this case would be the relay the relay is buying the the rights to do a slot auction and then the relay resells the rights to the Builder to to build the block this is fine because whomever is buying this auction is in the protocol and he already stated so yeah what you're describing is that perhaps there is an advantage into is is a centralized en force in that the relay will always win this and and the validators would always sell to the build to the relay yeah okay that's interesting okay let me quickly get to the last slide um so this slide is my opinion and it's uh so it shouldn't be taken as facts uh just curious to what you guys think

about it uh so to me um looking at this argument it looks like SL auctions is very fragile to what the secondary Market looks like um so specifically to whether the proposal has more options in the secondary Market than sophisticated Builder would have um so basically the question is if the auctioner sophisticated would you be less willing to participate in the auction than if the Auer is unsophisticated um uh and so for example if the secondary Market attachs fewer biders if the bilder runs an auction then proposers uh won't choose to use the epbs auction but we use the me instead and so potentially um that that's fine if you count like the re thing uh but yeah and then also there's

like a lottery aspect so um you could see as a revealed preference now that proposers for example don't participate in smoothing pools uh that they're very very risk-seeking and so if proposers are less risk reversed than Builders proposes would also want to wait later this is basically the point thato is making and so they would use me boo in potentially this is less bad because then it means that risk is just something that they like so they are maximizing their reward by committing to themselves um which maybe isn't technically a trusted Advantage but something to be taken into account uh and so since it's so fragile and since we're already in a regime of meth boost now uh to me it feels like um if all of this indeed holds uh and the assumptions are

reasonable then it could be that's in s auctions we get that uh either Almost 100% or almost 0% of the time they're actually used and this to me sounds quite bad uh and if we're in a regime it will be difficult to move out of it and so then my question would be like what do we need to know uh to decide on this because it's quite difficult to um predict what the secondary Market will look like and it could also change of course over time uh once epbs goes live and yeah so that's it so curiously here what you guys think about this I have a question Julian so so would you say like this type of a problem will exist no matter what in any type of future alra market right because you you can always

just like instead of committing to a builder I just commit to a relayer and then basically that relayer will just release the best block at the time once the altion ends or once the six second Mark is it is it a fair statement to say this type of problem will always exist whether it's like a slot auction or like a future execution auction ortion ticket um so um for any like autions let's say execution autions are also kind of for blood auctions I think it won't exist because you have to commit to you commited yes and I think for execute like further ahead auctions you're basically forcing the sale via like meev burn or something

so you're basically saying the proposer must sell at this point unless you're willing to pay a high premium for it and I think this will have a big effect on the secondary market so I'm not sure if it will always exist and intuitively I would say no you wouldn't have this if you sell for example to eot in advance uh yeah just I just want to clarify that the secondary Market is the the like selling that takes place after the after you've committed and said you're build you've said you've chosen a builder but it's really you and then you're going to sell it again okay and then yeah basically imagine you just commit to a relayer instead of a builder you just commit to a relayer and then the relayer just basically get the best block and just just propose it right I don't I

don't think it is the relay so so there are two components to this to this sort of attack to to this problem if I just commit to a relayer and I sell and my my block includes a header or a bid whatever it's called with a value that the relay will pay on chain and then the relayer results that's fine that's predicted by the protocol and this is something that we we can live with that's that's not off protocol I think the problem that Julian is describing is that even if I commit to a key for a relayer I am getting my payment off protocol and the whole auction is being carried outside of the protocol and this sends Builders Builders cannot compete

against this relayer because the relay will pay for their actual value of a block instead of like having to predict correctly what the value would be so Builders honest Builders cannot compete against this and this is the centralizing problem this is this is a problem this is a problem that that Rel would always win I think this is what Julian is pointing L I'm mistaken no yeah absolutely yeah so say the payments on the protocol right then if you today you run the honest client software like like then some basically some P2P bid will probably win because they have a higher value and then you just choose a higher value right no no but but the point is the point is that we don't want to have a system in which being off

protocol has a clear Advantage because then every validator will be off protocol we we want to have a system in which being off protocol is fine you can go off protocol if you want but if you have a clear advantage of going off protocal that's a system that breaks us that if you want to rely on altruism don't make it expensive although it's not altruism but yeah that's correct okay so just to walk through the logic yeah if they commit to if it's a if it's a block auction and they're committing to a particular hash then we force the sale at the time and there's just there's really nothing I mean you can get bids Faster by using me boost just because you have a point-to-point

connection but other than that there's really nothing happening off chain uh actually you get bit faster by using the protocol instead of MV boost that gossip sub faster than no gossip is going to lose anyway gossip doesn't exist so what do you mean forget about gossip I just meant I meant I just mean like getting the bids from the builders to the proposer yeah it's you you get it directly that's what the protocol hopes to get that the Builder connects directly to the to the proposal oh or is it okay so Builders will like an HTP at end point and the proposals exactly and then you don't and the relay does is has an actual disadvantage so even if you make a payment of protocol you have a disadvantage so yeah basically you you

set up your me boost to point at all the builders you like and then you're farming that out okay cool and then so then you've got your bid all right and versus the slot auction which enables this whole second Ary Market uh and that's basically the Crux yeah I mean that seems reasonable to me that and we thought that the secondary Market was cool because people at rig wanted to have something like like APS eventually so if you have a system that eventually enables a secondary Market you can move this secondary market and shape it however you want off protocol if you want and then we keep the in protocol uh auction as it is with minor changes but I think what this is showing is that uh that is trickier than what we

thought so what did R think about this Julian I assume that you showed them this yeah I showed them this um I think uh so it's difficult for me of course to speak for them but many of them thought it was a problem um I I presented um the arguments in favor and against those auctions which is the the notion uh document and um so I was part of a larger presentation um I think this was the the main problem yeah and so I think a secondary Market is fine as long as you force to sale early um VI meth bur as something that you would do in execution

auctions so if I could add to that um to me it feels like um two big considerations in block or SL aues are so SL aues the thing I just presented block aues has the the 3da problem that PO has pointed out and also uh the missing or potentially Builders not revealing their blocks uh if they later find out that it's unprofitable to to publish them um and so I think these are to me it feels like this is the main tra off what was the first disadvantage of the block auctions 3da yeah it's you can you can you can post you can post a hash and and the PTC would vote that the payload was

available and then you produce a payload that is invalid so that payload is dropped by every node but you can prove that you had that hash and that every node had that payload so that data it did exist yeah you get this for free so is this a DA problem a free da problem that's a DA problem that arises in Block auctions that we do not know how to solve see okay um so I feel like uh the arguments in favor and against block and SL auctions are somewhat well known uh so I'm just curious how we could move forward on that um yeah how like how to make a

decision so I I have an opinion on that matter uh from the implementation side these two things are very trivial so and we're still like far from from from having a defet at least a few weeks so my suggestion would be to stay as we are which is on block auctions uh we have a major change that we need to anyways rebase which is this change by Lucas about the going to talk about this later but it doesn't matter just to keep on block options and whenever we make this decision it's just a it's just a few lines of change it's not it's not a big change for us to Mo move from block to slot options at least this is not for prison so I think it's better just to

continue on the implementation side while these discussions are carried a sync okay sounds good um I'm trying to find people who are interested in looking into how often Bloods would be withheld in blood auns um that's probably a research thing and then I could update you async how that goes that's great um I'm I'm I'm I'm still worried about this da problem because I'm not sure how how much of an issue it is I I can definitely see a market for a for a rollup that requires the validators to be live I mean dumb

like I don't know this has probably been thought of before but like if presumably you can have an onchain egg get at a station by the entire PTC saying that the block was invalid do you really need to include the block on the chain no but the no the block is never included in the chain so because this thing is invalid you drop the thing uh but the the PTC so in principle you could you could uh make the PTC evaluate the block and check that it was invalid but we don't want to have this because this puts a high requirement on the PTC this puts execution on the PTC which is the big win of PBS is that you delay the validation of the block now you're going

to put the validation of the Block in under one second which is just tough I see so another one which was uh yeah so there was something yeah I that that that comment I don't know how to I don't know how to solve the the 3da but also it's not really clear how much of a big problem it is like when I mentioned this Franchesco seems skeptical that this is an actual attack to me it sounds like a like a really serious attack I guess it would depend on the I mean one of the things it would depend on is the relative price between like da and execution um and like da is pretty cheap so like you know having to

outbid like valid execution and pay that uh could be I mean not that we necessarily want to rely on this but it's just my thought is like if if da remains cheap you want to go outside of the 444 mechanism and soon per ass which with prices on one guay at least at this point just to have some da I don't know yeah but the the the thing is what is that that you're pricing right so so today da is cheap but that means that you can send a bunch of transactions with a couple of blocks with a couple of blobs cheap but with this you can send a full payload that's several megabytes so you can send a full payload

on every single blob because the kcg commitments anyways are going to be there and uh and you get all of those for free so you get several megabytes for free or for whatever the bid was so as long as those megabytes are cheaper than the me payment on a block it's rational for you to post that way if you only need it sporadically right you only need it for one slot yeah is

there ever like the good thing about that if this becomes a serious attack the network can react quickly because it's someone we can even slash uh the proposed the Builder anyway but the network will react quickly because you need to have a series of validators would parti on this and you can Blacklist them immediately so if you see a builder proposing invalid blocks validators wouldn't immediately check it and vanilla validators can Blacklist immediately the Builder so so a rollup doing this seems like unfeasible but uh but still it's an attack that is out

there can be can be something in protocol here potentially where you see the PTC voting everything and then the block is not included so you can afterward penalize situation yeah like could we decouple the the like if you if you don't reveal or like if you Reveal Your when when you when you when you have a commitment on chain you're like on the hook for that amount of money can we can we decouple the amount of money that you're on the hook for for including a block from either having an invalid block or not revealing yes so so that that was The

Proposal of Lee from offchain Labs just uh penalize after the fact for the da exact for the maximum amount of Da at the gas price that you could get which is something we can do uh but it definitely complicates the protocol because you need to go back and see what the Builder was and then you need to get a you you do have the the Builder's commitment but also it becomes a it becomes another attack and you need to start like studying what are the for chice implications of this because every time that a payload is reared now that Builder would be uh would be penalized so you need to have to prevent

this now you're going to have to be enforcing a PTC commitment being on chain so today the PTC vote is never enforced on chain it's only put on chain to reward the validators that are tested but under this penalization you're going to have to keep the PTC vote on chain and make it a matter of consensus uh more than just four choice so I think it's like the complication of like penalizing for this is just too much or at least it's a level up from what we have today anyway I think it's it became clear that

uh Julian made it made an exposition that there are these trade-offs we seem to have like serious attacks it seems to me that the slot auction attack that was presented today seems pretty bad at least at the moment I can't think of any way of solving this like having shipping the whole thing so that people just anyways bypass it and seems since I'm reasonable but this requires like client changes right so you have to modify your client entire like this is L client code for this not really because you're gonna so the client the the Builder API is going to be completely covered by us so keeping a MEAP boost Fork that uses the

client is going to be a very minor change a very minor Fork it's true that you're going to have to have a fork that automatically that doesn't connect to anything and it just commits to yourself right but me boost is going to be essentially supported right yeah because uh we are going to we are going to be requesting bids from Builders directly so that's all that they need right right you basically just commit to yourself and then you basically don't check any big value from everybody else that's it which just anyways that thing is going to be a flag right so I'm sure I'm sure prism at least will include a flag that says build locally meaning just

commit to yourself so the the the the fork of prism I think is going to be easy to make well we do have unless someone has more comments about this we can move on on the agenda we had uh Mark wanted to discuss something and Terren wanted to discuss something so we can go with Mark um I mean I can post a link I can share my screen though have a lot of screen so it might take a maybe I'll just I'll try sharing uh how do I do this in

[Music] Zoom uh no maybe I'll post the link I can't figure to do it might take too long okay so this is just the I posted in the chat there's a thank you um a link to like just a simple engine API method it's basically the exact same uh specification as get payload bodies except you return the whole payload it's renamed as get payloads because you're not getting a body you're getting the full payload um maybe we could just make it a get payload bodies V4 INR the whole payload and say that's the thing it doesn't really matter that's just semantics but

um this is the all these I just wanted to have something written that was like concrete that was a proposal so we can talk about it not that this is the end all form of the method but the reason we have this is um like the the consensus node often doesn't want to store the beacon or the execution blocks because the execution layer will already do that and then you're wasting dis space so we created this payload bodies method so that um because the execution because the consensus layer stores the the headers if you can just get the bodies the the transactions and stuff combine those with the headers you

can get back your full block and so you have that saving of space but now we don't have headers and so if you want to have the same saving of space where the the consensus layer doesn't keep the full execution blocks around you need some method to get those uh execution blocks from the e right now there is there's two reasons to do this compared to using something like e get block by hash number one e get block by hash doesn't accept a range and we're often getting range syncs uh I mean the main reason to do this is that you're getting range requests from other nodes in the network and number two if we use get blocked by

hash we would actually have to have rlp in the consensus layers of decode to transactions and get them in the form that we need so um yeah it's just not designed for consumption by the consensus later um but yeah like basically if we don't have this our options are use get by hash and put rlp in the consensus layer or have the consensus layer store all the payloads and duplicate the space because the execution layer is already doing that can I ask a very naive question sure I I don't understand why we we we

even need to so I I I I honestly don't know how how the the El sinks so why do we we need uh this range requests I believe it was for cl syncing actually not e but that's my point so for cl syncing you you kind of need it now because you need a block and you need I guess the block hash but for cl syncing all you need is the blinded envelope and the black because the blinded envelope has the right hash and you don't need to validate the payload for cl syncing how do you get a payload for Sal syn but

that's the thing so if the E is syncing the El knows that the hash if the hash is valid or not because the El is sying on independently on their own so that's it's my lack of knowledge of as to how they are syncing but my understanding is that if they can sync independently the blocks and I told them syn to this hash this is my finalized hash uh yeah I mean I right so I'm looking at the PDP interface so first of all there's a couple things being said at once here which is number one are you saying that the the CL doesn't need the payloads when sinking so so the

CL our syncing spec says that we need to submit the payload to the engine to validate and we need to wait for a request from the engine so therefore we do need the pay up but my naive question is why do we need the pay up the E can sync on their own and we have the hash and We Tell them I've synced up to this point and this is the hash is it valid or not and the El tells me yes it's valid for this height so why can I not take it you still need to process the payload though you still need to process the payload right the CL does not need to process anything the CL needs to

process the payload envelope and we have the blinded envelope is everything that you're right that's right that's right the only thing from the payload today that we need to process is withdrawals that is outside of the domain of the payload inbs and even in electr so you're asking basically like why during sying do we need to keep sending new payload new payload new payload new payload to the E when it can based on the hash and just thing uh I think the answer is we actually don't and there is a minimum amount of of validations that we need to do and those can be found in like if we don't send new payload there there are still a

minimum amount of valid yeah you're talking about the block hash but I even that has block hashes as and like uh I don't know if even that we don't need to do anymore because we don't even care what the content of the block is okay that's I mean the yeah the reason the reason though that we have to do the the Block H hash has to do with a specific kind of attack like um I know that at least where for withdrawals I can describe this attack so if you can force the yeah yeah but

because withraw is part of the block hatch but starting with Electra uh well I don't know about Electra actually because I think they probably still use it for RP but definitely on on epvs if we move to as that we don't care about what the content of the payload is we don't need anything from the payload nothing we don't care if the hash is even wrong um we do in terms of like the execution payload saying the execution engine saying that the block is invalid that it can no longer be the head I mean we yeah that's why that's why we only need the

the actual hash to send it to the L and the L would reply yes I have this block is valid or the L replies no I have this block and it's invalid and that's it okay I mean let so let me try to explain this attack if I can remember from memory so I think the the idea is that you Force if there's a mechanism of forcing the El and the CL into into or like the El into sorry the CL into optimistic sync if you can do that and you have this situation where the CL is not sending every payload to the E then what you can do is release two blocks which are different and where the validations between the two don't match up so like

it's wrong on one side but it but side doesn't validate it and it's wrong in another way on the other side and that side doesn't validate it basically so for example with the withdrawals like on the I think let's say on the on the CL is what validates that the withdrawals are correct and so you release a CL block with correct withdrawals um but with the wrong block hash and then on the E side you release like this crazy withdrawal which isn't correct and then you calculate the block hash correctly and that's the block hash you put in the CL side if that makes sense so you you put

in you basically have two blocks but they have the same hash and on the and on the CL it's incorrect hash but the CL has the correct withdrawals and then the eel you have an incorrect withdrawal but the E doesn't verify the withdrawals and then you have the correct hash wait El does but the El does verify so when you send um so the can't when we send the payload for validation now when we send the payload for validation now we will need to we need to send all the requests so this includes withdrawals yeah but the the El doesn't withdrawals because it can't no the El

verifies that those withdrawals are the request that they are fulfilling in that block the E can only get the withdrawals from the CL like from the payload on the CL and that's that's fine we can still send them without having the payload we only need the withdrawals so that's my point that to the El we can send a blinded envelope and the El can verify that the requests that I'm sending match up so I think yeah actually it doesn't matter the Y only consumes the request from the envelope yeah actually I don't

know to think about this I mean did what I said make sense though like where you kind of have two blocks but there it does but but this is a problem that we have today because the withdrawals are within and it's part of the block hatch I think it disappears once we just have this as a z object and the withs are outside of the payload yeah I mean it it's a good question I'm not I'm not sure I uh I'm fully across why like all I know is

that this verify and notify new payload function in the spec which almost no one talked about this function but but it has a number of validations in it and these are the minimum amount of validations that you must do if you do not send every payload to the to the E yeah yeah so it's just the block cash validation I understand and prison might be the probably the only client that doesn't do it no you're not it's only it's only it's only Nimbus and Lighthouse that don't send everything to the to like you don't have to do these validations if you send everything a new payload yeah yeah I understand understand we never want to implement this r&p thing so that we

don't need to check the block hatch yeah if you do and that's fine if you send every new payload request to the El and that's what prism does then this is fine and everyone except for Lighthouse and Nimbus send every pay every new payload request um and so Lighthouse and Nimbus are the ones that have to do these extra validations but these attacks are somewhat complex and I don't understand them enough to say that it's fine you know to to not send new payloads but but what you are proposing right is is to not send new payloads and just have the E the El sync on its own yeah so I'm proposing that optimistic syn needs change but but okay so to be practical

in this meeting I think what you're proposing for the engine API is perfect because it's a minimum change so that we keep the things the same way that we are now yeah but uh and yes we should probably move along with that but same time I'm going to start a call with uh with Misha uh and try to see if we can just get R if after accepting as said on the on the on the E we can get rid of these things yeah you you still need a new engine API code even for that right because you need to pass in the payload hash to this e and then the E will return valid but then in this case it's just a payload hash but we have the hash

from the bids like that's that is something we already have and so you can just use that basically yeah all right so does anyone have a comment about this engine API method if people have seen it I mean anyone disagrees with implementing it this way because we haven't made any changes on the engine API this would be the first new method added to the engine API ethon also suggested the same same thing all right so that seems reasonable um Terren wanted to discuss

moving process withdrawals to the execution phase yeah I guess just briefly right because I feel this is something that people has Sprout up every two weeks basically people ask that why can't we not do withdraw on the execution phase what does the withdraw curently has to be the consensus pH it's because the it's because the withdrawal is originated from the Beaton State and then it's redeemed on the cons on the execution phase but we also could move uh withraw to the execution phase if we want but then I mean I think currently it just feels safer more nature to do it on a consensus face and then just block on the execution if the if if there's an empty block basically but we could also

look into they are moving to a face so I'm not sure what's the best like step forward to me it doesn't feel safer I guess I mean I could be convinced to sayfe it's just that I have to sit there and think about it whereas is like it seems immediately obvious to do it on the on the side of because like you know like the way that it was framed in the spec is the state transition has been split into two phases and so like let's just do it on the phase that that is processing the execution payload side uh that and you know it kind of already to some extent needs to be done

there I mean not if we do caching but you already are checking that the withdrawals rout matches which is the same exact check as what used to be in process withdrawals so it like yeah in a sense to me it it it feels actually like it's more similar to what we have pre BS because oh no no no wait so it is sure in the happy case it is exactly what we would have pre BBS the problem here is that withdrawals affect the safety of the beacon chain and they affect the economics of the execution layer uh so if you get a wrong

withdrawals on the execution layer you can you can get paid but if you get wrong withdrawals on the beacon chain you can get out like say slash money and and there is an actual change what is the difference of executing it uh and I'm not against moving it to the execution side but there's an honest difference which is the following let's suppose that I today withraw with the current specification I send a withdrawal and this block lands and I withdraw so my withdrawal is going to be deducted right now on the on the beon chain and and now let's suppose that the next thousand blocks are missed not not missed but empty there's no payload there's a

liveness problem on the on the Chain now my validator is leaking but it cannot be leaked because I just already withdrew so the 16 withdraws that were included in this block were already withdrawn on the Bon chain and they need to be fulfilled on the execution layer if we go with the design where we only process on the execution layer then my validator would be leaking for 100 blocks and what I would with thrw would be different would be a different value so the effective balance might have changed and a lot of so it has it has an effective balance change so these two withdrawals are effectively different and we need to verify that they are set guess I just

don't follow because like you send a withdrawal yeah that okay so this does this have to do with the ordering of process withdrawal requests versus process withdrawals is that what this comes down to no no for forget about the withdrawal request okay but I thought you you send withraw I I I send I send a withdrawal like I I withdraw my my Val I exit my Val okay so like you whatever whatever form ofra okay even if it's a partial withdrawal it's fine suppose that my validator was to be partially withdrawn now in this block yes currently I would par we throw like 0.1 e and that's it that's that needs to be

fulfilled in the next payload yeah but if we go with the payload one and there's a thousand blocks I can actually leak during those thousand blocks and then when the next payload comes in I don't Withrow anything see so this validator one this implies the existence of a q sort of like no there's no Q there's nothing the beon chain continues advancing if there's a a thousand blocks where beon blocks are coming but yes and the payload is not I might even be slashed during those thousand uh blocks so this validator that could have

been exit exited or withdr or whatever in this block on one scheme will not be exited or whatever withdrawn and might even be SL slashed in the other scheme so these are different outcomes for the from the Bon chain perspective and we need a for Choice analysis of this outomes so I'm not comfortable changing this without getting that analysis the current design is such that on the beon chain is exactly as we have now and on the E side is different turn like process withdrawals effectively doesn't run if there's no payload the last time uh yeah but the first one does so it only affects one

block that I agree it only affects the last block before the liveness problem so there's 16 withdrawals that will be different okay I I guess yeah I'll have to think but I my my thought is that this whole thing just shifted one block and that I don't see how the attack is different but I'll have to think about it more well because the withdrawals are something that is determined by the beacon State at the point where you process them yeah so if we're not freezing and the beacon State keeps advancing without payloads then the withdrawals might be different after a

thousand blocks that are missing Oh I thought the withdrawals would freeze effectively because process withdrawal doesn't run I thought no Butz but withdrawals don't the thing is that the beon state is different so you're not processing a partial withdrawal of a validator that got slashed for example process withrawal is not doing anything but the beon change the beon state is changing therefore the withdrawals that you expect when you call process process withdrawal now or a thousand blocks from now from now it's going to be they're going to be different okay and you're you said it was 16 so like basically if you're the guy who's getting a withdrawal in two

blocks and then this thing happens you're out of luck and you're in the same position is what you're saying yeah so so if yeah that's correct so the only thing that changes is for the guy that will be withdrawn now and then suddenly it's not and that I don't I don't think it's I don't I agree that I don't think it's a dangerous thing but we don't have that danger analysis I mean yeah we could think about it but that seems like so I don't see how if one is preferable to another I don't yeah I don't know the the one has exactly the same behavior as it is today on the beacon chain the other one would be a

change in the beacon chain I see okay I see what she I think I see what you're saying now um in the sense that like I see because currently the beacon chain cannot progress without the execution chain progressing at the same time um and you're just saying that like if we know that okay yeah I I would be really I per I def perer move it to the ex surprised if

it mattered but we are on the same page and I also prefer moving it to to the execution but I would want someone to actually think about this problem before we decide this I want someone to to assert yes this is safe I thought about this the changes are s they seem safe to me uh and and it would it also seems like an easy change on the spec so that's why I'm not not that worried of doing it earlier or yeah so I'm not sure about what the

status of of implementation is for us it would be easy to change it now we already implemented this but it would be easy to change it now so if people haven't even started doing this we can't change it uh and it might be simpler for everyone yeah yeah I I haven't implemented process withdrawals yet because I got stuck on it when I thought when I didn't see that one line but it would simply it would definitely be simpler for me to implement just because it requires no changes to the process withdrawals function uh so I mean that's that's just easier and there's like no changes to the the but yeah I also it also has an advantage

that you don't need to have this extra field in the state yeah and a cash is always ugly so so I do agree that it seems better why don't we run a poll in the in Discord because we're already over time why don't we run a poll on Discord and then decide what what to sure all right people we are already over time I don't know if people have more comments thank you all right thank you guys I'll see you in a bit thank you guys guys right