FOCIL Breakout #37

Transcript

Justin Traglia: Hello!

Jihoon Song: Hello, hello.

Justin Traglia: I am just waking up again. I've been trying to sleep in more. I've been so tired recently.

Jihoon Song: Oh.

Justin Traglia: I mean, it's just 8 A Oh, yeah.

Jihoon Song: What time is there?

Justin Traglia: 8 AM?

Jihoon Song: Not bad. And… How's your flip cycle?

Justin Traglia: I mean, it's fine. Going to bed around. 11. Yep.

Jihoon Song: Not bad. Hey, Matthew.

Mehdi Aouadi: Hi, guys.

Justin Traglia: Hey, Madd.

Jihoon Song: Hello guys, I think we can wait 3 more minutes.

All right. Seems like we have enough people here. Right. Let's get started. Hello, everyone. Welcome to FOCIL Breakout 37. Today we can share development updates and spec updates. Yeah. Do we have any client updates?

Mehdi Aouadi: Yeah, I can give an update for… From the tech side. Yeah. Recently I integrated our latest Glamsterdam changes. into our FOCIL branch, but I wasn't able to interrupt with Lodestar. I think it was because of the builder execution requests that have been added recently. So yeah, I didn't publish a new docker image. I left the old one which was working. So, I guess, once, the builder execution request, would be implemented in other clients, I'd be able to interrupt again.

Jihoon Song: That's that. No updates from Lodestar. Need to replace and clamp 6 on ethrex as well. Yeah, we don't have anyone from Lighthouse, so I guess… This is it for client updates. 6. Okay. Right. I think we can move on to the spec updates. Yeah, let me share my screen.

Is the screen good?

Justin Traglia: Yep.

Jihoon Song: Thank you. Yeah. So, today I want to introduce. three changes. One is about execution APIs, which is quite mature, and we expect to merge it this week or next week. The second is payload attributes event. And the last one is having a little bit of Q&A session on adding IL bit list back. So let's start with. Sorry. Yeah, I was just checking on chat. Sorry. How can I go? My bad. Yeah, so, Let's start with payload status V2. So previously it had latest IL satisfied hash, but given the fact that we are interested in the IL compliance of the tip.

It is enough to use a Boolean flag indicating whether the tips satisfy the IL constraints. accordingly, new payload and FCU are changed. Let's start with new payload. It specifies, to set IL satisfied as follows. If the payload is valid, then the flag should be either true or false, depending on its IL compliance. Otherwise, it must be null, because IL-compliant payloads are a subset of valid payloads. And… I think this is the important part. The EL must retain ILs for an accepted payload. This is to make sure… to have the same IL view after moving to a different branch. So when you receive a new payload called with a block from a different branch, you store the corresponding ILs.

And later, when you receive an FCU call picking up that branch, you must return whether the tip of the branch is IL compliant. So this was the new payload. And for FCU, sorry for small letters, what it asks is. it's the, IL check for the block with head block cache. So it's just the same. So if the head block is valid, then… You're going to run the IL check for the block and return the result. Oh, sorry, I forgot to mention this. We are interested in the tip of a block, so if the EL… so the EL can drop ILs for accepted payloads that are not at the tip anymore, and the EL also doesn't have to run the IL check for intermediate payloads.

So this is the engine API changes. Mikhail and I have been working on this and we believe it's in a final stage. We plan to merge it this week or next week, as I said earlier. And once it's merged, I will try to find some resources from Stihl to help us with execution spec tests. So. Before we move on to the next topic, do we have any questions or is it all clear? Guess it's fine. Oh. Yeah, so… Now we have execution spec handling different branches. In the same vein, consensus spec will have a comment somewhere saying that is payloading clausally satisfied will return true for not validated payloads. This is currently missing, and I'm gonna add this. It will be a simple change, at least at the spec.

And… We can also discuss about payload attributes event. So there were a few options that we had in our mind. The first one is changing the Engine API to send a list of ILs, not IL transactions. And then a builder can retrieve IL bit list by decoding payload attributes v whatever. The second option is leave everything as is and just modify the payload attributes event to include IL bits. So… And the last option… which was proposed by Indigo yesterday, is adding enclosure list bits to the event as a top-level field. So. Yep. Do we… can we have, like, some input? On which direction we want to go.

I think this is related to setting up Builder, because Builder… Need to set this IL bit lace. It doesn't have to be perfect in first few DevNets, but down the road, we need to agree on This SSE event.

Nico Flaig: So we definitely keep the bits now. Because right now the spec has them still removed, right?

Jihoon Song: Yeah, I haven't added it back, because… We need to… Consider it, I mean, consider the bit list in fork choice, and I haven't had enough time to think about. what would be the best way to implement it, but it's on my to-do list, and yeah, we will not have it back. And we can… Discuss why we're adding it back after this topic.

Nico Flaig: Yeah, I mean, from my side, I think three would be the simplest. For one, I guess we need more discussion. That's something we want to do. And would need EL and CL changes, so yeah, like, you're gonna add some delay in the testing.

Jihoon Song: Right. So… we might end up changing Engine API to send ILs, because… for whatever reason, but still… If we were to go with the third option, then it will be the least invasive change, because We can just change it in the CL and Bill Dorff can adapt it. Yeah. So I'll say we can tentatively go with the option three and then revisit this later. Right. Let's move on then. So, let's talk about why we are adding back IL bitlays. There were some lengthy discussion in Discord, but it might not be…

easy enough to grasp. The reason, so… Let's imagine this case. Let's say the winning builder didn't listen to some IL and they used trustless payment and somehow that missing IL. contained some unique transaction, which causes a payload reorg. Then, the builder… is enforced to pay. And in this case, if… The first condition is because of some network failure or whatever, then. The builder is forced to pay. When it follow the protocol honestly. So this is what the bit list can prevent. I think there was a chat.

Yep. Yeah, so, this was the reason and We can ask a few more questions to understand what is the implication of this change. So… The first question could be, does the bid list align incentive for proposers? Then I think it is helpful to Explore… trustless and trusted payment cases separately. For trustless payment, it is yes, because otherwise their block will not get accepted by the payload… by the protocol. And for trusted payment, it is also yes, because it doesn't change the fact that their block Might be reorged if it contains. Not a super sad bit list. But it is noteworthy that it is still a bad step for a proposer because they will never know whether the payload is actually IL compliant until it's revealed. But still, from proposer's perspective, it is their incentive to choose non-sensing payload.

And. Yes, Nico.

Nico Flaig: Just one question. What do you mean by the block would not be accepted? What's the accept condition where this is not the case?

Jihoon Song: Right, so, this… That's what I've been thinking about. I think there are at least two ways to implement this. One is quite simple, but… Strong, which is. We can make a testers to vote for a parent. If the block has a, If the blocks bit contains a bit list that is not superset to their local IL view. So, there will be no blog. And hence, no payload for that slot. The second… option is… we don't reorg a block, we just reorg a payload, but if the block, sorry, if the builder used Trustless Payment, and if The builder's missing IL caused… the payload reorg, then we do not enforce the trustless payment.

Even if it received enough attestations. I'm not sure if… If this is feasible because it kind of entangles fork choice and state transition. I doubled it a bit before this call, but it doesn't look like pretty. I'm not sure which one is the best, but like, yeah, it depends on the design, I think. So. In here, I just wanted to, explain, saying that, like, that The testers were going to reorg a block. We're not going to accept a block. If it if the beta lead is not good.

Nico Flaig: Yeah, I guess the concern would be if the proposer and the builder have a bad view of the ILs, then you orphan the block, right? While before you would just orphan the payload.

Jihoon Song: Yes, if you were to go with this design. Yep. So what changes here before and after the bitlist for Proposer is before bitlist, Proposer doesn't care whether the payload is Censoring or not if it's trustless payment because they will get gonna get paid anyway. If it… if their blog is timely. But with bit lace, they want to care about whether the bit lace is a superset. So yeah. So for, but for builders it's different because from their perspective, if they are using trusted payment, then they can just ignore this bit.ly, just set it to all ones and then just try to compare it only with base value.

And this could be… The case… Where builders are confident that they have a good infra. to listen all available ILs in the network by… I don't know, fetching… IL from peers using request response or over the P2P or whatever, even when network is diverging, then they might go with this. Competing with only bits value strategy. So, it doesn't really change for builders, but it might change incentive for proposers. So, another argument that it will gonna improve liveness, and does it improve liveness? Then, my opinion is yes, but when certain conditions are met. So, this is the condition that, we can improve liveness, which…

the protocol would have reorged the payload without bitless. So it is just a case that we just covered before, when the winning builder couldn't listen to some IL, and that IL caused the payload to reorg, and somehow a proposer and the majority of our testers received that IL. And we also need to know whether the bidder list was honest or not. And in this case, the proposer will fall back to the next bidder, and it can go down to local building. So, if we go to local building, we will gonna still have some… Beacon block and payload. So yeah. So. this is my understanding of the benefits of having Bitlys, and how much does it make sense is depending on like, what is the

probabilistic of this conditions are met. And… So it has multiple facets and my main understanding is it can prevent this Case, which is… an honest actor shouldn't be foolish by acting honestly, so I think this is more about correctness or soundness. So yeah, I'm happy to answer any questions. Or any just concerns. It doesn't have to be like perfect.

Nico Flaig: Yeah, I guess my only feedback there would be, how likely really is this that a builder doesn't observe an IL while a proposal did? That scenario seems to be zero, probably, on mainnet. Because you also assume, right, it's a builder that wanted a bit, so… It's not. It's gonna be a sophisticated builder, and usually relays and builders today are way better connected than proposals.

Jihoon Song: That's true. That's true So it doesn't really matter if there is no trustless payment. But there's a trustless payment and This scenario… might happen. So if you're asking me, like, how many slots will this gonna happen, then… I don't know, I cannot predict, but yeah. From protocol's perspective, I think this is just about, like, correctness or soundness. Of course, it can improve liveness, it can align incentive for proposer. More research is needed if you were to provide some numbers on each argument, like how compelling they are. So, yeah. Yeah, it's multiple reasons. to have it. I think. But the trade-off here is… This will be part of fork choice.

And… So yeah, it adds some complexity to the protocol.

Nico Flaig: I guess the minimal useful thing is, if we assume both proposer and builders honest, then we don't need anything in Focus, right? And you get the same benefits.

Jihoon Song: Yeah. So in the happy case. where… Payload is good and Vitalist is also good or whatever. It doesn't really change anything. It comes into play when things go wrong in this, like, weird case. Alright, do we have any…

Justin Florentine: Can I just try to parrot something back here? Tell me if I'm oversimplifying this. This sounds to me like the winning builder. Lied about their bid? Isn't this saying that the wedding builder said they could satisfy an IL that the proposer required, but didn't?

Jihoon Song: You mean in trustless payment or trusted payment?

Justin Florentine: Trustless.

Jihoon Song: Trustless. And are we assuming the payload is good?

Justin Florentine: Hmm. Yes, outside of IL compliance.

Jihoon Song: Yeah, so if, as long as payload is good. Builder is free to lie about BitList, because… Yeah, it doesn't really hurt anything. But if Builder lied about bit list, like setting to all ones. even when they didn't listen to all IELTS, and if their payload turns out to be Not IL compliant, then… They will have to pay for the cost. But for… if it's trusted payment. It doesn't really change anything, because they were not gonna pay anyway.

Justin Florentine: Right, that's the risk you take.

Jihoon Song: Yeah, so if you are a proposer. And if you want to use trusted payment, then… You want to know there's a risk that you are accepting a bid that might come with censoring payload. But then the next question is, what would be the reason for a builder to produce a censoring payload, if it's not a bug or whatever reason?

Justin Florentine: Okay, thanks.

Justin Traglia: It. I still don't really see the value in the bit list because, I mean, they can still just lie in either case. Like, couldn't you assume honest behavior in the first place? And then if they submit a. a payload that's non-IO compliant. It would just be reorged out anyway.

Jihoon Song: Exactly.

Justin Traglia: Nothing would happen either.

Jihoon Song: Yes, but with trust lease payment, you are gonna pay for it.

Justin Traglia: Wouldn't they pay for it? And the current. Why are you two?

Jihoon Song: Oh, sorry. Yeah, I, I mixed about. To possible implementation, so yeah, So, if we… if we are gonna reorg a block, then they were not gonna pay anyway, because, yeah, their block is gone. But if we don't reorg a block, if we just somehow find a way to not enforce The payment, then… Yeah, they were gonna have to pay… But we will gonna just reorg a payload. So that's why I think reorging a payload and just not reinforcing a trustless payment in this specific case is the ideal way, but I'm not sure about its feasibility and complexity.

Justin Traglia: But that wouldn't hurt the proposer, no? Like… I feel that it should be on the builder to be I/O compliant and not on the proposer.

Jihoon Song: Mmhm.

Justin Traglia: Like, we shouldn't, financially harm.

Justin Florentine: I think that.

Justin Traglia: Yeah.

Justin Florentine: Right? Because the builders don't see the block until it's too late. It's already been signed and everything, right.

Justin Traglia: What do you mean? It has to be. It has to be on the proposer.

Justin Florentine: No, it has to be on the builder. Like, the proposer has no input or decision about what goes into the block anyway, because… You know, they're signing blinded bids.

Justin Traglia: Yeah, sort of.

Justin Florentine: So we're trying to figure out the penalty really, right?

Jihoon Song: Yeah, that's fair.

Justin Florentine: Okay.

Jihoon Song: Yeah, I think… We can have more productive discussion if we have some. candidate spec implementation. Sorry, I just didn't have the luxury of preparing. Okay.

Justin Florentine: Okay, I think what we're… this is helpful to me, at least, because what we're doing is we're… Adding utility to the difference between trusted and trustless payments, right?

Jihoon Song: Yes.

Justin Florentine: We're just creating more reason to not use trusted payments. To me, I think that's a feature, right?

Jihoon Song: Yeah, you can frame it that way. Yeah.

Justin Florentine: Okay.

Jihoon Song: Could be. So it's funny that this bit list was proposed. even before we have the spec, and now we are discovering the pros and cons of this bit list. The cons is, protocol complexity, and I think we're just mainly focusing on what we can do with this bit list and what is it for.

Nico Flaig: Yeah, but I think we could just do a minimal approach first, maybe, where we… so the proposer just picks bits that is a superset of their IL view, and then… We do nothing on the fork choice level. So you assume the proposers honest and basically has interest in picking a bit that is non censoring. And then you also assume the builder's honest in that case, right? So the proposer only looks at the bit list basically to protect the builder from getting its payload reorged. So that would be minimal, right?

Jihoon Song: In trustless payment, right? In trusted payment, you don't get, you don't have any guarantee. that's a catch, but I agree that that would be the minimal approach while we are discussing how to implement this.

Nico Flaig: Yeah, I mean, because that is pretty simple from the complexity, right? We just need to update the event. We need to add this to the container and then how we select bids from the pool is also basically we just also check the bid list instead of just the bid value or whatever clients use to select bids.

Jihoon Song: Yeah, yeah, yeah, absolutely. So Yeah, okay. We have…

soispoke: Sorry, I'm late, but would it be a step forward, like, a step towards then?

Jihoon Song: Oh, weird.

soispoke: Enforcing the fork choice, or would it just be… Like, keeping it minimal.

Jihoon Song: mainly discussing… I think we are mainly discussing how to… consider BitList in the fork choice, because there are multiple possible options, and each option brings with different meaning. And…

soispoke: Right, right. I was just, I was just wondering if, you know, like the minimal approach of just I'm… the bit list in there and sort of a first sort of like step forward then including it in the four choice or is it Or do people want to keep it this way?

Jihoon Song: What is this way, sorry? I think you're, you're sound cutting out now.

soispoke: Not enforced. In the folk choice at all. My question is, like, do people generally agree we should enforce it in the fork choice eventually, and is it just more like, right now, let's test it, without it, because it's easier, or… Or do people actually think, like, we shouldn't enforce it in the fork choice?

Jihoon Song: I think it is not decided yet. I think we haven't reached to a rough consensus on whether to not include this bit lace in fork choice. or included in Fork Choice. That's why we were just discussing having the bit list. In container, but not in fork choice as the first step, while we are figuring out, yeah, its implication and how to… what would be the best way to implement it.

soispoke: That makes sense.

Jihoon Song: All right, any more questions or comments? Right. To sum up, The engine API spec 619, sorry, 609 is expected to be merged very soon. And then I'm going to get some resources from Steel to work on execution spec tests. And consensus specs, we'll have a little bit of change to specify how it should behave for not validating payloads. And for this payload attributes event for build door, we will gonna go for tentatively go for the third option. And for the bit list, we're gonna bring it back to the container, but not yet in the fork choice. And…

Regarding having bit lace in the fork choice, I'm going to explore possible implementations and then maybe we can Discussing in the next breakouts. Right, does it sound good?

Justin Florentine: Yes, sir.

soispoke: When you say different implementations, do you also mean sort of like… Like, do you feel like we should also sort of, like, high-level agree on whether it's Necessary in the fork choice first, and then sort of, like, go into the implementations, or was that sort of, like, included in what you meant?

Jihoon Song: I think it depends on The complexity and what does the protocol works? How does the protocol works? Because. Yeah, because like. we need to Figure out how the protocol will behave to, to, like, discuss, like, okay. How does it make sense to have bitlays in the fork choice and what is its implication, so on and so forth. So for now, we are just, we are at the stage where, we might have bit-wise in the fork choice, but we haven't really, found good answers when it comes to how that protocol works exactly, so that's why, Discussions were like a bit up in the air.

Justin Florentine: Are you… are you thinking that… so, for example, like, maybe, you know, the bit list weighs fork choice differently, depending on how complete it is, right?

Jihoon Song: Yes, like…

Justin Florentine: Yep.

Jihoon Song: We might reorg a block or we might not and then just like not enforce trust payment. if it makes sense, and there might be some… some other option that we haven't really thought about at the moment. So, yeah. And, like, trade-off here is, in my opinion, it could be, like, aligning incentive, or liveness, or… improving correctness or soundness versus adding complexity to the protocol. So, yeah. And I don't think this is, like, a blocker for making a progress, so we can take more time to find the best solution ahead of us.

Justin Florentine: So, for example, you, you know, for starters, we just say, okay, it's a superset of what the views, the, the, the merge view of the committee, or sorry, yeah, superset of what the merge view committee saw, it's valid, great, but maybe in the future, we start preferring, you know, more thorough Arrays of the bid list, right?

Jihoon Song: Yes, yes, makes sense. So, like, in the beginning, we can just… Say that the spec we're gonna say that proposer. Should pick up bits. that has a superset IL view to their local IL view, but it is something that we don't really check in the fork choice, so Procoser can choose whatever they want, and in the meantime, we can figure out what would be the best way to have, you know… Consider this beta laser in the protocol. And what, what, what is that meaning?

Justin Florentine: So I'm not a CL dev, so I can't really speak to whether or not this is liveness. On the surface, it doesn't speak to liveness, but it certainly leaves room for micro-censorship, right?

Jihoon Song: Could you expand on microcensorship?

Justin Florentine: Well, just the idea that, like, a proposer is looking at, it has a fork choice, maybe, between two chains, and they each have compliant ILs, but one is bigger than the other. Something's getting censored. And maybe it's gonna get delayed, or maybe not censored is the wrong way to put it, but it might get delayed Like, there's a Venn diagram there when you're looking at these two bit lists, if they differ.

Jihoon Song: When they're choosing.

Justin Florentine: No, later during pork choice.

Jihoon Song: Okay. But… Assuming both payloads are… Good. I mean, both are IL compliant.

Justin Florentine: Yep.

Jihoon Song: What does it mean that… One has… more, I mean, how to put this, like… more, more… One, and they're a bit less than the other.

Justin Florentine: So, if I'm understanding the bit list correctly, right?

Jihoon Song: Yep.

Justin Florentine: It's an array of IOs, right? And… It's bigger than…

Jihoon Song: Sections.

Justin Florentine: It's bigger than the, what the committee is requiring, right?

Jihoon Song: Could be, yeah.

Justin Florentine: Well, it should be for the bid to have gotten through the bid, right?

Jihoon Song: Yes.

Justin Florentine: In a… in a trustless… in a trustless setup, right?

Jihoon Song: Yes.

Justin Florentine: Okay. So when you get down to fork choice, you could be looking at two different heads. that each have… A bit list that is a superset of… What the committee saw.

Jihoon Song: Yes.

Justin Florentine: in different ways. And so now the fork choice could choose one that is effectively censoring some of the ILs. They have some optionality here, I guess is what I'm trying to say.

Jihoon Song: Go with your man, I think.

Justin Florentine: And if all we ask for is compliance with what the committee saw, that optionality exists. If WorkChoice is updated to be more thorough and prefer the maximally inclusive. Of the two choices at the head? Then the optionality goes away.

Jihoon Song: Mmm.

Justin Florentine: My head is in the optionality space because of lucid work right now. But I would ask that those blinders be considered by people that understand the fork choice protocol a lot better than I do.

Jihoon Song: Hmm, I see. Yeah.

Nico Flaig: Yeah, I mean, the thing is, we already lock in ahead before we even look at the bits for that parent root and parent hash, right? So… I'm not sure what you… if that, like, what two competing branches you meant. But yeah, we would pick the branch we build on before that.

Jihoon Song: I guess Justin is saying… He was describing some possible behavior when we are tie breaking.

Justin Florentine: Yep.

soispoke: But that's in cases where the proposal equivocates, no?

Jihoon Song: No, not necessarily. It's just a tie-breaking between two branches, so they will have They might have different proposers. Or they might from different slots. Although it is not likely, but still, like, if it's like. non-finality or whatever then, yeah, maybe it is possible. So it is not always proposals equivocation.

soispoke: Yeah, okay.

Nico Flaig: Yeah, but essentially, you call getHead, right? Then you get your head you want to build on, so you have the parent root locked in, and then you run shouldExtendPayload on that, right? Whether to build on empty or full. Or whether to build on, like, if there's a… another block that build on empty, right? But at that point. Does that mean we would consider the IELTS there? That's not really… I'm not really sure how that would work.

Jihoon Song: This. Part is before that. So like it is during get head call. So after you choose your hat, then. Yeah, things just go as we… have today, but when we are choosing GitHub.

Nico Flaig: But in that case, you already, the EL already verified, right? If the payload satisfied the IL.

Jihoon Song: Yeah, so both payloads are good. And in this case, somehow you have two competing block with good payload. And in this case, Justin is suggesting to consider picking a block with more thorough bit list. But then the next question is. What does that mean? Like what? What? What does it mean to have, like, more ones in your bit list like that? If you miss somebody else, does it always mean censorship? Maybe not.

Justin Florentine: No, there's no way to know. There's no way to know that whether it's censorship or not, I guess my question is just like, you know, is that a thing we should prefer?

Jihoon Song: Mmhm.

Justin Florentine: Because somebody had a better view of the network, right?

Jihoon Song: Yes, and do we want to… Put more weight on that. Better view. Not sure, like, this looks like something new to me, because, like, when you, when you're choosing a hat. We just counted… How many attestations it accrued. And we, I don't know, like. this is something new to me. I need to think more about this, whether this is a good idea or not. But it's I don't know. It's just new. Right,

Regarding the next breakout, can we push it back by a week? Because I will be out of office around the 14th, so can we… Have the next breakout on the 21st. I got many a thumbs up. So Thank you, guys. The next breakout will be held on the 21st. Before we wrap up the call, do we have any more comments? It doesn't have to be on bit list.

NC: Sorry, so to summarize, there's an updated execution API, and it reintroduced the bit list. And then… Probably, we update Lodestar and some other clients, and we do another round of interop.

Jihoon Song: Do we believe that Clem 6 is good?

NC: I mean, for Lodestar side, we do have some capacity for FOCIL.

Jihoon Song: Oh, nice. Yeah, we need… 2x2 to launch the first DevNet, but we can always try local interop. We are basing on the latest Glamsterdam devnet, whatever that is, which is 6 at the moment, so if you guys can rebase your implementation on top of Glamsterdam devnet 6, and have some bandwidth to apply new changes on the spec, then yeah, we can try the local interop. Yeah, of course. Yeah, I… think the engine API change will affect both EL and CL? So yeah, I think it will take some time.

Any more questions or comments? Otherwise, I think we can go ahead and wrap up this call.

Justin Florentine: Thanks everyone.

soispoke: Thank you.

Mehdi Aouadi: Thank you guys.

Jihoon Song: Bye. See you at the.

Justin Traglia: Throw.

Jihoon Song: First.

NC: See y.

Jihoon Song: Thank you.

Justin Traglia: See you then.

Jihoon Song: Bye bye.

Transcript adapted from ethereum/pm, CC BY-SA 3.0.