Will Corcoran:breakout room number 22 for EP, or EIP7732, or EPBS.
Transcript
Will Corcoran:We're gonna start with agenda item number two. I think we're waiting for POTUS to join us. We're gonna go back to agenda item number one.
Will Corcoran:But, Terrence, if you wanted to speak to, I guess the second agenda item discussing the potential shift of beacon-blocked body fields, like KZG commitments and execution requests from consensus layer to execution layer.
Will Corcoran:I know you had some…
Will Corcoran:You know, wanted to highlight the benefits, but also flag any backwards compatibility or tech debt concerns.
terence:Yeah, for sure.
terence:Porto's just joined, but let's start with number two first, then we can go to number 1.
terence:And, so I guess the question here is that… let me give you a little background on just our rationale, that in EIP7732, EPBS,
terence:there's this notion of pipelining, which means that you're moving some stuff from the consensus side to the execution side, and then on the execution side, you have this signed execution pedal envelope, which consists of, like, execution requests, KCG commitments, and those were originally on the block body, on the Beacon block body. Now the question is, like, what do we do with those
terence:existing fields on the Bitcoin block body that's being moved to the execution site. We could either just remove them, or we could stop them with empty value, but assert them in the state.
terence:And then, in the current spec that we are removing them, and therefore, the generalized index is gonna be different than before. It's no longer backward compatible. I haven't heard any strong pushback on this. Like, if your applications, you
terence:care about this generalized index field, such that you want them to stay the same, that we're compatible from, Fulu or Electra, like, please speak up. But for now, I'm just assuming, like, remove them is, like.
terence:it's basically cleaner, and then it's less tepid. And, yeah, so that's… so that's basically the beacon blood body fields. And then there's, and then the second item on the…
terence:or number two is, it's data column sidecar, right? So, like, in EPDS, because of removing all the KCG commitment to the execution side, the inclusion proof step is also different. That means that you have to create another data column sidecar.
terence:With a different inclusion-proof deck. And that kind of leads to the questions of, like, because we know the notion of consistency
terence:block will be released before the… before the iconic sidecar. You actually do not need, the signed block header and also the inclusion proof.
terence:in a data collection sidecar. So you can actually remove those two, and then it's also much cleaner as well. So, but that requires more, like, eyes on it. I had a PR out on that already.
terence:But I basically have two PRs in the consensus fact report today.
terence:sorry, I actually have swan PR for this purpose. That is just, renaming the data column sidecar. We removed the sign block body header, sign block header, and also the inclusion proof. So, yeah, feedback welcome.
terence:Yeah, basically, Will. That's… that's basically… yeah.
Will Corcoran:Great, any… Any thoughts on this?
Will Corcoran:Yeah.
ethDreamer (Mark):So, like, I haven't had time to, like, fully consider this, but I will say that…
ethDreamer (Mark):It seems like perhaps even another Benefit of this?
ethDreamer (Mark):is, as far as I can tell, the execution requests are the only thing that was in the beacon block
ethDreamer (Mark):that… really required the beacon block to be signed. That and, like, the state route, basically.
Potuz:I'm sorry, that required the payload to be signed?
ethDreamer (Mark):the… yes, the payload, sorry, the payload to be signed.
Potuz:They don't need to be signed because it broadcasts.
Potuz:Otherwise, you're tossed.
ethDreamer (Mark):So, you can check the hash that it matches everything, and if they change anything, you know, that would…
ethDreamer (Mark):Like, the… there are only a couple of fields that were not protected, that were outside the block. Everything in the block can't be changed, because it's committed to by the hash.
terence:But the CL cannot do that before rebroadcasting, right? We don't want to make this new engine API call to check the block hash, or… we don't want to code new payloads before we… beforehand.
ethDreamer (Mark):So…
ethDreamer (Mark):the CLRD, if… I mean, this… that is true. You would have to be able to evaluate the block hash yourself on the CL side, which some CLs, including Lighthouse and Nimbus, do, because if you don't send… if when you're syncing, you don't send every block
ethDreamer (Mark):like, a new payload. If you don't send a new payload on every block, the spec actually requires you to validate the block hash on the CL side.
ethDreamer (Mark):Because it would enable some attacks if you don't, and you're not sending every single new payload when you're syncing and waiting for the execution engine to tell you that it's valid. If you instead skip over blocks and just, like, send every thousandth, as I think Lighthouse does.
ethDreamer (Mark):You have to do things like verify the hash, and we have that kind of code, but this would actually require that you have the ability to verify the hash in the CLL.
Enrico Del Fante (tbenr):And we don't.
ethDreamer (Mark):Yeah, I mean… We do, we know Nimbus does, and… It does enable you to…
ethDreamer (Mark):Not have to send new payload to every… every… when you're syncing.
ethDreamer (Mark):It does enable you to, like.
ethDreamer (Mark):it doesn't have that benefit that you wouldn't have to send new payload every time when you're syncing, but… yeah, no, it's just… it was just something that I was thinking about.
ethDreamer (Mark):But… I was just pointing out that, like, moving the…
ethDreamer (Mark):If you move the execution request also out, then the only thing a malicious actor could really modify would be the state route, and…
Potuz:What do you mean, the execution request's out?
ethDreamer (Mark):If you move it up…
Potuz:How are we doing that?
ethDreamer (Mark):Oh, actually… Well, so I thought the idea was that the execution requests are being moved to…
Potuz:The execution requests are not being moved anywhere, they are in the envelope.
Potuz:I think the idea now… what we're discussing now is the proof, the proof of inclusion of the KCC commitments. This is in the sidecards.
Potuz:We do not need to prove that the case… that the sidecars are actually included in the block. There's no longer a need to prove that.
ethDreamer (Mark):Okay.
ethDreamer (Mark):A lot of things.
Enrico Del Fante (tbenr):I have a question, maybe just for wrap-up in my head. So, removing the inclusion proof from the sidecars has a strong assumption that you assume you have already received the big on block, right?
Potuz:Yes.
Enrico Del Fante (tbenr):Right?
Potuz:Correct. So, otherwise you have to wait.
Enrico Del Fante (tbenr):Okay, so that's my point. If you don't see the bigum block and you start seeing the sidecars, what do you do with gossip? Validation? So, you have to withhold and wait for the block, and then afterwards you say, okay, we can disseminate the…
Enrico Del Fante (tbenr):the, the…
Potuz:Yeah, so just drop them, but but I think the… what happens is that
Potuz:Today we have this issue because both of these things are being broadcast at the same time by the same player.
Potuz:But in EPBS, it does not make any sense to receive the sidecar before… it's just like receiving the payload before receiving the block. If you receive a payload before receiving the block.
Enrico Del Fante (tbenr):Yeah, yeah, yeah, I mean, in the perfect world where everything goes into the right direction, it's okay, it's just a matter of
Enrico Del Fante (tbenr):a networking glitch that you don't see the beacon block, but you start seeing other stuff that's supposed to be.
Enrico Del Fante (tbenr):So we have to deal with, in code, an edge case in this case, which will be dropping those sidecars, and supposed to never ever receive them, and what we do with the…
Enrico Del Fante (tbenr):Dissemination, do we…
Enrico Del Fante (tbenr):We can't validate them, so we should drop and say… invalid. But then we downscore the peers.
Enrico Del Fante (tbenr):So, yeah, there is a kind of an edge case.
Potuz:Yeah, it worries me even more for the payload, so our current behavior for the payload is kind of tricky, right? When you get a payload that refers to a beacon block for the current slot.
Potuz:We are currently requesting that block by route. At least this is what saved us in our, Kurtosis runs with, with Teku.
Enrico Del Fante (tbenr):Yeah.
Potuz:Requesting those blocks by route.
Potuz:And this is dangerous to do, right? Because anyone can send you a payload for that slot, and you're gonna be starting making requests.
Potuz:Yeah. So I'm not… yeah, I'm not sure. We need to get the P2P experts to decide what is the best, what is the safest way of dealing with these things that are unexpected.
ethDreamer (Mark):And…
ethDreamer (Mark):I mean, I don't know, maybe this is already dismissed, but the ability to receive the payload before the beacon block was one of the things that at least I had theorized, was a potential way, if we had to apply penalties to
ethDreamer (Mark):like…
ethDreamer (Mark):Proposing a beacon block, but not proposing the execution payload because you're doing a free option, but you're self-building.
ethDreamer (Mark):then proposing the execution payload before the beacon block and allowing that to actually propagate via gossip was one of the ways I had thought that you could prevent a solo staker from suffering such a penalty, but…
Potuz:Self-building is never an issue, because the proposer index is already expected from the BCOM state, so if you receive a payload from the proposer index of the current slot, it's fine to request the block.
Potuz:It's… that's not a GOS vector. The problem is, if you receive a payload.
Potuz:From an arbitrary builder, signed by an arbitrary builder, for the current slot, then anyone can actually send you such a thing.
ethDreamer (Mark):Right. And this becomes now a DOS.
Enrico Del Fante (tbenr):Yeah.
ethDreamer (Mark):So this hasn't… Rolled out, potentially, that mitigation if it comes to that.
ethDreamer (Mark):That's good to know.
Potuz:So, Alex has a question, I didn't understand, I just saw it. Could you state it, Alex? I'm not sure if you were talking about the miracle proof, or this issue now of payloads.
stokes:Yeah, I mean, maybe I wasn't following, but I thought we were talking about… okay, so I think you said that basically…
stokes:We don't need to have this, like, KCG inclusion proof in the bobsidecars anymore because of how UPBS works.
stokes:But then, I mean, I think it gets back to what we were just talking about, where you might get the bulbs before.
stokes:And then that's a DOS vector, right? Unless there's some way… so I think what…
stokes:Just, you know, off the top of my head, you'd want to still have some kind of proof, and…
stokes:I mean, yeah, the weird thing is you won'.
Potuz:I think here it's a safe assumption that things are coming in the right order.
Potuz:Because even if you're self-proposing, you might want to send things in the right order. You don't even have time to propagate the blobs, and the become block needs to propagate much faster.
Potuz:So I think it's absolutely safe to just drop messages and ignore them. Instead of downscoring or anything, just ignore messages that come in before the block.
ethDreamer (Mark):Here's coming.
Enrico Del Fante (tbenr):Yeah. Ignore if they are not in the same order, and it should be a very edge case in this standard situation.
stokes:Well, but it might not be. Like, someone might be actively trying to exploit it.
stokes:So, I mean, this is why we did this in the first place. So, like, if you get a bobside car, you should be able to prove it back to either the beacon block or the execution payload that you have, right?
Potuz:That's if you have it. Like, if you don't have it.
Potuz:Right? If you don't have… I think today, people probably do just ignore it.
Potuz:Which doesn't change the behavior. That's my whole point.
stokes:Yeah.
Potuz:So today, what happens is that you prove it once, and now you save this… the sign… you need to do a verification there for the root.
Potuz:And since you have the header, you can do this signature verification there, and then whenever you actually receive the blog, you don't need to redo that verification.
Potuz:But I think this is just completely in vain after a PBS. You could just assume that the blog… you're gonna see the blog before, and if you haven't, just ignored the package before. Ignoring is not a… it's not a problem on the P2P, it's not a DOS, as long as it's more costly to generate the message.
Potuz:But the payload is, the payload.
stokes:This is a problem.
Potuz:room, I think.
stokes:Okay, but the payload would have a block cache, let's say, that is committed to in the beacon block, so that's fine.
Potuz:Yeah, so if you see the… yeah, the problem is the same kind of situation, like, if you see
Potuz:So let's forget about DPBS, and today, you receive a beacon block whose parents you don't have, you request that parent. And we are fine doing this because we first check that the beacon block that we're receiving corresponds to a proposal that we were expecting for that slot.
Potuz:So not an arbitrary guy can send us this, so that's why we request the parents. But if we receive a payload, this is a problem, because anyone can send us a payload.
stokes:Well, but they can't, it's signed by a builder, right?
Potuz:Yeah, but any builder can do that.
Potuz:Builders are not expected… we're not expecting to see this particular builder sending a payload now, unless…
Potuz:we already have that become block. So the analog of this situation, where you're requesting a parent because you don't have it.
Potuz:doesn't really apply for payloads, because we're getting a payload for an arbitrary builder, we don't have the VCOM block, and we cannot start requesting… that's what we're doing now, but I think we're making a mistake. We cannot just start arbitrarily requesting the corresponding Beacon block just because a builder sent us.
stokes:Hmm, so you could… Yeah, okay.
Enrico Del Fante (tbenr):Yeah, but the problem is then… You have to…
Enrico Del Fante (tbenr):Somehow cache them, then wait for…
Enrico Del Fante (tbenr):For the actual beacon block, or you assume that you ignore them, you drop them, you wait for the actual beacon block, and then you do a request by route.
Enrico Del Fante (tbenr):as…
stokes:So yet?
Enrico Del Fante (tbenr):Drop everything that comes, before your action beacon block.
Potuz:You could do that, you could… you could just block… I think I would implement a cache, a small cache, but yes, in principle, you can just drop the payload, once you get the VCOM block, request the payload by route.
Enrico Del Fante (tbenr):Yeah, and a heater cache if you have it, at least a limited cache, you can just…
Enrico Del Fante (tbenr):cache them limitedly, but this applies to the common ones as well. I would… I would do the same for… for… for blobs as well.
Potuz:Yeah, yeah, that's what I think it's what we should do.
Enrico Del Fante (tbenr):Right.
ethDreamer (Mark):There's…
Enrico Del Fante (tbenr):gate everything. Don't do any RPC before receiving the big on block.
Enrico Del Fante (tbenr):Yeah.
Enrico Del Fante (tbenr):I kind of agree at the moment.
stokes:That's probably the pragmatic way to do this.
stokes:You could also imagine the builder has to include the proposer's signature.
ethDreamer (Mark):That's what I was thinking, yeah, like, how… how much data is a beacon block header?
stokes:Not, it's tiny, but I think it's more… we have to make sure all the, like, flows make sense here. But basically, you could…
stokes:you would have some signifier in the execution payload, which I think the proposal signature would be a good candidate, and that would at least constrain this message space quite a bit.
stokes:I mean, I think it would constrain it exactly to what we want.
ethDreamer (Mark):Interesting.
stokes:Because then we're assuming builders see the beacon block before everyone else, which I don't know if that's the case.
Potuz:Well, that HAS to be the case, right?
Potuz:Otherwise, the builder doesn't even know that it needs to broadcast a block.
stokes:Right, so, okay, let's think about this. So, proposer broadcasts to beacon block.
stokes:The builder then must watch for that beacon block, and then basically it would just take the signature of that message and put it onto their… what is it, the signed execution payload envelope?
Potuz:Yeah, it…
stokes:Then you would know.
stokes:Basically, it's basically like a token.
stokes:Well, yeah, I don't know if it does make sense.
Potuz:It sort of, like, doesn't make any sense to add this extra latency when it can only be added after the blog has actually broadcast.
Potuz:I mean, I understand that this prevents a possible DOS,
Potuz:But, I mean, that DOS can happen anyways by people sending you this invalid thing, and still you're gonna do a signature verification, which is much worse than just ignoring the full thing.
stokes:No.
Potuz:So I don't see how this prevents anything, because anyone that wants to send you this maliciously still is going to make you do a work.
Potuz:Verify something.
terence:I think at the minimum, the P2P spec needs to be updated here. That's my takeaway as an action item, that we need to include, like, some sort of, like, cache that says that we only accept the first payload from the builder based on this index.
Potuz:No, I don't think this should be… this should be specified at all. I mean, this is just client implements however they want. We… we can just say ignore.
terence:Even though the builder can send you multiple payloads, they'll just spam you.
terence:Because today, there's no…
Potuz:You could just say ignore if… if you haven't seen the barren bacon block.
Enrico Del Fante (tbenr):Yeah, I would just add some security, related, sentences where…
Enrico Del Fante (tbenr):It's a… it's a suggestion, so… Just ignore everything that… comes… Before the begin blocking.
terence:Yeah, yeah, okay, okay, so just add that, yeah, yeah, that's fine.
terence:Yeah, I mean, what I'm… yeah, stores basically say what I meant.
Enrico Del Fante (tbenr):And dust prevention, just for that, and then… and then all clients can just decide what to do.
Enrico Del Fante (tbenr):Just, like, a suggestion from a security perspective.
Potuz:I think that is already filtered,
terence:No, no, no, that's enough today. We don't have that. That's what I meant with that.
Potuz:Oh, we didn't have the…
terence:We don't have payload? We don't have payload. Oh, I thought, I thought… That's what I meant to add.
Potuz:Yeah, that needs to add, certainly.
terence:Okay, that's missing.
Potuz:added.
terence:Okay, we're… okay, we're on the.
Potuz:Are you sure it's not… are you sure?
Potuz:One line that says it's the first message that we see from that builder for that song?
terence:check, I don't think it's there, that's why I'm surprised.
Potuz:Yeah, if he's not there, that's a bug.
terence:I just suggested to add that, yeah.
terence:Yeah, we don't have that. Yeah, we don't have that, just check again.
Will Corcoran:Do we go back to Agenda Item 1, or do you guys, want to continue to ideate on this?
terence:No, I think we are good. Okay, so I know the action item, I will do that after the call, and yeah, feel free to jump to agenda 1.
Will Corcoran:Okay.
Will Corcoran:Yeah, POTUS, this is accessing post-state information, like account balances, contract states, and the EVM after execution payload processing.
Will Corcoran:Do you want to kind of tee up the details and the… the, I think, 3 trade-offs that you outlined?
Potuz:Yeah, I was just looking at the P2P,
Potuz:And document to see if it was there or not. Yeah, so, okay, so this is something that was raised, by the Lido guys. I think it doesn't apply today, to them, it's not a problem to them. But, the situation is the following.
Potuz:How does someone prove something on the EVM today about the consensus layer? Say that you want to prove that the validator, you want to act, for example, like returning money to someone that is running a validator, and you want to prove that this validator is not slashed.
Potuz:At least up to the previous block.
Potuz:the EVM… has the last block route, and it gives you that by EIP4788,
Potuz:That beacon block root, it's just a root, but then in… within the beacon block, we have a state root field, and that state root
Potuz:Is the post-tate after executing that become block.
Potuz:So you can prove against that state root, you can produce a miracle proof up to that state root, and then from that state root up to the blocked root.
Potuz:And then on DVM, you have a proof of anything that happened on that post-it.
Potuz:So, for example, you can prove if that validator field was slashed or not.
Potuz:On EPBS, however, there's two state transitions. One is after the beacon block route has been executed, after the beacon block, with that Beacon block route has been executed, and then there's another state transition with a different final state route, which is after the payload has been executed.
Potuz:So, suppose in the same situation as today.
Potuz:on the payload for the block at slot n plus 1, you want to prove if a validator was slashed or not.
Potuz:then you do exactly the same thing that I just said.
Potuz:And you would get the right
Potuz:answer because a validator cannot be slashed on the second state transition, which is the state transition of the payload. However, if you need to prove something that happened
Potuz:in the last state transition, because of, for example, an execution request, or something that was processed with the payload, but not at the beacon block that the EAP4788 gives you, then you're in trouble, because you cannot prove against
Potuz:that post-state transition, because you don't have that state route anywhere. You don't have a commitment to that state route.
Potuz:Yeah, I thought it was that we did have it. I didn't say Terrence on the P2P stuff.
Potuz:Okay, so… so the question is, do we need to provide a functionality to prove this against the last
Potuz:Peak and state transition or not?
Potuz:Notice that you can always prove against the parent, the previous, payload transition, because…
Potuz:The state itself has a state roots field, and the latest entry in that field is going to be the post-state transition of the latest payload.
Potuz:Before the become block root, with beacon block route given by 48788. So you can always prove something about either the grandparents
Potuz:post… Execution transition transition, or about the parent-post-consensus transition.
Potuz:Now, the question is, do we want to have something that proves against the parent's execution transition, or not?
Potuz:The only thing that changes on the beacon state are because of execution requests.
stokes:Are you sure? That's the only thing?
Potuz:Well, yeah, currently it's that, right? So we have the, the, the…
stokes:Anything?
Potuz:that has… in the payload… in the payload envelope, you only come in with, execution requests.
Potuz:and you process the withdrawals, but the withdrawals are already pre-processed in the beacon state, but their execution requests aren't. They are only processed with the payload.
Potuz:I mean, it's an easy EIP to add on the execution side. You just have a new EIP that gives you the latest execution payload envelope route.
stokes:Yeah, but we also don't want scope creep.
stokes:I would say to leave it alone, myself, unless…
Potuz:comes on.
stokes:And it's like, this is, like, you know, completely unacceptable, but it should be fine. Like, even the way 4788 is designed, you have, like, a day of look back, so…
stokes:The whole point was not to have something so time-sensitive that this is really gonna be an issue.
stokes:But I want to understand a little bit better. So basically, we're now saying, for one slot, there are two beacon state routes.
stokes:Okay.
Potuz:Yes.
stokes:Is it written into the state roots field in the Beacon state?
Potuz:No. So, the state root fields on the beacon state
Potuz:only has the post-state transition of the latest payload, and if there wasn't any payload, the… so it is… so the state routes in the beacon state doesn't change. It means that whenever you do the state… the slot transition.
Potuz:You compute what was the state route at that point.
stokes:Okay, but then that's just gonna be post-state routes at the beacon block, right?
Potuz:Well, that's going to be post-state routes of the payload, if there was a payload, or the beacon block, if there was a beacon block, or the previous payload if there was neither.
stokes:Okay.
stokes:And so, the way it works is… but, okay, so, but you end up basically writing two routes.
Potuz:Oh, I see what you mean. Just one. There's only one?
stokes:Yeah, yeah, I see what you mean.
stokes:Hmm.
ethDreamer (Mark):So the… so basically the index, like, I, corresponds to a slot, and it's the most advanced state root of that slot.
Potuz:That's correct.
Potuz:So it… it keeps the current… in the happy case, it keeps the current semantics of being after you executed the payload.
Potuz:I also think that we should just leave this problem alone until someone requests a fix.
Potuz:Because the fix can come either on committing more on the… so the Beacon block can commit to a previous state route, the… the EVM can commit to the execution payload envelope route.
Potuz:Or the beacon state itself can keep track of both state transitions.
Potuz:The last one.
Potuz:It would be more fine, like, in the sense that you can prove against either of them in a finely grained manner, but it adds a lot.
Potuz:to the beacon stage. So the last one is the only one that I would be opposed.
stokes:Yeah, I think we would just leave it alone for now.
Will Corcoran:Sorry.
Will Corcoran:No change is a good chain.
Will Corcoran:Terrence?
Will Corcoran:I just dropped, the two PRs, 4525 and 4527, in the chat that you had to open.
Will Corcoran:I don't know if there's anything that you wanted to discuss there, or if you're looking for feedback.
terence:Not much. So, yeah, I guess for 4525, that's renaming execution Payload Header to Execution PayloadBid. That's what people have been suggesting. And that's actually also nice, because it fixes the spec test issue, such that today.
terence:If the name just overloaded, then it gets… it messes up the like sign up.
terence:the light find object for SSC spare beta test, and we don't know how to solve it, so this actually resolved it, which is nice.
terence:So, yeah, I think that one is a no-brainer. And then the Depot Clome sidecar was the second one to remove inclusion proof. I think that one probably needs more time, more eyes on land, before we merge it. I'm not in, like, a rush to merge it. I think we're still fairly early on that, so yeah. But the first one, we can merge it once it's ready, and I will fix the DIMP.
terence:And, yeah, and make sure it's green today.
Will Corcoran:Great.
Will Corcoran:I don't see Barth on the call. He had shared HackMD, I just dropped him a chat regarding some…
Will Corcoran:proposed changes, or considerations for the Builder API,
Will Corcoran:I can keep this on the agenda, and we can discuss it next time if they're able to attend, or if people have thoughts on it now, we can…
stokes:Yeah, he couldn't make it today. Part of this goes back to the discussion that Potos, Terrence, and I were having on Discord around
stokes:how this all fits together, say, with an external builder network, I think this document can probably…
stokes:be iterated a bit more. So yeah, I think we're good for now.
Potuz:I think.
Will Corcoran:Okay.
Potuz:This document, though, has a lot of…
Potuz:mistakes as to how EPVS works.
stokes:Yeah, it's kind of… I think… yeah, I was working with him on this, I think we didn't understand some things, and now we do, so…
Potuz:we… we do have… I mean, and I've talked to builders before, and we never wrote it because, well, because we were waiting until the CIP was accepted, but we do have a very clear understanding of what the builder API should be.
Potuz:And it should not be very… very different to what MedBoost is now.
Potuz:It would be essentially exactly the same way. We should support builders' registrations, because we want to send them the fee recipient where the bid is going to be paid. We want to request the header in the exact same way that we do it now.
Potuz:The only difference that I think we might be forced into doing that, and I think that's really the only difference, is that we might need to sign the message
Potuz:To a given builder.
Potuz:So the validator… a proposer will need to, like, cache these signatures, because this is going to be a different signature for each one of the builders that you're requesting directly. And I think the proposer will need to cache them before the next lot. When you find out that you're proposing next lot, you will need to start caching those requests.
Potuz:And and sign them all, so that you send them signed in the next lot.
ethDreamer (Mark):Why… what is the rationale for including the builder index in the signed piece of data?
Potuz:Because… so the issue is that the auction becomes… even though it's not intentional, the auction becomes sealed.
Potuz:Currently, you now can track what are the bids for everyone on the relay, but if you're communicating directly with the builder.
ethDreamer (Mark):Oh, so if… okay, so, like…
ethDreamer (Mark):if you were… if it didn't include the builder index, then the proposer could send something that they assigned to one builder, and he could use that to send to another builder.
Potuz:Exactly. And since it's sealed, I think this is a request. I mean, it's not that it's important to me, I suspect that builders want this, and when I talked to builders, they told me yes.
Potuz:So… so I think this is something that we need to… we need to do.
ethDreamer (Mark):So, I also had some question about the spec to bring up, I don't know, on me.
ethDreamer (Mark):Have a chance, but it was…
ethDreamer (Mark):It seemed like an ambiguity to me.
Potuz:this, or…
ethDreamer (Mark):Yeah, it's difficult.
Potuz:for the Builder API?
ethDreamer (Mark):It's… no, it's actually the peer-to-peer spec.
ethDreamer (Mark):Passive conditions.
ethDreamer (Mark):If you look at the one for the execution payload, the envelope, I linked it just now, the
ethDreamer (Mark):Looks like the third condition, the one that says reject block passes validation.
ethDreamer (Mark):What does that mean, exactly? Like…
Potuz:Block there is the consensus block.
ethDreamer (Mark):Okay, block be the block with…
Potuz:Block there is the block.
ethDreamer (Mark):I see.
Potuz:That corresponds, that has the root of envelope, beacon block root.
Potuz:Okay, so… And if you have an invalid block, you do not want to sync a payload that is based on an invalid block.
ethDreamer (Mark):Alright, so it's blocked, not envelope. Okay, thank you. Yeah, there's…
Potuz:Yeah, but coming back to the builder API, I mean, do we want… because that's a question I think, we have now, right? Do we want to scope the first DevNet with external builders, or do we want to do what we did with TechCU, which is self-building, but the fully PBS thing?
Potuz:Because if we are going to include the builder API on the first DevNet, then we really need to fix it now.
Potuz:Otherwise, this can be delayed a little bit.
stokes:Yeah, Delane seems fine.
stokes:I mean, there are many changes here, so I think even just showing it works with, like, local self-building is a good first step, right?
stokes:But yeah, this is… I agree we should not delay on this too much, because we should figure it out.
Potuz:business owner.
stokes:a blocker for the first I've nut.
Potuz:the API itself, I think we don't want to change anything. Like, we don't want to change the calls, and we don't want to change the types. The only thing is that the header becomes now what was called,
Potuz:payload envelope… what is it? Execution payload header, and now it's going to be called whatever Terrence is calling it,
Potuz:Something like Bit.
Potuz:But the calls and everything should be the same. The only difference that I see is that we might need to sign them, and I don't know
Potuz:how that signature is going to be. Is it a… I assume it's a BLS signature.
Potuz:Yeah, who knows?
stokes:You mean the staked builder?
Potuz:No, the… no, the return is going to be a signed object, that's fine, but, the question is that the proposer needs to sign the request itself. So today, the proposer sends via MedBoost a request.
Potuz:And that request is not signed.
Potuz:So…
Potuz:now we… the builder API is going to be exactly the same, but the request for the header, the request for the bid, needs to come with a signature. I am the proposer index.
stokes:or…
Potuz:Right, so the purple.
stokes:I also need to say?
Potuz:Well, because…
Potuz:You want to, the auction is sealed, so you don't want to have the builder being hit by other builders
Potuz:Asking them, what is your best bid? Because the other builder will get information that is otherwise secret.
stokes:Okay. So, like, today, MedBoost doesn't work like that, and everyone seems okay with it.
Potuz:Well, yeah, but today the auction is not sealed. After… when… today, I'm not allowed to contact the builder directly.
Potuz:Right?
stokes:Well, the builder and the Relay in either era are just the same thing, like, let's just…
stokes:treat them as Right?
Potuz:If the builder and the relay is the same thing, then this becomes EPBS, and then other builders are trusting when they participate on that relay. But after EPVS, this gets dropped, because I cannot trust
Potuz:that their bid in a relay is the latest good bid, because the proposal can actually be contacting this other random builder on their endpoint directly. So, builders among themselves cannot trust themselves anymore.
ethDreamer (Mark):Yeah, so…
stokes:Right, so I don't see how that's different from today, because another builder could also not trust another relay, right?
stokes:You're muted, but…
Potuz:I didn't… I didn't get.
stokes:I just… I just don't see how it's any different, like…
stokes:this is kind of, I think, orthogonal to EPVS or not. We're just saying, today, it's not a sealed auction.
stokes:And then what you were saying is you want it to become a sealed auction.
Potuz:No, no, I don't… no, I don't… I don't mind. If we don't implement this, it's fine by me, because it's less work. This is an ask from builders, and the reason is that they expect the auction to become sealed.
Potuz:Today, my node does not have access to a random builder. My node only has access to these two or three relays that I can put on MapBoost.
Potuz:And those relays are trusted by the builders.
Potuz:But tomorrow, my node will have… But what are they trusted, right? Because they're still today leaking the same information that you're saying the builders want to hide.
stokes:No, we could go call relays right now and get all of the same information.
Potuz:Is my point. But the question is, today my node cannot get on the side a bid from one of those builders.
Potuz:Because I just don't know where to even ask them.
Potuz:Right? And I wouldn't even trust… my knob would not trust a bid on the side, it only trusts the relays.
Potuz:But tomorrow, I cannot Trust a bid that comes from the side.
stokes:I don't think it matters. Like, I think the picture's the same either way, because, like, all you can get right now is a header.
stokes:And then all you would get under this change, let's say, is add, or…
Potuz:Nope.
Potuz:Today, you just get a header. Tomorrow, you're gonna get a signed header.
Potuz:So tomorrow, I can actually enforce the header.
stokes:Okay, but that doesn't change anything about any MEV you're leaking, right? Like, that's the thing, is like, you're not actually leaking any MEV at any point in time.
Potuz:No, no, it's not about leaking MEV, it's about leaking what is the best bid.
Potuz:Do we have any builders here? This is taken directly out of the Titans report.
Potuz:If you have a builder here, they can just describe why.
ethDreamer (Mark):Simply…
stokes:Either way.
ethDreamer (Mark):I think he's saying that today the builders… like…
ethDreamer (Mark):can all pull the relay and also get the information on what the… like, the auction is open today, it's not closed today, and we can make it open after EPBS, just as…
stokes:or closed. Like, we can make this change, and it would become sealed bid, and that's fine, but it's just kind of indifferent to EPVS, is my only point.
Potuz:Yes, I… with this, I completely agree.
stokes:Okay.
Potuz:I completely agree.
ethDreamer (Mark):So.
stokes:Yeah.
ethDreamer (Mark):One side effect of this, which is a little more subtle, is like, right now, we do expect users to curate their own list of relays, but that's not been such an issue, because relays don't often change that much. I don't know how often there's turnover among builders.
ethDreamer (Mark):If there's, like, more builders that come in and out, but if you do require it to be a sealed bid, it precludes there being a kind of relay that, like, you can point at where, like, say if you don't want to curate your own list of builders, and you just want to say, like.
ethDreamer (Mark):I want to point at a relay that's just gonna, like, builders are gonna sign up to it all the time, and maybe stop, or whatever, come in and out, and I won't have to, like, curate my own list. I'll just point at a relay, it'll collect bids for me, and give me the highest one.
ethDreamer (Mark):Like, if you have to sign for each builder, it precludes this kind of relay from existing.
stokes:Well, so there are things you can do here. I was thinking about this some, and yeah, I don't know. Okay, so the obvious solution is that…
stokes:I mean, yeah, basically the relay and builder merges, so I don't know, you could call them, like, meta builders or something, but…
stokes:Basically, you just need that actor that you're talking about, this aggregation actor, to be a staked builder under EPVS, and then this is fine.
stokes:I think for this to work…
Potuz:Darren says it's optional. I mean, you can just send something that is not signed.
ethDreamer (Mark):Yeah.
Potuz:And that really contrasted or not.
ethDreamer (Mark):I, I was talking about something completely different, which is, like.
ethDreamer (Mark):A relay whose only purpose is to, like, do the work for you of curating builders.
ethDreamer (Mark):You get what I'm saying? So you don't have to make…
stokes:But you can still have this, is what I'm saying. Like, there's no reason you can't have this, it's just, you ultimately need a signature from a staked builder.
stokes:And the question then is, like, does this aggregate, like, how does it… does this aggregation entity that looks like a relay today, does it…
stokes:Is it the staked one and signing bids? Is it…
stokes:It could probably just forward them, and that's fine. But then it just acts like a relay today.
ethDreamer (Mark):Well, I… yeah, I guess you could have… if the builders trust that this third-party relay service isn't going to reveal the bids to any of the other builders, then I suppose… Which they already do today. They don't today trust… they trust them, but not that they're not going to reveal bids, but yeah.
stokes:Yeah, I mean, we've discussed this. I don't know, the Flashbox people have done a lot of research, and so they have opinions on this.
stokes:I don't think it… Like, I think either paradigm is fine, it's just that…
stokes:Yeah, it does, like, change the market structure.
stokes:But I've never seen anything that says, you know, one is strictly better than the other. It's just kind of different options.
ethDreamer (Mark):I had heard that it was good for the buyer when the bid… when the auction was closed, but I am not an expert in that domain.
ethDreamer (Mark):So that could be completely rough.
Potuz:My impression here is that we don't want to make
Potuz:a statement about how the auction should be. Like, if we can make it so that the market decides this, it's better.
Potuz:Instead of us making an opinionated decision on how the options should be.
ethDreamer (Mark):Well, the weird thing is that…
ethDreamer (Mark):Can you have both an open and closed auction at the same time?
ethDreamer (Mark):what I mean is, like.
ethDreamer (Mark):would you have two sets of bids, one that's private and one that's more public? Like…
ethDreamer (Mark):I… I don't know, I just…
ethDreamer (Mark):Because when you're like, we'll let the market decide, or let it be more…
ethDreamer (Mark):like, open, and people will do whatever they want. It seems like…
ethDreamer (Mark):Once an open auction exists, it precludes having a closed auction, or maybe not.
ethDreamer (Mark):That's why I asked if they could exist at the same time.
ethDreamer (Mark):Early.
Will Corcoran:So in the chat, sounds like there's…
Will Corcoran:Christopher, I don't know if there's anything that you want to add to this, but…
Will Corcoran:Some of the sealed proposer bids or seller bids are…
Will Corcoran:Consider to be the… the fairest way to go?
Christoph Schlegel:And this way, I don't know. I mean, as discussed before, it's a… is a thing…
Christoph Schlegel:Makes sense under some circumstances, and to have optionality of,
Christoph Schlegel:what, what auction, to use would be valuable. Yes.
Christoph Schlegel:But, so intuitively, these, CF bid auctions usually use them when you have… you fear that the bidders collude in your auction, or they try to coordinate the behavior.
ethDreamer (Mark):The other… if we have a sealed auction, though, too, we also are doing all this work to, like, add in a public gossip for the bids.
ethDreamer (Mark):So… I mean, I think the thought was that…
stokes:Yeah. I mean, it's kind of just a different channel, though, right?
Potuz:Yeah, both of these things are to prevent collisions. Like, if we do it sealed, that's good in the sense that it's harder for the builders to collude.
Potuz:Because it's… the fact that it's sealed makes it easier to defect any kind of collusion.
stokes:Yeah, but Mark's point is we won't have sealed bids.
Potuz:I understand. And then the P2P stack that is completely open and everyone can see those bids also makes it hard… makes it harder to have a complete collusion of builders.
Potuz:Like, sending, for example, off-protocol better bids, because we will have some builders that would only put
Potuz:public bets on the P2P stack.
stokes:Well, we're assuming that, but yes, assuming there are enough there to make a difference. The thing is, though.
Potuz:I already talked to our chain last to have our own builder about this.
stokes:Okay.
stokes:Yeah, cool.
stokes:I'll believe it when I see it. That's not… I'm not trying to be negative, but I'm just not sure what it will.
Potuz:Oh, my own node will provide bits.
Potuz:on the P2P stack. My own personal home node. Of course, they're not going to be competitive, but my own node will provide bits, for sure.
stokes:Okay.
stokes:Jumping back one point, though, it seems like… so imagine all builders only use the P2P
stokes:Bidful is what I've been calling it.
stokes:I feel like you could still collude there, right?
Potuz:no builder will use the P2P stack.
Potuz:Like, Titan will never send a bid over P2P.
stokes:Well, we don't know that, but sure, assume they would.
Potuz:No, no, we do know that! Why would they ever send a bid over P2P?
Potuz:I mean, they today never send the bid until the very last millisecond. Why would they change this and start bidding, like, 2 seconds beforehand?
stokes:To play weird games.
Potuz:No, I guess I can tell you.
stokes:The point is just so you can imagine.
Potuz:signed. Alex, this doesn't work. These are signed. I can take them for this. So, I can enforce a two-second older bed over the P2P.
Potuz:This is different than today, that you can start sending bids on a relay 2 seconds earlier, because the relay will serve the last bid that they have. Over the P2P, whatever you sent is already signed and is enforced. If you have a better block later, screw you anyways. The proposer can just put whatever bid they decide.
stokes:So, Titan will not send bids over P2P.
Potuz:That's a matter of fact.
stokes:I'm sure.
stokes:Agreed.
stokes:Separately?
stokes:what could happen. What I do know does happen today is, you know, say Titan is looking at bids against BuilderNet.
stokes:from the relays today, they play games based on what they do know. And I'm just saying that open bids in the P2P pool.
stokes:Gives you the same sort of information.
stokes:So there's a chance now for people to play games here, where they could try to, like, trick other propo- er, sorry, other builders, and yeah, like, there just is…
stokes:There's, like, a tax surface here, quote-unquote.
Potuz:What's the attack.
stokes:I basically… so I put a bid out into the world to convince other builders that I'm bidding something other than I would want to.
Potuz:Again, so what is… what is this attack? This is… this is a signed bid. If this bid that you're putting is too high, you might be taken, and you have to produce that payload, because it's just bid and it's signed.
Potuz:It's binding. And if the bid is just too low, it's just useless information.
stokes:Well, but it's not useless, which is my point, because then maybe because of that, Yeah.
stokes:Okay.
stokes:Maybe it's fine.
stokes:I'd have to think about it more.
Will Corcoran:Alright, last item on the agenda is just really calling attention to… we've got an empty spec sheet.
Will Corcoran:For DevNet Zero.
Will Corcoran:I'll take a first stab at getting this loaded up and running by the group.
Will Corcoran:by the next call, which is in 2 weeks, on September 12th.
Will Corcoran:I don't know…
Will Corcoran:I guess one thing I would like some feedback on is timing or proposed schedule for when we anticipate this DevNet 0 to launch.
stokes:Maybe, sorry, just to summarize the previous discussion, we… Oh, for sure.
stokes:We want them to have sealed bids.
stokes:in the builder API, whatever that looks like under EPBS, and then otherwise, we still have open bids with the P2P layer.
stokes:Okay.
stokes:That was it.
stokes:I don't have any views on the DevNet.
stokes:But the sooner the better is probably always good.
Potuz:It'd be nice to know, I guess in this order, do we want to have them, like, multiple clients, or is it fine if it's just a single or two clients DevNet to start with? And the second one, I mean, if… if we want just… if it's fine if it's a pure PRISM or a pure technical devnet.
Potuz:we're gonna have one timeline, which I think it's by the end of October.
Potuz:If we do want to have all clients, then it's better if…
Potuz:We know how other clients are doing.
stokes:I would say two minimum, because, like, one minimum is just, you know, local dev net anyone can do, so that doesn't add too much.
stokes:2, then, is different.
stokes:I wouldn't block on everyone being ready.
stokes:Because I think even having two is going to give us information that's useful.
stokes:That's what my intuition would say.
stokes:I mean, yeah, the other thing then is just, like, okay, now that there's two, there's now interop concerns, and that might be a whole little rabbit hole of attention.
stokes:But that's also kind of the whole point of doing this sooner rather than later, so… Seems fine.
stokes:Do we have… Like, what, Prism, Teku, are there other clients here?
stokes:I don't see anyone. Okay. I guess Lighthouse.
Potuz:There's Lighthouse, and there's, there's Nimbus? No, Lodestar.
Will Corcoran:Oh, it's fair.
Potuz:And now, there's Nimbus too.
stokes:Great.
stokes:So, yeah.
stokes:Have people started looking at this?
ethDreamer (Mark):Yeah, I mean…
ethDreamer (Mark):we're implementing, but we're quite a ways away, at the time being. I keep getting pulled onto Fusaka stuff.
stokes:Yeah.
ethDreamer (Mark):But…
stokes:Kusaka's very important.
terence:It's also worth mentioning that there is spat tests for the basic stuff already, so basically, as you're implementing, you can also check spat tests in the same PR just to make sure that pass. Hopefully, that will shorten some, like, time in terms of debugging on, like, multi-client setup.
Potuz:What I'd like to get, even from clients that are just starting to implement, it would be nice if we can just set up some branches.
Potuz:that we can pull out of the PandaOps, image… Docker Images, builders, so that we can test on Cryptosis without having to bug you.
Potuz:Like, if I can actually grab, I know that the latest CPBS Docker image from Lighthouse is going to be whatever you have latest, I can try against it without having to bug Lighthouse.
stokes:I think that's a very good idea, but it also sounds like other clients are not even
stokes:In a place where they can give you that right now.
Enrico Del Fante (tbenr):And to be honest, we will try to move away from a branch as soon as possible.
Potuz:Same here. Same problem with Ozaka, yeah.
Enrico Del Fante (tbenr):We, yeah, and we will definitely have, kind of a blackout for a, for a…
Enrico Del Fante (tbenr):medium time period to actually start grabbing stuff, and maybe rewrite portion of that thing that we have in our current branch, and probably do… and yeah, having a proper implementation, we'll test it, so we will have, will take some time.
Enrico Del Fante (tbenr):Even if we have a kind of, current working…
Enrico Del Fante (tbenr):testing branch doesn't mean that we will have, soon implementation on master.
Potuz:Yeah, we're in the same scenario, and we also need to change quite a bit our implementation, so we're gonna start, like, pulling things, and this is only going to happen after we have
Potuz:Fulu in our developed branch. So once… once we have complete Fulu on the developed branch, we can start looking into
Potuz:EPVS. Otherwise, it doesn't make any sense.
Enrico Del Fante (tbenr):You are in a worse position than us, even.
Will Corcoran:I think that's all we got for today.
Will Corcoran:I'll try to circulate notes.
Will Corcoran:Yeah, Mark.
ethDreamer (Mark):question about, I mean, Terrence brought this up, but…
ethDreamer (Mark):There's something I was thinking about. So today.
ethDreamer (Mark):Whether you're… whether you're using a builder or not, you will…
ethDreamer (Mark):like, get… you will have the option to self-build, and generally clients will tell their EL to build a block, and then we'll compare the value of the block against the builder block, and you could, in theory, end up picking your own local block if
ethDreamer (Mark):It ended up being more valuable, or if it didn't meet certain conditions that you can specify it anyway.
ethDreamer (Mark):I… I expect something similar to happen in…
ethDreamer (Mark):Post-epbs, where you're still preparing, at least, to publish locally if something were to happen with your communication with the builder.
ethDreamer (Mark):And if you think through…
ethDreamer (Mark):what that means, then the… you'd have the following order of events. You would first prepare payload to your EL,
ethDreamer (Mark):then you need to get the block from your EL, Turn it into a bid.
ethDreamer (Mark):send that bid to your validator. Have your validator sign that bid, and then at slot 0, or at time zero into the slot, or whenever you would usually fetch bids, that's when you…
ethDreamer (Mark):would… Go actually fetch bids from builders and compare against the bid that you built earlier.
ethDreamer (Mark):So, it's a little funny because it necessarily means that a certain number of steps took place before you…
ethDreamer (Mark):Like, like, you stopped local building in order to sign and create a bid before you, like, hit builders to stop building.
Potuz:I think we do this at the same time now, so when… So…
Potuz:Today, we request a local payload at the same time that we request a header.
Potuz:So that's… that's a point. So you… you start slot zero, you request a local payload from your engine.
Potuz:And you request headers from the external builders at the same time.
ethDreamer (Mark):Okay, but so.
Potuz:You wait for the external builders, and by the time that the external builder has returned, you compare against your payload.
ethDreamer (Mark):So, like, you get your local payload… oh, so you just compare against your payload, and in which case…
Potuz:the bid in parallel, but it doesn't matter. The question is comparing against the payload.
ethDreamer (Mark):Sure, but then, let's say you take your local payload, then… when…
ethDreamer (Mark):your original request to the Beacon API was asking for assigned bids to… or, like, a signed bid to, like, put into your block. No, I guess it's asking for a beacon block. Yeah, so it's asking for a beacon block to sign, right?
Potuz:No, the what? So, the engine API just asks for a payload. There's no changes on the engine API.
ethDreamer (Mark):How much knowledge.
Potuz:Oh, the Beacon API, you mean from the validator client?
ethDreamer (Mark):Yeah, so, like, the validator's gonna need to request a beacon block to sign.
ethDreamer (Mark):and the CL is gonna have to pick, like, the best payload. And so, like, usually, when they request being blocked to sign, that is when you're gonna hit for builder pay… builder bids. Well…
ethDreamer (Mark):if you haven't already gotten your payload from the EL, gotten
ethDreamer (Mark):an unsigned bid that you can return back to your validator to sign, to then put in your beacon block, to give back to your, like.
Potuz:No, the way we do this now is, at the beginning of the slot, the validator client requests the bid to sign.
Potuz:At that time, it also requests the Beacon Blog sign.
Potuz:the beacon node handles both. The beacon node
Potuz:Gets the payload, requests the header from the builder, the payload uses to make a bid, it sends back the bid to the validator.
Potuz:Gets the signature from the validator, and then assembles a bit on block with whatever the best speed is.
ethDreamer (Mark):And sends that.
Potuz:Sends back that to the validator client, the validator client signs the become block.
ethDreamer (Mark):This has to be multiple requests, then?
Potuz:It has to be…
terence:So this is why, like, I have been thinking, like, we know what the cell build scenario is, we know when cell building, if the proposal index and the building index are the same, that we could maybe, if it's self-built, then just don't check the signature of the bid.
Potuz:Such that you must make it more complicated.
terence:It's supposed to be suspended.
Potuz:more complicated just to save one signature.
terence:But it's one Beacon API request, and then it's also one, like, I think it's… I think it's a much greater safe there than the spec change, someone that's implementing it.
ethDreamer (Mark):I think I agree.
Enrico Del Fante (tbenr):That's I have the same feeling…
Enrico Del Fante (tbenr):There are two in-flight requests, the beacon…
terence:Sure.
Enrico Del Fante (tbenr):light will have to wait the other one to close, and then return back. It's kind of a little bit… the design is complete.
ethDreamer (Mark):It's all to be driven, by the way, by the validator client.
ethDreamer (Mark):Which makes it worse.
ethDreamer (Mark):Even, like…
ethDreamer (Mark):It's like, you… you…
Enrico Del Fante (tbenr):Yeah, yeah, because you have to have the validator client ask for the bid before, because otherwise the bid or not doesn't know that there is a self-building in…
Enrico Del Fante (tbenr):in, in flight.
Enrico Del Fante (tbenr):yeah.
ethDreamer (Mark):That's my thought, because if.
Enrico Del Fante (tbenr):Unless during the preparation, we also prepare, giving the information to the beacon node that I am a validator who.
Potuz:That's… we are doing this for the…
ethDreamer (Mark):Yeah, no, that already exists, like, the customer does know that you need to… that you need… that you have an upcoming proposal, and it tells your executioner to prepare a payload, but…
ethDreamer (Mark):Like… but the point is that at… generally, what the validator asks for is a friggin' beacon block.
ethDreamer (Mark):And…
ethDreamer (Mark):If we don't require the value to sign this thing, then it's just gonna get back a beacon block. It's one request, gets back a beacon block.
terence:It's seamless today, it's seamless today. There's no charge there.
ethDreamer (Mark):Yeah, same as… that's what I'm saying, that's simple. If we don't… if we do require the validator to sign, it asks for a beacon block.
ethDreamer (Mark):Somehow, either before, or during, or some weird way, it has to get back an unsigned bid to sign, to send back, and then get the beacon block.
Potuz:No, no, no, so we've requested bid before, but if we do what Terrence says, that self-building does not need to include a bid, or… I mean, we enforce that the signature, for example, is zero.
ethDreamer (Mark):Yes.
Potuz:then you can just go this… make this into a single request. Just request a beacon block, and that's it.
ethDreamer (Mark):It's… it's much simpler.
terence:It's seminars today.
terence:Nothing changed.
Potuz:Okay, it is… it is a change. It is a change in the spec. We can… we can add it.
Potuz:just make… I would say that the signature needs to be zero in the case of…
ethDreamer (Mark):Yeah.
Potuz:In the case of the… of self-building.
ethDreamer (Mark):Yeah.
ethDreamer (Mark):Because the beacon block is signed anyway, so, like, it's already dumb in this case.
ethDreamer (Mark):You know, you're signing a little piece in the block, and then outside the block, like… Sure.
Potuz:The change in the spec is simple, it's just I didn't want to add this extra check. But, yeah, the change in the spec is just enforce that the signature in the header is zero, well, in the bid is zero, if it's self-building. If the proposal… the builder index is the same as the proposal index.
Potuz:And in this case, the validator index would… the validator client would only request once a become block, and that's it.
ethDreamer (Mark):Which is what it does today. It's perfect.
Potuz:So do you guys want to add this?
ethDreamer (Mark):Oh, yeah.
terence:I can add them.
Potuz:Rico, sounds good to you?
Enrico Del Fante (tbenr):Yes.
Enrico Del Fante (tbenr):To me, I would… yeah, I don't have the details, but I think, like, we're already handling explicitly the case where there is the self-building, so you're… in the spec, that case is already well… well-defined. We're adding another…
Enrico Del Fante (tbenr):condition there, so it's not just another thing, another con… another situation that we have to handle. It's just a situation that is already there with just an additional constraint, which
Enrico Del Fante (tbenr):may… may be easier, and we save… we save some… something on the VCBN communication.
ethDreamer (Mark):Well, like, the only way, because without this, it's like, the simplest way to do it without this is to just have the validator client
ethDreamer (Mark):Hit before, like, do this in advance.
ethDreamer (Mark):You know, if you want to do it just in time, then you have to handle all the edge cases of, like…
ethDreamer (Mark):You know, the… the builder bids arriving beforehand, and like… like, it just…
terence:My biggest complaint is not the extra code, it's that Bitcoin now has to catch that pillow.
Potuz:Yeah, they got it.
terence:The next person. I don't like that catch.
Potuz:Yeah, that's what we're doing. We're caching the… we're caching the payload and the pitch.
Potuz:All right, so let's add… let's agree that then that the signature is zero.
Potuz:On the header? On the bit?
ethDreamer (Mark):On the bid for self-building.
Potuz:Okay.
Potuz:Okay.
Will Corcoran:Alright.
Will Corcoran:seems like a productive call. Any last comments?
Potuz:This is going to be in the first Debnet.
Potuz:So this… this… this thing will be in the first abnet, just on the scope, okay.
ethDreamer (Mark):For any DevNet. I want to implement the other thing.
ethDreamer (Mark):Yeah, no, I know, but the first definite is… I was going to suggest that we only do self-building? Well, we already agreed on that, too. Oh, okay. So, but with this change already included.
Potuz:So, let's wait until… yeah, so let's have this PR today so that it is in Alpha 6.
ethDreamer (Mark):Sweet.
Will Corcoran:Great. Well…
Will Corcoran:Everyone have a nice weekend, and we'll see each other in another 2 weeks on September 12th.
Potuz:Thank you!
terence:Thank you for hosting.
stokes:Thanks, Erwin.
Chat Logs
00:05:17
Potuz:Am I here?
00:05:28
Justin Florentine (Besu):i see you fren
00:05:33
Potuz:had to log in like 10 times
00:08:05
Will Corcoran:So, :
1) remove entirely OR
2) stub as empty?
00:09:10
stokes:Stubbing as empty will be less of a headache
00:12:04
stokes:Hm don’t we need to prove the linkage for DoS reasons?
00:24:36
stokes:Can filter the p2p topic to one message per builder
00:24:41
stokes:Per slot
00:24:45
Will Corcoran:I can ask Raul and/or Marco to join the next call, if helpful
00:28:42
terence:sorry @Potuz and @stokes we do have it: [IGNORE] The node has not seen another valid SignedExecutionPayloadEnvelope for this block root from this builder. maybe not in our usual language but that specifies what I was worry about
00:30:12
Will Corcoran:Evaluate options:
a. Leave as-is, using state.state_roots for post-payload access (grandparent payload, sufficient for most cases).
b. New EIP exposing execution payload envelope root (like EIP-4788, for post-payload proofs).
c. Add pre_state_root to beacon block (similar functionality to a)
00:31:27
Will Corcoran:Team Leave it Alone?
00:33:58
Will Corcoran:https://github.com/ethereum/consensus-specs/pull/4525
https://github.com/ethereum/consensus-specs/pull/4527
00:35:15
Will Corcoran:https://hackmd.io/@bchain/BJYoUYjIll
00:39:00
ethDreamer (Mark):https://github.com/ethereum/consensus-specs/blob/master/specs/gloas/p2p-interface.md#execution_payload
00:44:07
terence:the siganture should be an optional field anyway, builder can choose or not choose to gate it
00:48:59
Christoph Schlegel:The other way around, for the seller
00:49:17
stokes:Replying to "The other way around..."
Open or sealed?
00:49:26
stokes:Replying to "The other way around..."
(Is better for the seller)
00:49:43
Potuz:Replying to "The other way around..."
sealed is better for the seller
00:49:45
Christoph Schlegel:Replying to "The other way around..."
With a lot of asterisks sealed bid might be better for seller
00:49:45
Potuz:Replying to "The other way around..."
the proposer in this case
00:50:05
Christoph Schlegel:Replying to "The other way around..."
Harder to coordinate for the bidders
00:50:31
Potuz:Replying to "The other way around..."
fair?
00:51:05
stokes:Makes sense
00:51:50
Will Corcoran:Replying to "The other way around..."
Least-exploitable?
00:54:58
terence:you cant cancel p2p bids though, if you have a higher bid, someone will just take it
00:55:28
Will Corcoran:https://notes.ethereum.org/@ethpandaops/epbs-devnet-0
00:56:10
Potuz:how are clients in implementations?
00:56:23
Potuz:yes
00:57:35
Will Corcoran:Teku: does end of October work for you?
00:58:16
Enrico Del Fante (tbenr):Replying to "Teku: does end of Oc..."
I hope so
00:58:33
NC:Lodestar: pretty early into the implementation
00:58:35
Enrico Del Fante (tbenr):Replying to "Teku: does end of Oc..."
We will have a long work to start moving stuff on master branch
00:58:48
stokes:Id say just launch devnet-0 once two clients are ready
00:59:05
stokes:May not be able to set a date today
01:00:18
Potuz:we're on the same scenario Enrico