ePBS Breakout #6

Transcript

anyways this call should be like just five minutes there's there's actually no updates that we have to give there hasn't been any changes in the spec uh at all which is good because that means that we can actually start coding we we are increasing the speed at implementation in prison uh the EIP I don't remember if I if I was passing already every test but I think I was already two weeks ago uh it's pass passing all existing tests on the consensus side Ethan left some feedback uh I think it's the only one that left feedback so far on the CL spec and I'm going to start pressuring Shia

to merge the one without tests because that's not invasive to have it in the repo uh it's over 3,000 lines the full PR so far and this didn't add any new tests uh what else implementation uh there's this the only issue we found on implementation so far that I'm aware of is what was discussed uh yesterday night that I got an explanation from uh from Misha and from Adrian um the issue is that when when we pass to the engine the new payload we need to pass it together with the parent beon block

route because that's the root that they use for uh for the block rout op code and the problem currently we we have that root because we have the block that included the payload and then we just request from the Block the parent route but on on epbs we don't have a block we only have the execution payload the execution payload envelope so there's two ways out of this we could add both the block root and the p and the parent block rout to the envelope or we could just request from for Choice uh which is what I did in prism ask for Choice hey I have this rout can you give me what is the parent route to to that route I assume that

this is a very cheap check for every client so that's why I went with that because that doesn't require require any spec changes but if this is not immediately cheap for everyone then I'm happy to change that uh that's all for me I don't have anything so I'm open to any comments uh en rco's updates from te and so forth yeah you just men go ahead sorry no I just just mentioned that we uh yeah we are actually organizing to really start working on it which is good

we have um uh since I'm I'm going off I I put on the on the on the desk stepan as well and uh so we can start working together um uh in anyway there will be everyone everyone will be off NE next week so next week will be anyway nothing to work on and uh maybe the week after there will be actual work starting on on table so your comments to burn a beus here so

little background right because to basically to self build that you also need to come up with the value of your local mol and then you compare their value with the Builder's bid and then you choose the highest bid and this is easy with block auction today basically because it's just because it's because it's just in time right and then you basically commit to the contents of the block at that very second but I I think your point is that because in slot auction that by looking at the local man pool G would not have like a very good estimate on what the value will be six seconds later because no one uses local

man pool for example and it's also Al harder for local Mano or local Gest to come out with that estimate versus some other sophisticated Builder is that your point well yeah so the last one is exactly my point the previous one is not really right if no one uses the mol then you know that the current value is going to be the value that you're going to get 6 from now yeah but yeah so that that's yeah that that's right Mar posted my comment on Discord which is something I do dis like about slot auctions it makes the difference between producing a block today and comparing your block against the Builder much worse than uh on block

options I don't know if I totally agree with it I I need to type the answer to just convince myself but I actually think for instance like you don't know how much the block will be in six seconds that's true uh but you have this optionality that you don't have in Block option that's the first thing and the second thing is you might find a good estimator based on the value of your local block at0 second versus the best beid you're getting um from the slot auction at the same time so when see that's already 100x then probably you can tell yourself your local block won't be competitive six seconds from now um yeah but I I I want to type it up just

so that it's clear I didn't understand the first point what what is the the new optionality that you have versus block aution so you can commit to yourself right in a slot auction and then you deliver the Block in six seconds that's not something you can do in a in a block auction like in a block auction you have to if you commit to yourself you have to also commit to the to the block content yeah so is the same yeah yeah exactly exactly so you have like these dat istic value like there's no no Randomness um but at the same time yeah it's

uh yeah I'm just saying like The Benchmark of saying oh this is much worse it's it's a benchmark that seems to be based on the best possible outcome in a in a random world but you don't have a random world when you have block options and so is it fair to compare against this Benchmark I guess would be the the argument is pretty simple the Builder is much more equipped who speing is much more equipped to knowing what their value would be 6 seconds from now than a home Staker that is running vanilla software they can actually do this uh this analysis and a homaker will not be able to do this definitely not on vanilla on vanilla software because we

will not Implement such analysis yeah yeah yeah but so the Builder does this analysis and this is mediated through the bids that they send you in the slot options and so but just by reading the Builder bids you can kind of tell what's their own forecast for instance if a builder bids are one if and your local block is telling you oh currently my value is 0.1 if I think you can tell yourself like if your decision function is oh I want a local build when it's like a bit better then maybe you can oh I see what you're saying I guess you're saying like you don't have a deterministic decisions of my local you can't so what you do today for example would be a strategy today would be if my

bid is 20% less than the than the Builder or with a cap whatever it is but if my is up to 20% less than a builder rather take my bid because I don't I I trusted not to sensor that's that's a possible strategy that validators can do today or or they can do the opposite but we have a flag that does exactly this and right this number uh gets much worse because now if you get a bid that is now 20% less than the Builder 6 seconds from now might actually be 60% less than Builder and you do not know this so to protect you from that if you were betting bidding for 20% less than a builder on slot

auctions you're going to go to 60% less than a builder or whatever it is because this number is going to tend to increase well but the Builder pays you the forecast right right so if they expect to give you one if they will pay you one if now and your value in the local block can only increase over time so that's that's correct but the thing is let's suppose that that I am willing to to get my block if it's worth up to 20% less than the builders on block option this means that if I see a bid for one e and I have my own block is 0.8 e then I would locally

built and that's it it's an easy check nothing else now let's suppose that we go to a slot auction and now I see the exact same situation the the the Builder tells me that they are beating one e right their current block is not valued one e their current block is probably valued less than one e but they are forecasting that it's going to be one e 6 seconds from now no their current block is let's say 0.8 is currently now now my block is 0.8 time 0.8 currently so if it were in a block auction I would accept my block but if since I am in a slot auction and 0.8

time 0.8 is less than 0.8 e which is the 20 the 80% of the current bid from the slot auction then I would not self buil I I don't understand why 0.8 times 0.8 well because the the if we were making a comp comparison I I have today a block which is right now at the beginning of the slot I have a block that is 80% of the Builder block of the Builder block right now so both blocks are the Builder's block is 0.8 e and my block is 0.8 of that right so it's 20% less if we were doing a slot a block auction right now I would take my block

because it's 20% less than the builders but now we're doing a slot auction and the Builder is not beating 0.8 which is the its current value the Builder is building one e because he expects to get that 0.2 extra in the next six seconds and my node is telling me you don't have 0.8 my note is telling me you currently have 0.8 of that so then I reject my current block and I gave it to the Builder yeah yeah but the so when you come to the Builder's bid of one you secure one like regardless of what the value of the block is after six seconds you compare that to the value of

your block which okay let's say at t equal Z is8 times8 that value can only increase over the next six seconds right because you just add more transactions so so that estimation that you get at t equal Z should be like let's say if your model of the world is you're always like 20% away from the Builder that should hold as well at equal six in expect yeah but that's my point that that's exactly my point that now it's true I have a minimum estimation as to what is what I'm losing or a maximum that I'm the minimum estimation is how much is that I'm going to get therefore a maximum estimation of how much I'm losing but these numbers that we just talked about

means that I am now getting my block is not making 80% of the build block I'm not guaranteed of that and I have no way of knowing how much my block is going to increase up to the six seconds uh and I am not a sophisticated player which I and I don't have any meanings to to Computing this right I mean you could say you could still have a local decision rule that says if my current value of the local block is 20% of from the Builder's forecasted value um then I use my local block and and maybe if you want to yeah embed but that means but that means in

the example which you talk now that means that I would only choose my block if my current block right now is the same as the Builder's block right now right the Builder block was to 80% of an e and if I put yeah yeah so the the Builder bit one one e but the Builder's block at that moment was 0.8 so with your rule which is 20% from now I would only accept my block if my block is already beating the builders which is what makes it much worse okay okay I need to write it down just so that I'm I'm clear I I think you can find a decision rule that's not perfect because there is Randomness so

it's never going to be always like perfect forecast but I think you can find something that's reasonable and not stupid but I'll write it down just to convince myself is it fair to say whatever value you determine at second zero uh becomes up opening so the second six will always be higher than second zero but what about transaction can be cancelled I don't think those exist or something does the the for example account abstraction made this property harder uh I guess the build could cancel there yeah the Builder like let's say if

if they are actively extracting the sexex Arbitrage and this the price moves between t equal Z and t equal 6 uh their block value could change negatively you as a local Builder who's just accumulating transaction fees uh like it can only go up right because you let's say at t equal 0 second you have some set of transactions if you find a different set that gives you a worst thing you can always just take the set that you already have for Z seconds so yeah I'm not exactly sure so is there anyone from the e here because I agree with you that in principle this only increases but I'm

not sure how the E decides what's the value that they give you I suspect that they do this statically by Computing the sum of the tips I think they also do it honestly too right they will allow people to cancel transactions yeah I guess yeah the replace by Fe type of thing yeah so the problem is that what Terence is I guess is alluding to is that with a counter abstraction you this Computing might be much much more complicated I I suspect that the

would only just give you the sum of the fees that they compute statically when they they build their block I'm not sure about this number I mean isn't the local block building algorithm just yeah decreasing order of priority fee and then just feel until you done yeah I I think I think so I think that's at least what's get gets is and I I agree with you that if it's this then it has to increase cannot decrease yeah unless you allow for cancellations uh within the duration of tal 0 to t equal to six no not really right because you cancel by a

transaction with a higher fee so by definition if you include that cancellation then you getting higher a higher Fe not necessarily because you could use a lot less gas so you could cancel a transaction that uses like 500k gas with a transaction that you yeah yeah but that's my point I think that the number that the El reports to you is not the actual money that you make it's them statically computed from fees but I'm not really sure so I think the number that the El would give you can only increase because they only statically comput it I feel like they should report to you the numbers of a Blog that's just greedily constructed and then simulated otherwise I this is oh oh you think they do simulate do we have anyone from an

here to to confirm one or the other one I mean you will be totally Gable if so I could speak on behalf of of eum GS so what is the question the question is if if when when you tell us we we call get payload and the engine gives us a payload and the value that you're getting out of that payload is the value simulated from the block or is the value statically computed from fees in the transactions that are included yes so uh for now it is in ethereum JS it is basically the fees that are statically computed but but I think this would depend on upon implementation to implementation how they would want to Value it but yeah as

of now it is fees yeah and I suspect that actually G is also fees I suspect that the the engine never simulates it but I but I I'm not sure what do we want to simulate uh the benefit to the fee recipient yes no no I don't I don't think any of us would be that as of now yeah I suspect that this is uh I I think the mining algorithm is you just order all that are valid and you know because currently before account exraction the minor doesn't need to execute the previous transactions to know that the next transactions are still valid so

they just they know that they can order they know that they can include them because they have a cap on the gas and they know that they could simulate them if they want and I I think they only report the sum of the fees like what you're telling etherum JS does so I think this number can only go up so what would you want to simulate well the thing is that this number is not what you are actually going to get you might get more than this if there are transactions that ex that consume much more gas well you're I'm sorry you might get get less than this because what you're getting is the fee times the maximum gas

that you put the gas limit that you put no but no no so this is uh so as transactions are executed so this uh whatever is credited to the coinbase that is the value that is returned so it should be exact as such in terms of the fees that are credited to the coinbase oh then I don't understand so the so this then simulated you're actually executing the transactions and this this this is in disagreement with what you said before so you're actually executing the transactions and exactly Computing how much gas this transaction actually comput consumed yeah if we have to build a

block it has to has a postate and we have to execute the transactions to get that postate there is no other way around it including fees that need to be given to coinbase okay so the value that you report in the blog is that is how much coinbase got or is it just is how many how much fees the coinbase got not how much value the coinbase got but how much transaction fees the coinbase got okay that's fine that's that's good enough yeah but I don't think there is a world where what you get is different by what you have seen in the engine API call you honest would be very

weird but if uh for example clients are giving you what they're crediting to coinbase it can't be different because then the El consensus will break right because the post state is calculated on the base upon whatever is a final state that includes whatever is paid to the coinbase as a transaction fees okay so so then it is whatever is included in is coinbase getting out of Fe that's that's good enough that's that that number can actually decrease unless uh clients Implement

some other way of evaluating the value but I don't think as of now anyone is doing any other strategy I wrote in the chat a question it does sound so you when you're doing like this local evaluation between your locally built block and what you're getting from the builders it sounds like if you're just naively doing gas limit times the priority fee for instance um yeah I could kind of gain that I could always but that that actually is what happens right with block transactions this is what led to the problem the other day where arbitr was was was complaining that that literally this was

H is what happening like uh some rollups were elevating the the tip but the execution of those transactions was smaller so G was including them in the wrong [Music] order right I guess I have in mind a scenario where I can just always Force the nodes who are doing this local evaluation to pick the local block because I trig them into thinking the local block is very profitable yeah I think that's true well no I'm sorry this this can trick the node into putting the wrong

transaction but what but what gajinder is saying is that you cannot trick the local blog because the reported value of the blog would be the right one so you can Tri the note into putting into including the wrong transaction I see so value would be the right one then you will be simulated and you would get the correct coinbase fees Yeah so basically you say that the you you're sending a local transaction which exceeds gas limit is that what you're saying know that the the transaction has a higher tip but the the maximum gas limit that it has is very high but the actual

consumption is much less for example yes so it doesn't matter so whatever uh so the transaction will be executed and on the basis of that the coinbase will be credited so yeah it should reflect the real thing yeah I was just wondering if this happens before you do the local evaluation between the builders bid and your local look and I'm getting from this that this does happen I think it should happen all right so we are diverting from from

EBS I don't know if there's any other uh any other comments we can probably close early there were some request from barnab to uh spec out slot auctions I made the claim that over the last PR on the cones repo it shouldn't be more than five lines change uh so I'm not sure if we want to do that or not or if there's any value on doing that uh if you guys want to I can just add a new PR with that but it's it's just a feliner probably it's going to fail tests I'm not going to fix the test but the specification should be very simple yeah I think this would be

valuable I don't mean to like air drop work on more people I was saying it more to say oh if there is like a branch somewhere that we can set I can find yeah I I'm happy to think about it though I'm not like super proficient in specking but um yeah I think it would be nice to just have this on the side so that we can point to it when people ask about these differences I'll probably open it uh in the afternoon it should be very simple okay that's amazing thank you does anyone have a question or a feeling about implementation can

probably close this early I just have an update on DSA that we have started working on this ah nice there's a question on the chat compl I didn't understand the question I see you muted yourself abishek but I we cannot hear you or at least I can't

hear you I think abishek might be trying to speak but we cannot hear you all right any other comments all right guys I'll see you in two weeks hopefully we're going to be much more advanced at least on our side see you

guys byebye