ePBS Breakout #7

Transcript

all right so welcome to I think this is the seventh breakout room for epbs uh we have some sort of an agenda today uh and we have a topic that is a little bit complicated that I would like to discuss um but anyway so before we get there I posted the link to the agenda there uh so let's go over the points that are noted there perhaps some people might show up uh as we go along so the first point is the EIP status no changes here uh I think the main PR to the consensus repo has been merged since the last breakout

room uh implementing block uh only the markdown for uh block um auctions and the only testing that that EIP actually does is testing that the fork code is compatible with the previous Forks so it only tests the transition ition up to the transition into epvs but it doesn't test anything on epvs the pr that actually does all the testing on epvs is quite invasive and it's still open I don't think it's even been reviewed uh that's all about this EIP status implementation status I think it hasn't changed uh perhaps I can I can report over prism prism has uh we

are somewhat Advanced we have most of the helpers for for processing the blocks on the sync uh package over the network and uh there's been quite a bit of Advan in the RPC end points to Pro to propose blocks uh but we still need core processing and for Choice which is uh which are going to be hard um perhaps gajinder can speak about two whether or not you guys have been working on something already or started implementing yeah so on lar also we have started and me and NC are working on it uh we have sort of got the types uh done and some clarification regarding that uh in the channel and uh

right now I am looking at places where uh where there is a blinded block and uh normal block SL execution header SL execution payload uh handling so that uh this can be taken care of in the new Fork because all the blinded types are now sort of collapsed into the normal since uh the consensus is mostly blinded uh if you if you think like that um so one question that I had with regard to that is how would the block contents uh apis basically the produced block API will change I think it will also uh collapse into uh into just a

single thing I'm not sure whe whether uh I'm sorry I'm not foll so so the question is how how is the the block production uh workflow yes so basically how is the block production API changing uh right now we have for example block contents uh so we have produced block V3 API and it basically has uh it comes with block contents or it comes with the blinded block and uh so so that that thing uh how how that is changing and uh one other thing that I wanted to oh so you're thinking more more on the beacon API not on the on the engine API to produce a block right yeah yeah on the

beacon API between Beacon and validator yeah and one more thing that I was curious about was uh are we sort of building this on the Petra I know EIP says on Petra but again Petra is right now undergoing lot of changes and what we have started is on the top of denb and uh I don't think that it would basically cause any issues if we sort of later re based to pectra or are we already building on top of Petra oh so in prism we are uh building on top of pectra uh and the spec PR is built also on top of Vector on the on on on

essentially not the not the tip of pectra but there's been not that many changes from pectra uh so I need to probably rebase to the latest changes but those are very minor so on this on the spec PR the the the pull request is on top of pectra all right regarding your previous question which is how the block production goes it's true that we didn't include uh a pull request to the beon API because those things are typically quite enous so everyone seems to have an opinion how an API should work and i' rather be out of those discussions but also the the API which the workflow itself changes a lot if we

go with block options or slot options so probably we can talk about this later in the talk in the call all right understood so what we'll do is I'll sort of rebase the branch on De of Spectra basically I wanted to AV that uh but since prism is already building on top of that so I guess we should also move on top of pectra yeah so I I think it's going to be be easier for all of us if we work on top of pectra like all clients are quite advanced in pectra already testing so most of the typing system should be already in place for Petra so if we build on top of Petra it's going to be easier for us to like keep it closer to our develop branch and test on on Vectra

that's that's what I'm guessing I'm not sure if everyone would agree sounds good so we will uh so I'll be targeting uh the block flow uh block processing flow and uh NC is looking towards uh PTC and uh uh consumption of uh of the payload uh and uh so basically yeah that is what is our Focus uh going forward but yes I think if we can sort of have some sort of clarity on block production that would be nice all right uh yeah so let's let's talk about this in like when

we discussed the last point because it's could changes quite a bit um but okay it's now perhaps let's clarify now how how we are dealing with block production so if we go with with block options you so the the validator would need to to make a call to the beacon to get it a block to to sign just exactly as we do now right and this happens at the beginning of the slot now the beon needs to produce two different objects it needs to produce a signed execution payload

header for the local block and it needs to produce a signed execution payLo header from the Builder and then compare them and uh and see see which one is better and return that block to the validator to sign now how would that go with block production my I think the most optimized way would be the validator makes one call uh and but it needs to call before to get the header because it needs to sign the header because the block route will depend for for the final block would depend on the

header that that is included in the block so the easiest way to do this is to make two calls the first call is give me a header to sign then the validator signs it and gives it back to the beon and then the second call is give me a block to sign and then the beon rep responds with the right block either with the local header or with the Builder's header which is already signed uh but then that block already contains the right route so that that requires two round trips yeah go ahead so the first round thing is uh for the local Brock production right correct and then you get the header immediately and then you you sign

it um yes so that's uh that's one thing um so these two round trips on the beon side are handled by a single call into the execution engine so the the this is the beon API right so what we just called we just Ted but the execution engine can deal with all of this with only one um one call which doesn't change at all so the beon in the same spot would ask give me a block to the execution engine and the engine would reply with the payload and then the beacon out of this payload would make the sign well the execution

payload header that would return back to the validator to sign and then it will have to keep that payload in a cache because if if we use that header then the beacon later needs to broadcast the execution payload envelope so with the same payload the beacon needs to produce two objects the header and the envelope if it chooses to use local payload then it needs to broadcast the envelope and if it doesn't then it drops the envelope uh okay so there's only one call to the engine but two calls between the validator and the Von so basically that depends upon whether we are embedding the execution block hash or

not because if we are not embedding execution block hash then I mean what engine could or what Builder what uh local I think it's the same so the the the workflow is the same which is a shifting time so if the workflow from the beon API so now let's do slot options so the work workflow from the beon API would be the exactly the same the validator would request give me a header to sign uh the header will not include any block hash at all uh uh and then it would call again it would sign the header give it back to

the the beacon and then it would call again give me now a block to sign now the beacom doesn't need in this stage when it gets the header it doesn't need to call the engine at all it doesn't really call the engine at all it just when it gets a request to get a Heather it doesn't call to get a payload it just produces the Heather with the data that the beon already has it doesn't need any information from the engine to produce a Heather but it does it would sort of need to figure out a bid a value for it for for the header right so this is this is really a problem uh we either want to have a we want to be either involved or not so we either put an oracle on the

engine so that the engine says well I more or less expect that this is going to be the value that I can give you a block for now or uh or we sort of like have some eristics in terms of gas price or whatever it is I don't really know what's the best is if we if we have an Oracle in the engine that's going to be a change in the that's going to be a new end point in the engine it doesn't really make any sense to request a payload at this stage because we're going to have a better or a different payload later so we would be requesting a full payad just to get a value but I think if we sort of keep the local in simple then and if we sort of

get a value that is sort of uh what collection of the fees uh I mean so so depending upon that can we allow the payload to add more value it value to it later on uh than the value it sort of committed earlier yeah so so we don't even need the payload at this stage that's that's the thing so we could in principle just request the payload now get a value and then request a payload later and get a for example if uh if we sign uh or if any Builder sign U uh locally or external Builder sign an

execution payload header with a value with a bid uh so as long as they produce uh execution payload envelope with a bid or with a value greater than what they bided I think that should be acceptable because in that case uh things would be really simple because you can first make a call to get the value and in the second call you can get the payload which will obviously might have value greater than that oh no but wait a second so I don't understand so you don't change the value of the bid right so the the the the payload envelope doesn't have a value only the value is only on the header which is committed with the block so the block commits to a

value with the header and this is completely independent of what the payload would would have oh that's nice then this problem is sort of resolved in that way yeah yeah the payload doesn't really need to pay anything so it's only on the header that the payment is done the question is local building how does it work and if you don't want to change at all the engine API for slot auctions then local building could work as follows you could just request a payload at as we do now at the beginning of the slot it would give a you a value and you already committed to that payload so that's the

easiest way of implementing a slot auction you committed to that payload and the Builder hasn't committed to anything so you're comparing your local block right now versus a future block of the Builder because they're beaing on what the value would be uh 6 seconds from now uh so I suspect that local building would always lose in this situation uh right so that is another way would be to put another way would be to put an oracle uh you could have an oracle that says uh I'm I'm going to local build if I see the gas price being this much or that

much or whatever it is or another way would be to ask the engine give me a value what do you think uh a payload would be worth six seconds now uh I don't like any of the L latter ones so I would keep it simple as it is today and clients that always local build because there are clients that will always want to local build and not use a builder those clients can always uh those clients can always uh not call um to get an envelope right at second zero to get a value you can have a flag in your client that would because you only need to get a payload when

you're about to broadcast which is about six seconds into the slot is that is that all right so basically what you're saying is that uh so in my geta for example I don't want to call any of the builders and I only want to produce locally so the first call I'll do nothing and and uh I'll provide uh I'll basically provide uh a a value with I mean I can provide whatever the header the header can be zero for local building the header is zero it's the value is zero it doesn't really matter the value because it's it's a transfer from the Builder to the

proposer which is both objects are the same both entities are the same right so the local building header can always have a value of zero oh understood so so the the thing the point is that you don't need to call get payload for local building under slot options because you call to get a header and then the header only contains the parent hash the parent block route and this information and the slot this this kind of thing this information that you already have at the vle so so you don't need input from the execution layer if you already know that you're going to locally build and then you can call get payload

later on now I personally think that clients would not Implement a delay here I think for clients validators that want to produce locally built blocks anyways they're not going to be delaying their execution I think they're just going to commit now and broadcast immediately the block and the p and the execution payload envelope together because they guarantee uh inclusion that way so block is now committed at 6 seconds the block is Comm the the the

consensus block is committed at the beginning of the slot ATT tested at 3 seconds and the broadcast of the payload is supposed to be at at about 6 seconds but it can be anytime so if I'm locally building I already know that my blog has my a commitment to myself as a builder so I can broadcast both of them together so basically uh when I'm locally building then you are saying that both my consensus block and payload can be emitted at 3 seconds yes can be

emitted at zer seconds if you want right right unless I mean uh unless execution wants to unless the local block production wants to wait till 6 seconds to get a better payload exactly so you could Implement either way I suspect that clients would go with the easiest which is for local building always commit to a payload immediately at the beginning of the slot you get a value immediately there and you can compare if you wish with other bits or not but it's much simpler to keep it as it is now the the whole thing as it is now uh if you want to update the block

without changing the engine API what you would need to do is call for a payload at the beginning of the slot you would get a value from the and immediately call for for Choice update to the last four Choice update that you did so that you trigger another execution for the same block or you need to change the engine so that it continues building uh on the same block that it already gave you but I don't like those changes because I want to keep it a consensus a consensus PR for the time being right right but I mean these changes are sort of minimal so I mean if I look at ethereum JS I think it should be

easy to modify it to just make sure that the first call it doesn't stop uh stop building and it so we just to add another Endo to get the value reckle I think that is that is something that should be pretty easy to add sorry I got I got disconnected and connected again internet here sucks uh could you repeat this you were you were saying that uh on ethereum GS it's simple to implement this I mean it should be uh simple to implement uh a get value Oracle that does not stop payload uh building and might just give you what what is the current value ah

perfect yeah the Oracle yeah that that would be yeah so my guess is also that for Ys it should be easy to more or less estimate what the current value of a block would be yeah all right so let's move on to the next topic which is relation with Pier Das so we're talking that uh we are basing this on Petra but Pier Das is so already being discussed whether or not it's going to be incture or not and uh in any realistic uh scenario in which we have epbs we will have P Das before or at the

same time uh that means that we need to be careful with how we're going to be merging this once P do is merged in prism we have the following problem which is the fact that most of the code for data availability relies on the fact that the data availability the blocks themselves come with the blocks so they are they don't come exactly with the block but they they're always related to the block they're they're labeled by the block route and um they're expected to be uh so all of the helpers that we write are written in terms of the beon block that that is supposed to be valid or not because of the data availability but epbs changes this because the data

availability is a valid a validity condition not on the Block but on the payload so this is just a warning for clients that are implementing but I only see load star in this call which is a problem uh but anyways this should be in the notes which is if you're implementing uh da eventually you need to be careful in you're implementing PR TK then it would be good if you separate the ga requirements on PR itself on your P Branch to not assume that the data comes with a block so if you could separate this now which is early then it's going to be easier to then rebase CBS on top of p apparently I'm being told that in prison this is not easy to

do I'm not even looking at the pr D coding prism but it seems that it might be a problem to rebase EBS on top of p d yeah just to also provide you the ler perspective it is quite similar in ler also and very tightly coupled with the block so that might need change when we are trying to rebase uh PS repas Ebbs on top of PS yeah uh yeah so that's that's going to be a problem that's going to bite us eventually uh yeah so this was just a warning to to keep this in in mind if you're starting implementing and if

you're also implementing P to try to abstract away the block from the PRD Branch I'm trying to convince the pring deaths to do this all right so the next one which is what I posted on Discord and on Twitter and a bunch of phrases I think that actually that is a killer for Block auctions and I think we might want to switch to slot auctions now instead of rather than later so let me describe again the attack just for the record going to be here uh the attack is as follows is that uh I am a rollup operator uh I win the bid to have a payload so I commit my block hash in the

Bon block and I submit my payload which has all and remember we are committing not only the block has but we are committing the kg commitments as well to I well then I will submit a payload that is invalid later on but early so the PTC that doesn't check for validity nor DA they would attest and give it a boost so my payload would be included uh but it would be immediately rejected by the El that's going to say this payload is invalid so the outcome of this is that I I am a rollup operator

I can collect this PTC votes so I can prove on chain that a block and the blobs for this particular block hash and this particular kcg commitments were available on L1 to most validators so I have the hashes I have the kg commitments and I know I can prove that the data is available or was available at least therefore I can base a roll up on this paying only the bid and not paying the gas that includes the date on L1 so neither The Blob gas nor the data gas no nor the the C data gas and I believe this is a brutal

attack and we don't have a solution to this uh as of this moment uh the solution that was uh uh offered by Lee from Lee bowfield from Arbitron is we could in principle slash the Builder for invalid blocks this is actually not hard to do you could always slash uh the Builder for um the length of this so the the the value that would be committing all of the block as data that means the maximum uh consider the size of the data the size of the block and multiply with that as if it was called Data with the current block uh with the current gas fee and then consider the number of blobs and

multiply that uh for the as if the blocks were available for the block data gas so you could deduct this payment from the Builder if the block is deemed invalid but it comes with a bunch of trade-offs uh you need to keep those invalid blocks this is not so bad but we need to keep them U because you need to prove that they are invalid and uh and then preemptively when you're validating the the bids you need to know that the Builder has enough money to pay in the occasion that his payload is uh is invalid so this makes complication and I think people anyways already uh favor slot auctions over block auctions and Slot auctions are much simpler to implement because we

don't commit to anything we don't need to commit to um we don't need to commit to the kcg commitments in the block and we don't need to commit to the block hash in the block so my proposal at stage would be that I spent a couple of days actually I can have it today even the pr for the consensus uh repo only changing the markdown on the without the testing for slot auctions so we move a slot auctions by default unless there's someone that can actually come up with a better design uh for Block auctions and uh we don't commit to the block hash nor the kcg commitments on the Bon block um we commit to the kcg commitments on the payload envelope well

I mean we update the kcg commitments on envelope uh so I need to think whether or not these are deep changes or not but they seem to be very simple to implement and I could have this PR by today or tomorrow um in addition to well no let's open the discussion with this only I don't know if people have opinion here all right I don't

see oh hello hi yeah hello just a beginner at I just learned um about the PBS and epbs and execution tickets and some other kind of thing related to MVB proposal so U maybe it's kind of like a City question so if you don't mind may I ask what is the difference between um the beacon block and block like what is the difference between the beacon round Beacon proposer and executive around execution block so if you're reading about

APS and this execution tickets um the meaning is different there than here here the meaning is we are separating the consensus block So currently a beon block comes inside with what is known as the execution payload so the beon block inside the body has an execution payload which itself contains the transactions that are sent to the execution layer what we're doing is separating those out of the pon block so we would have two different blocks one that is sent by the proposer that only contains the consensus information and one that is broadcast by the Builder that contains uh the execution information namely the

transactions what we're discussing now is whether or not we want to have in a in a we want to commit to the block hash of the execution in the Bon block or not and I'm hoping to get some feedback on whether it's a good strategy to move to slot auctions now rather than later yeah so my opinion is I I like slot auctions and we should do it now only I mean there is no point doing it trater okay I I actually dislike slot auctions but I think I dislike more the problem that I just found on block

auctions so uh I'll I'll I'll ask round since this meeting doesn't have enough people I'll ask a little bit but I suspect that most people would want anyways to move to slot auctions so I'll work on the pr if you're already implementing this it's not big change for me I I'll take the pr on prism it shouldn't be a big change to move to slot auctions the changes are really minor because you're checking less things so it's just changing a couple of ties and removing the hash and the kcg commitments from the uh from the bom block uh all right so we are only essentially two deaths uh currently arguing this so so perhaps

this is just premature but uh but anyways it seems like reasonable to commit to having the uh the hash not committed nor the kcg commitments another last topic I wanted to discuss is the issue of withdrawals uh this I'll keep as it is today but it would be nice if someone spends time analyzing the dangers of processing the withdrawals in the payload as we do today so today on without epvs the withdrawals are included the payload and we check that they correspond to what the beon state wanted but uh but then we process them out of the

payload onbs this changes on EBS we process them out of the beacon uh State and then we request that the payload fulfills the same uh withdrawals the problem with this is that this needs to commit the withdrawal route to The Beacon State and it's ugly it's much simpler if we actually process them from the payload uh we get a payload we check what is the beon we check is we don't change anything name we we don't check process we don't change process withdrawals and we include the withdrawals on the payload that's easiest possible implementation but it has some semantic changes as to what a withdrawal means because um you may um have many many blocks that are full from

consensus side but empty on the payload side and I haven't done the analysis as to what changes if there's any danger there it would be nice to have someone that actually takes takes it seriously analyzes the situation and checks if leaking or validator leaking or these kind of things or slashings during uh during this period without payloads could affect those uh withdrawals and if there's any danger in moving withdrawals to the payload uh I'll keep it as it is now but I really I'm looking forward to remove the process withdrawals from the from the consensus block and put it back payload that's all I had for today's

meeting we could close early unless someone wants to discuss a little bit more all right so let's call this ajour I'll post the notes shortly because I have them fresh now and ter is not here so I'm going to post the breakout room notes and I'll Circle um the question of whether or not to move to slot auctions immediately all right I'll see you guys in a couple of weeks byebye byebye thank you