ePBS Breakout #19

Transcript

[Music] Okay. Okay. Thank you, Puja. Uh this is going to be a quick call. Uh I posted a link on the chat uh with the simplifications we talked about before. Most of them can be just talked over except for choice doesn't really have any changes but the actual change is on the way that is in the payment mechanism that actually needs to be written somewhere concretely instead of hand waving as I did in that uh document in this hackmd but the the biggest issue is like how do we want to proceed if we were going to push for inclusion of this uh team be

already uh uh posted uh some guidelines as to how to like propose changes uh on the next forks and these guidelines are very loose at the beginning of for proposals. It doesn't really require even to have an EIP. This EIP is like fully specified. There are some minus minor tweaks that are being added except that thing of the payment mechanism that requires Q on the beacon state. uh but the full I mean the implementation I envision that is going to be like slightly changed from what at least prism and tech already have so we already have uh the consensus spec mostly specified except this tweaks u we

already have two clients implementation we already have an EIP so and I don't feel motivated to waste my time on the Python spec given that most of the EF research is clearly against this EIP so I don't I don't think it's worth my time to actually go and working like getting the spec test to pass, getting test vectors out and so forth. On the other hand, if I am told that some client is actually working on this, uh then we do want to have static test vectors at least so that we don't waste our time on interrupt like diagnosing the kind of things that we were diagnosing with Tekku because we were just hashing the wrong objects. it would have been much better if we

actually had static test vectors at least. So there's this uh this balance that I'm not really sure what is the right balance to it. I just don't want to be wasting time on writing specs if I have like this mountain to climb against EF research to propose this change. Uh so if you want if you guys want we can go over what are these changes. Let me just share my screen. Let me just put this in view mode. I think before I How do I do this? Um, let's see. Like this. And now let me just Hi,

hi. Uh, let me just let's see. How do I share? Ah, there we go. Okay, so hopefully this you guys can see this screen. Um, these are the simplifications that we're going to be um that we're going to be changing. Uh, the first one is the PTC changes. This is much easier to implement. Uh, and I think it's a no-brainer. We don't want to be dealing with the complication of like removing bits and so forth. So and no one actually has implemented this fully because we weren't really

considering the attestations on the state. So I think this is going to be easy to to remove just remove all of the payment. Uh keep the PTC commitments the the PTC members the way we are currently taking it from the committee just keeping there uh allow them to attest. Give them uh give them the attestation reward if they attest. Give them the penalty if they don't. and don't do anything for the PTC. The proposer is already anyways encouraged to include this PTC at the stations. And if clients are really like if all major clients are hacking their codes to not attest, then we're going to have to do deal something. But if some

forks appear that are just not attesting for these 512 members that are changing every slot, I think it's just fine. just like complete inter intellectual m masturbation to to give them reward and anyways if we're going to reward them to actually prevent some sort of attack on the PTC because of some for clients then anyways the the reward mechanism has to be very very different because uh one atestation reward is worth any kind of attack anyways so I propose just not worry at all about like rewards for the PTC uh the proposer will include and remove all of the logic of rewarding the PTC attestations.

There is one change. I'm not sure how difficult this is on clients. Uh this is very simple on Prism. So I'm not sure if this is true for every client. Uh which is about the merge view. U if we go with the simplified for choice, there's one thing that we need to change which is your PTC attestations. uh you should not consider any attestation that comes after a threshold let's say 10 seconds I'll post a document later on like in a half an hour about like full timelines if we go with slot reductions I think we can actually pressure this also in EBS but uh but say 10 seconds for the current slot so this this I presume is easy if you're getting

a PTC attestation over the wire you validate it you go zip it but if it's over 10 seconds, you don't import it yourself unless you're the proposer for next block. If you're the proposer for next block, you include all at all PTC in your block. And if you're not, you're not supposed to even consider this PTC at the stations. You're going to consider whatever comes in the block. Um so that's what merge view mechanism is and it's very simple. Port choice doesn't have any change. Uh the only change is remove everything that is about boosts already. purchase deals with the fact that you have empty and and full slots. So it's if you've already implemented this in your fortress that you have if we finalized

uh um if you finalized a few epochs without some payloads then you already have this. The only thing that you need to remove are the payload boost the withholding and the reveal boost and set the proposer boost to back to 40%. Okay, so we get to the actual thing that needs to be written down somewhere which is the payment mechanism because for becomes very simple by removing the boost and just keeping it as it is now but the payment mechanism needs to change. Uh so today we take the money out of the builder and we put it in the execution and we give it to the proposer when we process the payload header. Now instead of doing this we need to like put it in a queue. This Q should have

the proposer index for that block, the beacon block route so that we identify which one is the beacon block route. It needs to have the bid that was that's the amount that was already deducted from the builder and it needs to have an amount which is the total effective balance that attested for that block route. So when you see an attestation on a block for that block route, you just add and it's a new attestation uh you just add the state that you're seeing from this at the station to that que.

So we keep this queue on the beacon state which uh hopefully is going to be empty all of the time. We put this in a queue and when we process the payload, we remove this from the queue and we process immediately. If we process the payload, we just process the payment and we give it to the proposer immediately. So the queue in the happy case is always empty. It's it has one item when you process the execution payload header and is removed immediately because you process the payload immediately. In the unhappy case, you haven't processed the payload.

The payload got reordon state keeps this ceued blocks for which the consensus block was merged was processed but the payload was not processed. So this queue will have again the block route the proposer index the bit that was deducted from the builder and the adjustation stake at epo transition. You go over this queue and you check if the block if the for each element in the queue if the uh if the um if the stake that attested for the block was over um was over 40% then you pay the proposer that bid and if it was less

than 40% then you give it back to the builder. So it's very simple mechanism that is part of epoch transition. Uh we might want to do this uh instead of adding one item we might want to divide in items and then process up to a churn. That kind of complication we're going to do later. And the the idea of having a churn is to prevent the builder from attacking the chain by paying himself. Like you propose a block with an slash validator. you pay yourself like a thousand ETH and then with the builder validator you start attacking the network and then you just transfer all of your money by the end of the epoch and you get slashed but you

haven't lost your money. This kind of attacks might be prevented by adding a turn. I just don't want to complicate the spec at this stage. Um out of that the only structure change that I remember we agreed is to add the slot to the payroll envelope and that's it. Uh so these are the changes and as I said I'm not motivated to write them in the spec. I promised that I would but I don't really feel like and uh that's the situation now. I don't know if anyone wants to comment something. I already opened the thread on the magicians forum to propose this for Glamsterdam and I will post uh what are the implications for slot timings uh in a bit.

I just stop sharing. How do I do this? Can we quickly go over Tim's timeline or if you can like I guess I maybe like if you look at this page that he posted. I guess my main question is like like I assume this is a headliner EIP, right? And like by what date do we know it's going to be in versus we we basically just give up like we go work on something else because I I I I don't is is so is the Yeah. just my for my mental model is a date like July 17 because that says the headline and discussion and finalization is that time so like by July 17 we will know or do you think

this will like continue dragging on for a while type of thing like talk to the EF people I don't know but like I guess another question do we need to be like prepared is there something else we need to do between like May 26 and June It says like there's discussions and proposals is happening like like there's like the post should be focused on that so should be on those codes and stuff like that. I don't know. I think the whole post. Yeah, I do not really understand the post. That's why I'm asking. And then because of that, we need to know. Okay. So, like at some point, do we need to update the SP? We update the SP test, right? Obviously, we

don't want to do that too early like you said. But like, yeah, I don't know. That's just why I'm asking. I don't know. Yeah, I don't know anything about timings. So, that's a status. uh I do not know if we want to invest time in like um I mean if if we are going to work on a second devet to actually have all these changes then I can start implementing this on prism I don't mind working on implementation that's actually something that that gives insight is to into whether or not is uh is difficult or not so I don't mind implementing all of this uh as long as it's still on top of

electraz if we do this on top of fulu it's much much more complicated. Uh um the basting we already like we already presented this on ACD so it's it's fine it's already um we can argue that this was already uh proposed and satisfied. um uh I have just one question because this is something is not on top of my head and I remember I missed a couple of fossil um breakout sessions and the last one that I attended

I think like it was one that you were supposed to present some wrong the time. Yeah. Yeah. So there is always this uh thing in my head that might be wrong that says delayed execution might have some clash with EPBS. Yeah, the LA execution is is a proposal to not include EPBS. They're completely completely independent. They're exclusive. If you include one, no, they're not independent. If you include one, you cannot include the other.

Independent means that yeah, it's exclusive. Mutual exclusive. And if you want to listen how is the implementation of fossil in this meeting is very simple in fossil meeting is slightly more complicated but so there are a lot of complications for delayed execution to be compatible with fossil uh because you're making some validations on the payload and you're testing and the payload is already committed when you attested. So yeah, yeah, remember there there is there's require some require external information that needs to be allowed to validate the the the the fossil set of yeah essentially the the

you might need to like either forbid 7,000 transactions or you need to do some black magic to or to execute part of it to actually check that uh the delegator actually can pay. But on EPBS this is actually very simple. Uh the problem is on the on the timelines that get pushed a little but the the implementation of fossil from the PBS point of view is very simple. What you do is you just simply include in the bid the builder already has the block. So what it does it includes in the bid a bit mask of what are the uh inclusion lists from the inclusion list proposers that he's satisfying.

So then the block already commits to satisfying a bunch of inclusion lists and then the attesters that already have this inclusion list compare this bit mask again. This is part of fossil not part of EPBS. So the testers now don't get the payload. They only get the the block the execution block but the execution block promises them to satisfy a bunch of um a bunch of uh of inclusion lists. So the attesttors now enforce their view of uh the inclusion list mechanism. So they only attest on a block that promises to satisfy the corresponding um the corresponding inclusion lists

and then when you validate the payload if the payload does not satisfy them it's invalid. That doesn't change from from from Fossil. So Fossil already has this mechanism. It's just that now you only invalidate the payload and not the block. The block is still committed. It has a bit mask. It doesn't matter. But the payload is not committed. So that's why fosil is very simple from the point of view of EPBS. Does this clarify your question? Yeah, sure.

Do you need more detail? No, I guess it's so now it's matter of doing some comparison between EPS and delayed execution. in terms of complexity. Yeah, I I I would be very happy if actually people look at this because it's a no-brainer that the late execution is much more complex. It's just like an entire different game. So, as long as more people are actually looking on this, it's obvious the difference. That's a missing point that probably is the is required to actually then steer the cords to one place or the other. I'd be happy if people actually start

looking at this because it's obvious. Uh the the complexity of the late execution is just orders of magnitude worse. The the argument is that it doesn't touch for choice but the for choice changes are minimal. The the big changes is on the engine API which is the biggest problem. This is where all the bugs are. Yeah, we should take a look closer look definitely. uh so the main two differences with delayed execution I mean the main two points in which EPBS is much better well the first is much less complex fosil is immediate um and it doesn't involve the eel you just do

this completely on the on the CL side you can actually test it only on the CL side and the other the other big difference is in broadcasting delayed execution does not allow you to remove the payload and the blobs from the hot path have which is the scaling property that we want. We want to have be able to broadcast blobs more blobs and larger blobs and don't care about the time nor the bandwidth to broadcast them. So delayed execution allows you to execute later but it doesn't allow you to not get the payload and the blobs before the attestation deadline.

So that those are the main two points. All right. So I didn't want to take too much time. Uh I just wanted to inform this that I mean this is out there. This document is there. I don't really want to work on this spec. If you guys tell me that you're going to continue working on an implementation, then I'll start and just actually change the implementation of Prism and have it ready so that we can actually interrupt again. Otherwise, I'm happy to just put this on the freezer until there's a decision on ACD, but I don't want to waste more time.

I'm not even coming to ACD actually. So, so are there other clients interested in I don't really know. So, Nimbus told me that they had people working on them, but then they never I've looked at the branch and I haven't seen any push in that branch and loadar expressed this concern about like a field disappearing from the from the state that that would from the block and that would be a problem for them. But again, there wasn't any commitment to even start working on this. So, I don't know. I haven't been contacted by any team.

Yeah, I mean makes sense to to freeze uh also because there are no much progress on the other clients. Mhm. The only thing that makes on the technical side you mentioned that the the the coupling between at the station and PCT PTC. So, you're kind of removing the the um the rewards based on on on the action.

And I was thinking um yeah I don't like generally speaking having some duties that doesn't have any I I understand just like saying yeah it's but on the other hand the attack surface is such that I mean if there will be an attack because some clients will just decide okay I don't care about this I'm not going to send this PTC to the stations. And let's suppose that this happens and this is generalized and you want to prevent it because this is a malicious behavior.

If it may if it starts happening immediately from one slot to another from all from the whole network which is an edge case obviously is we start not having PCT anymore. And the consequences of these. So the consequence of not having PC means that the next proposal can actually reorder the payload. If he wants, he can reord the payload. So it's is a the protection the builder protection goes away somehow.

Yes, because uh the that's correct. The the payload wasn't there. So if the proposer decides to reorgget then the the block was heavily attested and then the payload will follow the the reorg one without having any any any reason to not do that. Exactly. So if malicious behavior like this arises then a and and you think that it can be prevented by actually giving rewards to the PTC then you need to give it much more reward than just a single attestation and then we're in this situation where these 512 members that are changing

every single slot need to get a lot of rewards. Yeah. Yeah. And then this is even worse than any any kind of UX for any validator. So I think it's just better not to give any sort of reward for the sync committee was different because the sync committee is something that requires uh hooking into a particular network in a particular subnet. It requires you to uh to to to register in advance. You you're you're there in that committee for over a day and so forth. But this thing is only one slot and it's on a global topic. So it doesn't really require you to do anything.

Yeah, you're not you're not um um wasting so so many resources by doing that essentially. You you already need to be listening to the payload anyways for the payload anyways. Exactly. Yeah, I see. I see the argument. So, so I I think it's just adding complication is just useless. I I did add it originally because uh people were complaining that that this would be without uh some some some and and other sync committee situation but I think it's just much cleaner not to have any rewards and also allow the the thing to attest

because removing it from the attestation committee was was the biggest problem. Yeah. complication of separating the two sets excluding a subset of the attestation. So that all the that code path goes away. Yeah, all of this goes away. It's much simpler. Just keep the attestation as it is. Just take out the commit the PTC the way we do. Yeah, in terms of simplicity makes total sense. Uh the theoretical thing that you have to do something without any even if the that something is essentially not that um heavy from what you have to do is anyway something that could be argued against.

Yeah. I mean anyways if there if we come to that sort of argument it doesn't matter because that's that's easy to change. Uh I think the biggest problem here is going to be that we're up to against a mountain which is uh delayed execution itself. Uh which is mesmerizing to me. I I I just honestly don't don't really understand what what are the forces behind this. All right. Okay. So then I I'll I'll keep it as this. I'm not going to work on anything.

If I work on anything on EPBS, it's going to be on the prison side on implementing this and if I have time and will at some point I'll just update the spec, but I don't even promise that. Okay. No other comments, no questions. Stefan opened his m but then he closed it. Oh, no. I don't have any. Okay. All right, guys. See you next time.

Bye, guys. Bye. Wow.

Jesus. Heat. Heat. Heat.