Potuz:Alright, perfect, thanks.
Transcript
Potuz:Welcome to… I don't really know which number it is, let's see… it is…
Potuz:Phone call number 21, the breakout for EPBS number 21.
Potuz:We have some few items in the agenda, some are actually… might actually be complicated, so… so let's start with the easiest ones.
Potuz:The ones that are already merged. We, are going to sample PTC
Potuz:by stake, so proportional to the stake that they have. The original, sampling that we implemented first was just simply counting, taking a number of validators from the, from the Beacon Committee, that, was rightly so pointed that it was, not compatible with MaxCB.
Potuz:And now we're sampling it by stake. I think this has already been merged, it was a PR by Francesco.
Potuz:But we still will count the votes individually. So, you are selected or not to participate according to your stake, but when you vote, your vote counts as 1, and the threshold, we still have it currently at 50%.
Potuz:I don't know if this might change for DA, we might use a different number for DA, or still use 50% for DA, but once we revise the Fulu, and we count, and we add
Potuz:the DA presence on the PTC at the station, we might have, like, independent thresholds even on this side.
Potuz:I don't know if anyone has a comment on this.
Potuz:Okay, good. So, let's move on to the next item. Okay, so this is something that Francesco brought up.
Potuz:Which is whether or not to commit the state route in the payload envelope.
Potuz:So there's two problems here.
Potuz:One is the fact that… well, there is a commitment for a state route that might not be useful, and I'm happy to remove that. But then there's a broader, question, which is whether or not we want to commit to the full envelope or not.
Potuz:And, yeah, so Francesco is here. He was arguing to commit to the full envelope. I don't know if you want to mention this, or if someone else has a comment about this.
Francesco:Yeah, I mean, I could just briefly say, I don't know, I don't have any, like, super deep reason to say that I think we should do this, it's mostly just, …
Francesco:if there's no reason not to commit to the envelope, I'd rather do it so that there's no question that,
Francesco:there's only gonna be a single envelope, and you can just check that against the commitment. There's no ability for the builder to inject, like, multiple envelopes.
Francesco:that's basically it. Then yeah, if, I can see that
Francesco:in the future, we might move away from, even being able to commit to the envelope, so maybe it doesn't make sense to try to start with that. Like, it might be that… I mean, it seems to me like in the first version of PPS, it should be possible to commit to the envelope, but…
Francesco:Maybe it doesn't make sense to try to have this kind of guarantee if we're gonna probably lose it in the future.
Francesco:… So yeah, that's it.
Potuz:Right. … Does anyone else have a feeling about this?
Potuz:Oh, Barnabas is here! Wow, we're getting serious.
Potuz:Okay, so I can… I mean, my opinion on the topic is that we definitely will not commit to the envelope in the future.
Potuz:We are hoping We couldn't clear out slot auctions, which is an issue.
Bruno Mazorra:And….
Potuz:Committing to the envelope is what's causing the current problem that we have with the…
Potuz:with a free option problem. So, if we ever find a way of actually not committing at all to the envelope, that would be good.
Potuz:Having said, so, I do agree that there's no strong reason to actually do a state transition and agree on the state route.
Potuz:So I don't mind removing the…
Potuz:The… the state route from here.
Potuz:I don't know if anyone has an argument as to why the state route was there. I just added it.
Potuz:Because…
Potuz:That's something we do whenever we change the state in consensus, and I just wanted to repeat what the state transition function is for consensus and the payload, but I don't see any strong argument as to why we need to have the state route.
Potuz:in the end, I mean, committed, and computed, and checked against, we can remove that assert.
Potuz:But I don't think we should commit to the payload, and it's just because of that argument, that if we ever find a way of not committing, we want to use it, and I'm not sure how easy it would be to remove that commitment.
Potuz:Once we have it. Like, it's… it's code that we hope we… we can remove it, and it's… if it's easier not to change it in the future, that's gonna be better not to have it now, not to change it now.
Potuz:Yes, so Francesco's, yes, pointing out correctly that,
Potuz:that, yes, the builder would need to be, to be computing the state route on the CL, on the critical path, and it's… it's a non-trivial commitment, and I'm told that any millisecond actually counts. So I do agree with that, with this.
Potuz:So I would propose to remove the state route, remove that assertion, unless someone figures out that it's actually needed.
Potuz:But I would prefer if we don't commit to the payload for now, until we realize, at least until we evaluate whether or not it's going to be trivial or not, removing that commitment later on.
Potuz:Right, I don't see any pushbacks, nor…
Potuz:Alright, so I don't see any pushbacks, nor… in favor, and I'm…
Potuz:I shouldn't be a moderator here, because I'm very biased on the topic, so… but anyways, …
Potuz:I'll ask to have another moderator in the future.
Potuz:in future meetings, but I think it seems reasonable to me to, to remove that commitment… this statement, remove the commitment to the state route, and…
Potuz:Keep the commitment… keep the commitment to the hash and not the full pay envelope for a while, at least, until we figure it out.
Potuz:If it's trivial or not to remove it.
Potuz:Alright.
Potuz:So, the next topic
Potuz:Let me skip it for now, because we need to have… I mean, I forced Francesco to be here, so let's, let's ask him to explain the changes to Proposal Boost.
Potuz:…
Potuz:which is to better handle electrification, and this is something that we want to port even to Phase 0, if I understand correctly, and it's independent of EPVS, although it's going to be better to have it on EPVS, …
Potuz:So, I'll give the floor to Francesco to explain these changes.
Francesco:Okay, yeah, maybe let me share screen…
Francesco:onto them…
Francesco:Yeah, so, first of all, yeah, do you see the, this VS Code thing?
Potuz:I conceive well.
Francesco:Okay, so one thing is sort of independent of… … EPVS, and it's…
Francesco:this one? So, I mean, yeah, this is just to help permit to update Proposal Boost Fruit, which would have happened otherwise here.
Francesco:And the new thing is basically, you don't just check if, a block is timely and, is the first block, before updating proposer, boost route. You also…
Francesco:basically check if the proposer is the one that… so this part, you only update if the proposer is the same as on the canonical chain.
Francesco:So yeah, you basically just, like, get your head state updated up to the current slot, and then check if the Proposer Index is the right one. To me, this seems just, like, basically a bug with ProposerBoost. Like, it basically allows that someone comes in with whatever block from some…
Francesco:forgotten branch, and, I mean, it has to be, like, descending from the finalized, but still, it can be done, and it can have a completely different proposer sequence, and it just forces you to update your proposer boost, and then you're not gonna update it for a real block.
Francesco:Of the actual proposer, like, as long as this block comes first.
Francesco:So, yeah, this…
Francesco:again, completely independently of EPVS, and this is why it's in Phase 0, seems to me just like a pure, like, proposer boost bug that we should fix. I don't have an opinion exactly on when this should be fixed, …
Francesco:I mean, I think it's… it's…
Francesco:not nice, like, in principle, it is pretty easy to exploit, …
Francesco:it's not, like, the end of the world, because, you know, exploiting it by itself kind of doesn't really do anything. To, like, exploit it meaningfully. You need to also be doing the kind of things that Proposal Boost is meant to prevent.
Francesco:But it's also not… yeah, like, it's… it's…
Francesco:I think it's a meaningful problem, like, if you control a validator and are able to do this, like, if you manage to have
Francesco:control a certain slot, and also manage to control, like, a fictional proposer for the following slot, which I think should be easy if you just,
Francesco:grind some kind of, grind assignments on some made-up branch, then you can basically do, like, an exanta reorg, like, you just essentially deactivate RoserBoost.
Francesco:So I, I, yeah, I think it would be better to fix it, like, sooner rather than later. I don't know in terms of, …
Francesco:you know, if this needs a coordinated, release, or if it can just be independently done. I don't know, last time that there was a proposal boost… I mean, one proposer boost was introduced without a coordinator release.
Francesco:a whole mess happened, so, you know, maybe we should just do a coordinates release, in which case, I don't know. I am not sure what's the earliest point that makes sense. Maybe, the first VPO after Fusaka, like, … the first VPO that is not scheduled with Fusaka might…
Francesco:Makes sense. But anyway, so this is one thing, and again, it's not super related to EPBS.
Francesco:And then other things, about the handling of… Proposal boosts and equivocations, here. So…
Francesco:the kind of point, is to… yeah, I'll show you what, but let me first say, I guess, what is the point? The point is basically
Francesco:to defend against the… actually, yeah, maybe before going forward with this, let's just pause for a second, and I don't know if anyone has comments about the proposer boost update, let's first talk about that.
Francesco:Like, the, the, you know, initial privilege update.
Potuz:So, Francesco, I can point that… so, as I was saying in the chat, in Prism, we are subject to this bug.
Potuz:But I think it can only be triggered, not by a random proposal. I got worried when I first heard about this, because in principle, anyone can actually just grind and see, well, if I build a block on top of this other very old block.
Potuz:And I imagine that there was such a branch, then I would, …
Potuz:Then I would be the proposer now, and I just propose, and notes would sync it. So if we're finalizing, of course, it doesn't happen, but if we're not finalizing, this in principle can happen.
Potuz:But I think Prism will not even attempt to sync such a block.
Potuz:So… so we aren't subject to such a thing, but if we are forked, yes, then we… this can be exploited for us.
Francesco:And why would you ignore, such a blog?
Potuz:This was an issue that when we were being dossed by these blocks.
Potuz:I think it proved that we can ignore them on gossip, but request them and sync them if we request such a block. So if we sync a child… if we see a child for such a block, we would sync it immediately.
Francesco:Or do you….
Potuz:Or an adaptation, exactly. So if we see anything that refers to such a block, we would immediately sync it, because we keep those blocks.
Potuz:But if it's just coming out of nowhere from gossip, we would just hold them.
Francesco:Okay, but then, I mean, if it is actually an attack, then someone can just attest to the block, and then… Yeah, that's.
Potuz:Yes, but that, yeah, the question is not to prevent from attacks, but to prevent from bugs. So clients that are buggy, typically they just randomly submit a block on top of a very old head that they had, because they were struggling.
Francesco:Okay, so I see… but yeah, I mean, just to clarify, I would… I mostly be…
Francesco:worry about this as an attack vector. I mean, not, like, not overly worried, but yeah, …
Francesco:But, yeah, it would definitely be good to be sure that it's not something that can accidentally cause problems, because that probably would be even worse.
Francesco:But I guess, you know, it hasn't caused problems for years. Well, maybe we don't know, but allegedly.
Francesco:But anyway, I see Justin is saying, ideally, would we fix it for Saka? Yeah, I mean, I guess it's just…
Francesco:… I don't know how people feel about
Francesco:making this change, before Fusaka releases. I also don't have a good understanding of, like, how
Francesco:you know, simple it is for people to do this. I mean, I would assume it is simple, like, clients, I guess, do already, like, would know what this proposer is, like this, …
Francesco:…
Francesco:kind of expected proposal for the head state. I would assume clients already have that, so I would assume it's quite simple.
Francesco:….
Potuz:Yeah, the fix is just a couple of lines for us. We have the… we have the full state, so it's very trivial.
Francesco:Okay, so anyway, I don't want to hijack this call with this too much, since it's actually not really about EPBS, so yeah, I guess now that people are aware, we can then discuss maybe offline.
Francesco:Okay, so then, yeah, for the rest, …
Francesco:And now let's go back here, so there's a few things.
Francesco:One is this, … We'll actually go here… where's the store?
Francesco:Yeah, so I'm kind of interchanging this block timeliness thing, which is, also used as part of the browser boost.
Francesco:to record if something has come on time, to kind of have now two deadlines. One deadline would be the same as before, and then the new deadline would be the PTC deadline. Yeah, this is just basically recording whether… whether something came… whether a block came before the…
Francesco:PTC deadline. And the point of that is that we basically want to treat,
Francesco:early equivocations in, like, a particular way. So the whole thing is about, yeah, what we do with equivocations, and the kind of case that we're worried about is,
Francesco:Mmm, basically when, … Equivocations show up, late.
Francesco:So they… they can, in principle, get a… trick the builder to release. Like, everything looks fine for the builder, the builder releases, but an equivocation shows up late, and then Proposer Boost is used
Francesco:to, try to actually get the equivocating block to become canonical. So, like, basically, if you think about the rule that we have for builders to release, the rule is release if
Francesco:40%… you see 40% of the weight. I mean, then, I don't know, builders might do something different, but at least this is the rule that's supposed to kind of ensure that builders have all the nice properties, and it fails in this specific way. I think it's the only way in which it fails.
Francesco:Which is, like, yeah, you could see 40% of the weight. That feels like it prevents you from being reorged through
Francesco:proposer boost, but then actually an equivocating block shows up, and now the, kind of, next proposer can anchor on that block with their proposer boost, and then sprinkle in on top of that some weight, and still reorge. So that's basically the annoying case.
Francesco:And, okay, there's a few things that go into trying to fix this. That's from pretty0. So, one thing is, in Get ProposerHead, there is now,
Francesco:this, proposed revocation, check, where you basically figure out, If the…
Francesco:the block in question is equivocation, just, like, there's two blocks from the same proposer, and then in that case, you have more lenient conditions to be doing the reorg. So, like, you know, these are all the conditions that you normally would check to do a proposer boost reorg, whereas
Francesco:You would do it, …
Francesco:just with this, like, basically just if the head is weak, and it's the right time. Like, as long… whenever you see, like, a weak equivocation, you basically aggressively try to reorg it.
Francesco:… So this is for, kind of, to establish, like, an honest, reorgan behavior that's supposed to,
Francesco:Like, it was establishing that the honest behavior is not to extend, weak equivocations, essentially.
Francesco:And then… so, yeah, that's one thing. Once we have this, then we can also change the testing behavior in such a way that,
Francesco:basically, if the proposer violates this rule, it can essentially guess is punished, like, the testers will try not to attest to proposers that appear not to have followed this rule, essentially. And, yeah, so this would go…
Francesco:here… yeah, go ahead.
Potuz:So… so… so you want to… the attesters for the next lot would check if there is a reorg of a week ahead, but they didn't see an equivocation, then they would just check the other, the other statements if… if they were all true, and if some of them weren't true, then you wouldn't attest for this?
Francesco:I mean, maybe just, like…
Francesco:Let me, let me just go through this, like, should apply proposer boost, and then it should be clear what the testers are supposed to do. Yeah, but yeah, this is what the proposer is supposed to do, it's, it's like…
Francesco:basically just boils down to reorg weekly heads, so that's meant to be, like, the honest proposer behavior. So what are testers supposed to do? Yeah, this should apply proposer boost, it just goes into, into get weight here, so it's, it's, you kind of update the proposer boost independently of all of this, but then you only apply it based on, on this function, once it comes to actually computing the, the, the fourth choice.
Francesco:So, yeah, basically, …
Francesco:everything up here is… I mean, yeah, so this was the only… the only thing that you had before, and then there's… there's all this kind of stuff that's added.
Francesco:So, you always apply it if the parent is not from the previous slot. This is basically because the…
Francesco:attack that we're concerned with is just, for, for the purpose of,
Francesco:you know, this builder kind of good properties, is when the, yeah, the parent block is just from the previous slot. …
Francesco:And, yeah, if the parent is, not weak, you always apply it, so it's only, kind of, weak, blocks that you, you might…
Francesco:take a second look at. If a block is not weak, meaning it has more than 20% of the weight, you just always apply it, just like before. And then this is basically the only part that's actually different. If something is from the previous slot and weak.
Francesco:And there are equivocations.
Francesco:accept everything, and there are equipped locations, then… so, yeah, basically, you only apply it if there are antiquity locations. If there are equations, you don't apply for rosor Boost in this case. So it's basically saying, okay, imagine that there is, like.
Francesco:a strong block, or, like, a not weak block, A, and then a weak block B from the last slot.
Francesco:attesters will only be able to apply a proposer boost to A, the one that's not weak. They will not apply proposer boost to B, so if, like, something shows up out of nowhere, it's an equivalocation and it's weak, that one is…
Francesco:cannot be chosen by the proposer. Or, like, the proposer can't choose it, they're not supposed to, like, this is saying, don't choose it, because it's weak and it's in publication.
Francesco:But if they do choose it, it doesn't get proposal used, so that's basically the point. Like, when you do have such a situation with multiple equations.
Francesco:the… the proposer is kind of, not supposed to choose any weak one, and if they do… if they do, they don't get the support of the testers, or at least of proposer boost. Yes?
Potuz:So… so in principle, it doesn't force them, but I think it would
Potuz:likely force clients to use this honest reorg feature.
Francesco:There are some clients that are not using Get ProposerHead.
Francesco:Yeah, this is meant to not be optional, anymore.
Francesco:Yeah, so, yeah, I mean, okay, no, this is suggesting things about the order. Yeah, I don't know where it says that this is… whether this is optional or not, but yeah, it's not supposed to be optional. …
Francesco:Which, I mean, I think we.
Potuz:We have Stefan here. Did Teku implement this? Because there's a few clients… I thought Teku, for example, did not implement this.
Stefan Bratanov:I'm pretty sure we implemented this, but I have to double-check it.
Francesco:But yeah, I mean, I think you're right that not all clients implement to the release, I don't know which do. But anyway, I… I mean, I always thought that this would need to become, non-optional, because, for example, right now, that's how Fossil is supposed to work as well.
Francesco:I mean, even there, it's, like, would be fine to be auctioned as long as, like.
Francesco:There's enough people that are doing this, so that it's not, like, an empty thread, but it's…
Francesco:Yeah, even in that case, it feels like some… like, every honest validator should be trying to enforce the inclusion list, and they would be doing it this way.
Francesco:…
Francesco:yeah, I mean, you could have different conditions for that specifically, but anyway, I don't know, I think it would be best to have this not be optional, and yeah, for this case, I think it would be necessary, because otherwise, I think you can probably…
Francesco:…
Francesco:screw the proposer, like, if they're not doing this expected thing, and they kind of just choose whichever of the…
Francesco:Of the two.
Francesco:It might… yeah, not sure, but I think this might… this might be, like, an attack vector… vector against the proposer.
Francesco:Oh, and yeah, I mean, here, there's this block timeliness thing that I was mentioning. It's just you only consider early equivocations, specifically to protect the proposer. So, like, here you're trying to get all the equivocations for… for the previous slot, or, like, equivocations that,
Francesco:kind of coincide with the parent, like, from the same proposer, etc. And you only consider the early ones, such that the proposer is supposed to have seen them. Like, you don't want to consider blocks that you just got, like, very late, because then the proposer would not have had a chance to see them.
Francesco:So that's why we need that timeliness thing.
Francesco:Mmm…
Francesco:this is basically most of it, but yeah, I know it's not super, like, it's also not super easy to explain, so I don't know. I guess, yeah, if people have questions, …
Francesco:Yeah, I don't know. If there's something that's unclear, tell me, I can try to re-explain it, or if you have a question, or… I don't know, we can also move on and do whatever else the call wants to cover, and then we can talk about this async.
Potuz:It sounds incredibly simple and reasonable to me, but it's… and it's very simple because we already have.
Francesco:everything here implemented. I'm not sure how simple it would be.
Potuz:for clients that don't implement the honest reorg, because that was not trivial for us to implement. So once we set up the Honest Reorg feature.
Potuz:implementing this is trivial. Although, even if you don't have the honest rear feature, I think the changes to Proposal Boost should also be trivial to implement for clients.
Potuz:I mean, not the… not the get proposer head, but the changes to Proposal Boost itself should be very simple, too.
Potuz:to implement.
Potuz:So, the plan is that you'll open a PR,
Potuz:for EPBS with this, and that PR will backport it to Phase 0. I mean, the other part would be backported to phase 0.
Francesco:Yeah, I mean, I guess maybe I would separate, the first thing that I was talking about, the…
Francesco:sort of bug fix for ProposerBoost, so I'll maybe open a PR for that independently.
Francesco:But I don't know. I definitely would like to hear more input on, like, what people want to do with this, when. And then, yeah, I can open a PR for the rest of it. I guess I'll wait for the rebase, probably, to be done.
Justin Traglia:If you, backport that fix to Phase 0, how will you pretty much tell clients to coordinate on the fix for, like, Fusaka or BPO?
Justin Traglia:1.
Justin Traglia:Do you have any ideas?
Potuz:we coordinated this thing? I mean, is it really exploitable in any way?
Justin Traglia:I don't know.
Francesco:I mean, I… do you mean exploitable specifically if it's not coordinated? ….
Potuz:Right, so if some clients ship it and some clients don't, and then we're gonna see validators trying to slash themselves by equivocating, and… it's kind of weird.
Francesco:I mean, I don't know if… yeah, not sure, it's not obvious, but, like, when we did ship Proposal Boost, there was that whole, like, 7-block reorg caused by Proposal Boost being, like, 50%.
Potuz:….
Francesco:So, I don't know, that's, I mean, that would be my apprehension, that, yeah, if, like, I mean, that was, I think, like, a fairly unlucky thing as well, but, ….
Justin Traglia:If… if it does need to be coordinated, I would think it might need to go in, like, the Fulu specs, and then after Fulu, we can backport it to Phase 0. But, ….
Francesco:Okay, right.
Justin Traglia:I'm not entirely sure. I'd have to think about this.
Francesco:Yeah, I… I don't know how to determine if it needs to be coordinated, to be honest.
Francesco:yeah, I think given that maybe there isn't, like, you know, it probably doesn't make a difference to do it in a month versus, like, whenever food ships, maybe it might as well be coordinated if people are okay with that, but….
Justin Traglia:Yeah, I mean, it seems pretty simple, and if it's a bug fix, it's important.
Justin Traglia:Yeah, and easy to be coordinated.
Potuz:Alright, is there any other comments on this?
Potuz:All right, great. Thanks, Francesco.
Potuz:We have a couple of more items. One is very simple, too, so let's go with the simplest ones first.
Potuz:Enforcing non-zero bids for builders that are not self-building. So, for blocks that are not self-building.
Potuz:…
Potuz:I can see one reason why to do this, and it also, like, simplifies other parts of code, and the reason is that when… when we have a blog that is not self-building.
Potuz:then we generate… we make changes on the state. We add… first, when you sync a block, we add a pending payment to the beacon state.
Potuz:And then when we sync the payload, we add a withdrawal. We take that pending pay… payment, and we add a withdrawal in the beacon stage. And it'd be very awkward to have these things with value zero.
Potuz:… Adjusting, we're clearly rejecting zero-value bits in relays.
Potuz:Yes, correct. Yes, there are no zero-value bits, and we're going to reject zero-value bits anyways over P2P as well.
Potuz:The thing with having zero-value bids is that it could be useful for people that want to go off-protocol, and there's an argument to be made of, like, actively keeping support for off-protocol bids. It's not something that I would be happy to support on Prism, but some other clients might want to support blind signing.
Potuz:And I'm not sure if it's useful for them to have this. So, there is an argument of, like, having zero value bids to go off protocol and receive the payment off protocol.
Potuz:So…
Potuz:Yeah, I don't know. I don't know if there's a pushback into enforcing that this value is non-zero. Otherwise, I would like to, like, remove
Potuz:Add paths to not add value zero operations, like pending payments with value zero and withdrawals with value 0.
Potuz:Of course, it's kind of silly, because you can still add these things with one way, and that's it.
Potuz:But… anyways.
Potuz:Like, asserting it to be non-zero is just one line.
Justin Traglia:I'm in favor of the assert.
Potuz:it makes tests… so this appeared because of Terrence's PR for tests, and it makes tests much easier to think about. It makes tests more robust.
Potuz:Yes, that comment, yeah, that's correct. If you want to go off protocol anyways, you can do it with one way, I just…
Potuz:It was just an issue of, like, … Yeah, making their life easier.
Potuz:But if no one… if no one is against, asserting that the bid is non-zero.
Potuz:That's something I would prefer as well.
Francesco:So, this is just for non-self-building, right?
Potuz:Yes, self-building needs to be zero. Self-building is important that it is zero.
Francesco:Okay, then, like, if you want to go out of protocol, you can also just have the proposer just pretend to self-build, so I think it's not….
Potuz:Yes, so that was my way of going off protocol. That was my proposal, that you keep it exactly the same as it is now with MapBoost, and then the proposer signs everything.
Potuz:But then, Mark came with a… with a system for… that… that would be good to have, like, different signatures.
Potuz:… Have the relay sign the payload and the envelope, and then have the proposer sign the consensus block.
Francesco:Okay, then I guess, I don't know, it's a question of, do we care about that, plus not needing to…
Francesco:be a builder, as whoever is on the other side of this. So, like, you maybe… I don't know, maybe you could do it in a way where you don't even need to…
Francesco:Yeah, I don't know. I don't know. I mean, it seems like if you have to be a builder anyway, then yeah, you could just submit, like, a really small bid, and it doesn't make a difference. Like, it would only be useful if you could actually not even be a builder.
Potuz:Yeah, but then, yeah, so if… that would break staking pool. So we don't want to take bids from things that are not builders.
Francesco:Okay, then I think you… yeah, it's… I don't know, I don't see any reason not to just enforce greater than zero.
Potuz:Alright?
Potuz:So those were the easy ones.
Potuz:Let's go to the two. There's one which is about, asymmetric payments for the free option problem. I see Bruno is here.
Potuz:Let me just mention quickly what, what this would be.
Potuz:The idea would be to somehow penalize builders that don't …
Potuz:penalized asymmetrically. Builders that, don't get their payload included. So if you… if you… you bid for, say, 5, and your payload is included, then, well, you pay 5, but if your payload is not included, then you would pay something different.
Potuz:And, probably 7, something like this.
Potuz:Now, there's reasons to do this, which have to do with this free option problem, to try to penalize withholding the payload.
Potuz:But it's… I think it's too early to find out exactly what sort of asymmetric payment do we want.
Potuz:I just wanted to point out that it is very simple to implement one way of asymmetric payments, would be to
Potuz:return part of the bid to the builder when we process the payload. So if the bid is for, like, say, 10,
Potuz:Then, we put a pending payment for 10, because anyways, there's no money being taken out of the balance from the builder at that stage.
Potuz:We put a payment… a pending payment for 10, and when we process the payload, we… anyways, we remove that pending payment when we process the payload immediately, but then, instead of transferring the withdrawal for 10 to the proposer, we transfer a withdrawal for 7, for example.
Potuz:In that way, the proposer gets 7 out of 10 when the payload is, … is, …
Potuz:well, it's included, and it gets 10 when the payload is not included. So this would make it more expensive to bid for the option, to exercise the option and not proposing.
Potuz:So the option is there to have this, but I think it's just too early to figure out a way, an effective way, of knowing what function should it be.
Potuz:Should it be a function of the… a percentage of the bid? It should be quadratic on the bid, it should be something on… a function of the bid that we do not know yet. I think we need to experiment more.
Potuz:And know exactly the extents of these problems, of the… of the free option problem, also know…
Potuz:what are going to be the timelines of the PTC commitment to committed so that the deadlines also determine how likely this option is to be exercised. So I think we should eventually do something about this, but probably
Potuz:after we have better numbers on… on what the timelines are going to be for deadlines? I'm not sure. Perhaps Bruno can say something about this?
Bruno Mazorra:Yeah, yeah, sure. I mean, of course, it's too early to say, right? We are doing some internal experiments right now with the data we have.
Bruno Mazorra:And yeah, one of the questions you had… a very interesting question you had in the previous meeting, essentially, was how pegged is the option value to the
Bruno Mazorra:… value of the block. And right now, what we see, it's, like.
Bruno Mazorra:not even, like, it's not very related, it's, like, has a lot of variance, no correlation at all, or mostly not correlation.
Bruno Mazorra:And so we… right now, but very preliminary conclusions, is that, just, …
Bruno Mazorra:The slash… the penalty to be some proportion of the bid wouldn't be that useful.
Bruno Mazorra:Of course, that's biased to the data we have right now, so… yeah. …
Bruno Mazorra:Other things that we could do is, like, or we mentioned in previous calls, is do something that it's… it depends on previous rounds, and depends on previous information. Also, for example, we could have a target, right? A target of, like.
Bruno Mazorra:when the off-free option is not used. Let's say 99.9% of the times, the free option shouldn't be used, that should be a target. If it's 0.1%, it's not that bad.
Bruno Mazorra:And we did this target trying to have the minimal slashing possible… minimal penalty possible. Why we like that? Because the smaller the penalty, the more… the lower the barriers to entry, right? That's for builders, and also the bids will be more competitive, because it wouldn't be budget constrained.
Bruno Mazorra:So I think that's…
Bruno Mazorra:research direction that we are currently doing, but yeah, everything is very in preliminary stage. We cannot have conclusions right now on what to implement or not.
Bruno Mazorra:But yeah.
Bruno Mazorra:That's more or less the summary.
Potuz:Thanks.
Potuz:I just want to mention that even if we don't go with a proportion of the bid, like, having, for example.
Potuz:said that you want to have a function that looks like 5-way, or 5 ETH plus 10% of the bid, then the way we would… we could implement such a thing, such a function would be… we enforce that the bid is at least 5 ETH.
Potuz:and then we just return to the builder, we return 5 ETH minus the whatever percentage is, and then we get that sort of, like, linear function.
Potuz:So I think any kind of function can be implemented as a refund mechanism in a simple way.
Potuz:… it's just… I think I'll be… I just wanted to have…
Potuz:out there that we can implement these mechanisms, but I would wait for researchers like you guys to tell us, we believe this is the best way of, like, penalty mechanism that we have, and these are going to be the actual numbers of this option before we start implementing these things.
Bruno Mazorra:Okay, and do you think it's possible to use, previous slots if they were missed or not, for example?
Bruno Mazorra:As data points to define the function, or you think that's a no-no?
Potuz:So, as I mentioned in the flashbots, I mean, and Francesca's here, I think we've had a similar discussion before. So.
Potuz:Generally speaking, when we do a state transition function, we try to not, to not depend on previous
Potuz:data. So this thing is, we want to have a pure function that takes a state, takes a block, and then it gives us a new state. So the way to maintain that sort of signature and still use information from previous slots would be to add that information that we need to the beacon state itself.
Potuz:…
Potuz:So… so we could… we could use this. There could be some pushbacks. I mean, as always, there's a trade-off. Like, if the… if the problem of the free option is very serious, and it becomes trivial by adding, say, the information of how many slots were missing in the last 10 slots, then I think it's an easy trade-off.
Potuz:If the problem is not so serious, then we might get… we might see a pushback.
Potuz:But it is possible, and it is actually simple to implement those things. Like, if the information you need is how many slots were missing before, or, …
Potuz:Or the bits for the previous slots, these kind of things. Those… that information is… it's easy to add to the state.
Potuz:So it's not hard to implement, but it's better if we don't need to add it, because it's a point where we might have a bug and then have a consensus failure.
Bruno Mazorra:Okay.
Bruno Mazorra:Thanks.
Potuz:Does anyone have an opinion on this, on this issue, or in general about the free option problem? I mean, now whether we've reached that, it's probably a good time to talk about that.
Bruno Mazorra:I mean, a question I actually have is…
Bruno Mazorra:what's a reasonable target? Like, if it's fine if it's… the option is used 0.1%, it's fine if it's used 0.01% of times, like, what do you think is a reasonable target?
Potuz:I've no clue.
Potuz:I think it's…
Potuz:So the trade-off is about, so whatever… so if I assume the following, let's put a simplified problem. One simplification of the problem is that
Potuz:I assume that there's no free option problem on the payload, which is not true. There will be a free option problem on the payload, because we cannot make the time to reveal actually zero. We can make it very, very small, but not actual zero.
Potuz:But let's suppose that there's no free option on the payload, on the deadline on the payload, then the only thing that matters is the distance between the deadline for the payload and the deadline to the blocks.
Potuz:And … now, that time gives direct impact on how many blobs… the blob number that we can have. So I think the trade-off is…
Potuz:Economic incentives for roll-ups, and blob number versus these missing blocks that would appear, if the free option is, is exercisable.
Potuz:So that's… that's literally the trade-off on whatever system, with or without EPBNs.
Potuz:So I think, …
Potuz:if you make that… if you analyze these two things, then you might get to a number that people might consider reasonable. But I… yeah, I have no opinion on this.
Potuz:Alright.
Potuz:… Okay, so… I don't know if anyone…
Potuz:This free option problem is something that people are actively working on.
Potuz:And we… we do respect to have changes because of this.
Potuz:And if we find a good mitigation, I'm hoping that we will implement it. The most drastic thing would be to have the two deadlines together.
Potuz:Which we always have an option. I'm hoping that that's preventable.
Potuz:Oh.
Potuz:Alright, so unless someone voices up, I want to move to the last item on the agenda, which is the discussion about inclusion.
Potuz:I'm sorry.
Shane Moore:Shane, I'm helping, Mark over at Lighthouse with, planning EPBS. And, when you mentioned the idea of pushing the two deadlines together, that would be, like, worst case scenario, right? And, I'm curious if… I remember reading from, like, a Shudder post.
Shane Moore:maybe, like, a month or so ago, where they had this idea of, like, builder builds the payload, signs the header, and then encrypts the payload under some, like, threshold public key that's tied to that, slots committee. So, like, if the committee members hold
Shane Moore:some key share after that reveal window gets hit. If the builder didn't reveal, then, like, any party can collect enough of these, like, partial decryptions to reconstruct the payload. It sounds a bit more complex, but, I mean, in theory, like, then…
Shane Moore:you don't really have the free option problem anymore, right? Like, you're able to, reconstruct the payload from, like, the partial, committee members at that point. Not sure if that's something you guys talked about in the past, this is my first time joining this call, but …
Shane Moore:Curious if it's something at all being considered, or if we're, like, pretty set on asymmetric payments is the way to go.
Potuz:This was proposed, it has never been discussed here, actually.
Shane Moore:Yeah, it's like a silent threshold encryption, like, concept.
Shane Moore:And I would have to do more research myself to, like, fully understand it, but yeah, I think it just means more, like, work for committees.
Shane Moore:And probably more, like, overhead for gossiping as well.
Potuz:Yeah, threshold encryption typically has this problem of, like, you need to prove also the existence or not of the keys, and then you have to have some sort of consensus on what was revealed and what wasn't.
Potuz:But yeah, so this… we've never discussed this. If there's a serious proposal with this, it would be nice to analyze it and have a good…
Potuz:description here.
Shane Moore:I'll post, like, what I found, just post about it. It's, like, later on in it.
Potuz:By the way, so I know that when we started doing this thing with EPBS, people on the EL, particularly Justin, pointed that it would be very nice to have encrypted payloads with this, since we now decoupled this, because we can probably use this to…
Potuz:To even have some privacy on transactions, so to… as a primitive for privacy, at least short-term privacy.
Potuz:of transactions.
Potuz:Alright, so, …
Potuz:Okay, so we can probably move on to the next, to the last topic. Well, I'll add two topics. One is going to be very short, but the next one is this discussion on inclusion. So today, we have a miracle proof that the blob is included in a block.
Potuz:This avoids checking a signature twice, otherwise we would need to check signatures on the sidecars, but also it allows us to sync a blob before we get the block.
Potuz:For data columns, it's more evident. We… data columns, we have… we ship them with the header, with the block header, and with all of the KCG commitments, and then we can verify the proofs of the KCG commitments, and…
Potuz:We can verify the signature from the proposer, because we have the header, we can just hash it and verify the signature of the proposer.
Potuz:And then we have a Merkle proof of the inclusion of all the KCG commitments in that block. So if we get one sidecar before the block, we can make this validation, and we already have the signature verification for the block.
Potuz:from the proposer, and we don't need to verify it again. And there's a lot of code that went into doing… into optimizing for both scenarios, where we get a sidecar before, or where we get the block before.
Potuz:Now, on EPBS, it seems to me that all of this overhead is just tech debt.
Potuz:We are…
Potuz:we were guaranteed to see a block before, because the blobs wouldn't be even known which blobs should be included, because the builder needs to know them afterwards. Except the edge case of self-building.
Potuz:So I think it's pretty safe, and also because, since we have much more time, we can actually wait until we sync the consensus block before even trying to sync, sidecars.
Potuz:So, it seems to me that the most reasonable thing to do would be to just remove.
Potuz:both the Merkle proof, the Beacon block header from the…
Potuz:from the column side cards, and when you get a column sidecard, you verify the KCG proofs, you know that the KCG commitments are good, and now you already have a route for the KCG commitments on the BCOM block. So you can just verify that the block
Potuz:Actually committed to that.
Potuz:Anyways, the payload envelope has the beacon block route, and it is true that we would need to add the become block root to the sidecar.
Potuz:So that you know which vehicle blockade this sidecar belongs to.
Potuz:But that would be my… my… my… I know that this adds to the spec, because it changes now the full spec.
Potuz:And I hadn't set my mind to rebase, EPBS on top of Fulu, so this… only we noticed this, this week.
Potuz:But I just wanted… I mean, I don't want to make a decision on this now, but I wanted to point out that I think it's…
Potuz:It's much better if we remove all of this crap.
Potuz:And I know since there's a lot of code into dealing with this situation, it might be even worse
Potuz:like, removing it, but I want to give one attenuation that Casey from my team pointed out, which is, this is not really going to be tech debt, because once you finalize something, you don't ever need to, again, verify these things, and this is data that is pruned eventually.
Potuz:So, after we finalized the first glamster Epoch.
Potuz:And we're after, like, the syncing phase for these blobs, we can just remove all of this… we can remove all of this code from our clients.
Potuz:Can you mention this comment, Terrence?
terence:Right, so I think, like, Francesca also mentioned on Discord that, like, eventually we're moving from column-based gossiping to, like, cell-based gossiping, so when you do cell-based gossiping, then it's a brand new object anyway, then you just move it there. But I guess the question is timeline, right? Like, if we're gonna do…
terence:cell-based gossiping, which I don't know, maybe in G-Star or, like, H star 4, then we just remove it there. We don't, like, we basically don't even worry about this, like, data column at all.
terence:So, I don't know what the time frame is.
Francesco:Yeah, so, I mean, one thing there actually is, …
Francesco:I'm… might have spoken too soon in the sense that, like.
Francesco:I mean, we probably do want to do some form of cell gossiping, but it might be that it's not directly by changing what the, let's say, gossips up level object is. Like, the data column sidecar might still exist, and it's more that
Francesco:Gossip Sub would, like, internally have this, like, concept of partial messages, so I don't know. I'm not entirely sure how to think about this right now, but yeah. In either case, I think it probably would be fine to…
Francesco:To remove this.
terence:Yeah, yeah, I don't have a strong opinion, I think, yeah, I think removing it is good. It just, there's more API-related changes to keep in mind, because it's not gonna be a new object.
Potuz:So I think that a question is, what do we want to have for zero DevNet? I mean, Stefan said that they are going to start implementing Inteco. We are going to start implementing soon in Prism. Certainly, it should be based on… rebased on top of Fulu.
Potuz:And then the question is, what's gonna be more work for us to keep the… the… There's this verification.
Potuz:…
Potuz:that is currently done on Fulu, keep it for EPBS, or remove it entirely. And I… I don't know yet. I think we should have this discussion again, but it might be the case that removing it's actually simple… is simpler.
Potuz:One of the biggest problems that I foresee for… of this rebase to Fulu is the fact that the KCG commitments are no longer coming with the Beacon block, and all of our code assumes that the KCG commitments are in the become block.
Potuz:Again, this is, again, something different, but I… but I also was proposing to keep the KCG commitments in the block, so therefore, they should come in the bid, because of this problem.
Potuz:Because it might make it easier for us to implement.
Potuz:But that would make also the bits much larger if we have 72 blobs.
Potuz:So I don't want to stress the P2P stack where every validator can send bids.
Potuz:if we are postpullo and we see we have hundreds of blobs, we're gonna be seeing bids with hundreds of KGG commitments. That was the reason to only have the root, originally.
Potuz:So, I don't know, I think we should revisit this when we start implementing, and then make a decision then of whether or not we remove these proofs or not, because…
Potuz:It could be a lot of work to just rehash, to keep this proofing mechanism, where everything is moved out of the beacon block.
Potuz:Oh, crap, we're just…
Potuz:on the hour. The last item I wanted to mention is that if we are going to continue having these calls, we need to have a moderator that is not so biased and passionately involved in the CIP as I am. I look forward to seeing… and the best candidate was Justin that just left.
Potuz:So I'm hoping to see some candidates… someone to propose themselves, on R&D to be the moderators for these calls.
Potuz:Alright.
Potuz:Does anyone have any comments before we go?
Barnabas:When do we want DevNet Zero?
Potuz:Haha, I didn't want to go over the hour, but that was the right question. Yes, I don't know. I would target it October. I… I think we can have it by end of October, beginning of November.
Potuz:Does that sound good?
Potuz:… I think Terrence proposed this.
Potuz:We are having to deal with Barnabas already.
Potuz:Stefan, do you have any… any guests?
Stefan Bratanov:Yeah, I think end of October seems better. I think our main thing is that we want to work on master, so…
Stefan Bratanov:Will to take things a bit slowly.
Potuz:Yeah, so that's a blocker for us as well. I don't want… I wouldn't want to be working on EPVS on top of a branch of Prism. I would want to work on EPVS on top of developing Prism.
Stefan Bratanov:Yeah, I mean, we'll still have, like, most of the changes in master, and then if we need some quick DevNet, we can start a branch, but I don't want to…
Stefan Bratanov:Rush, and just have a brunch, which then would be a pain too much later.
Stefan Bratanov:So, I think at end of October seems to….
Potuz:Okay, sounds like a good target for me.
Potuz:I think we can have it. Then, if we are going to start implementing soon, then I would schedule a call for two weeks from now, so to see if we have an idea of whether or not… I mean, this issue of the inclusion proofs and things like this.
Potuz:Because that's something that I think would be a lot of code.
Potuz:Alright guys, thank you for coming.
Potuz:And thank you for those, that were forced into showing up here.
Potuz:See you next time.
Stefan Bratanov:Alright.
Bruno Mazorra:See you.
Chat Logs
00:04:42
terence:21
00:06:47
Barnabas:hola amigos
00:08:15
Barnabas:haha
00:10:06
Francesco:I think independently of the commitment I’d rather leave out the state root, that’s another thing the builder needs to be more or less in the critical path
00:10:53
terence:@Bruno Mazorra you are unmuted btw
00:11:06
Bruno Mazorra:sry
00:14:49
Potuz:Fwiw I checked that Prysm actually suffers from this, I thought that we implemented it the way that Francesco is trying to change but no, we are subject to this bug now
00:15:39
terence:Replying to "Fwiw I checked that ..."
first timely block of slot? or proposer is the same on the canonical chain?
00:15:49
Justin Traglia:What would the fix look like?
00:16:10
Potuz:Replying to "Fwiw I checked that ..."
No the issue of syncing a block from a remote branch, OTOH we won’t sync arbitrary blocks though
00:16:30
Potuz:Replying to "What would the fix l..."
Is that one liner: check that the proposer is the one expected in the canonical branch
00:16:50
terence:Replying to "Fwiw I checked that ..."
because our gossip check is "different"?
00:16:51
Potuz:Replying to "What would the fix l..."
So it’s a descendent from the current head
00:16:55
Justin Traglia:Ideally it would be fixed at fusaka, not a BPO
00:17:03
Potuz:Replying to "What would the fix l..."
Or not necessarily
00:17:12
Potuz:Replying to "What would the fix l..."
But same index
00:18:22
Stefan Bratanov:I am not sure about Teku, have to check if we have this
00:18:42
terence:I know we did it for attestation, but i forgot we did it for the block as well
00:29:36
Stefan Bratanov:I will double check, pretty sure we had this, even remember a PR of it
00:30:36
Potuz:Replying to "I know we did it for..."
Ahh you may be right that this is still in a branch and we had Nishant preventing this because clients didn’t agree
00:32:36
terence:writing spec tests is the hard part (I think)
00:34:17
Potuz:Should be pretty trivial for fork choice tests though,
00:34:27
Potuz:Cause we keep the equivocation
00:35:25
Justin Traglia:I believe we currently reject 0-value bids in relays
00:35:31
Justin Traglia:So it would be inline with that
00:35:51
terence:beacon node rejects 0 value bid anyway when requesting header
00:36:11
terence:(for prysm at least)
00:36:37
Justin Traglia:All for rejecting it
00:36:50
Justin Traglia:(enforcing non 0-value bids from builders)
00:37:27
NC:I mean if those out-protocols want to get around this, they can just submit a bid with 0.001ETH or something right?
00:37:55
Stefan Bratanov:it makes sense to me
00:41:05
Justin Traglia:Sorry, I have to bail for an appt 👋
00:47:09
terence:you can count skipped slots using state.block_roots no?
00:47:41
Potuz:Not. really
00:49:25
terence:interesting, I thought you could just count the number of same block roots in state.block_roots because we process_slot before process_block
00:52:41
Shane Moore:https://blog.shutter.network/shutters-perspective-on-glamsterdam-and-a-cryptographic-fix-for-epbss-free-option-problem/?utm_source=chatgpt.com
00:56:58
Barnabas:Touching fulu spec feels sketchy
00:57:07
terence:are we moving from column to cell anyway? can also just remove there
00:57:50
Potuz:Replying to "Touching fulu spec f..."
It’s not changing Fulu
00:57:59
Potuz:Replying to "Touching fulu spec f..."
It’s changing the Fulu additions in Glamsterdam
01:01:22
Stefan Bratanov:yeah I agree lots of if statements for the kzg commitments was in Teku for the ePBS interop
01:02:25
Barnabas:too late
01:02:26
terence:easy
01:02:30
NC:lol
01:03:23
terence:but we should set on a spec version yet, ex: whats the final data column sidecar format?
01:03:48
Barnabas:20th of Oct sounds good for target then?
01:03:56
Barnabas:should be a week without public testnet