ePBS Breakout #26

Transcript

Justin Traglia: All right, thank you. Hello, everyone. Welcome to ePBS Breakout Call 26. To jump right in, I'd like to state that there is a new consensus specifications release, Beta.1, which I believe we have decided to use, for DevNet0. Epbs DevNet Zero, that is. Yep. There are some open PRs, and there were quite a few close PRs this week. I'm not gonna go into each and every one of these, but feel free to review if you want. There… yeah, just some open testing PRs, and then I've personally started reviewing the specs and just fixing up, random things that I see. And there are starred, though, there still are two open, like, to-do. Things that need to be fixed if anyone wants to make a PR.

Okay, I guess we can just jump right into, updates from client teams. Is there anyone from prison that can give us an update?

Terence Tsao: Let's see… we haven't really merged anything to develop, unfortunately, because we're, like, blocked by Fusaka release, and we wanted to wait for the new spec, because of the data column side card. We added a slot, and then we changed the field location for the slot, so we wanted to wait until that before with formal reviewing, and And the merging that to develop. So we were able to finally start reviewing that yesterday. So, hopefully, once that's merged, we'll see more PRs getting much developed, but we have about, like. 8 open PRs right now that's actually implementing the beacon Chin.MD and passing SPED tests, so hopefully it's just a matter of reviewing and merging that, then we can start working on, say, four choice in parallel, P2P in parallel, validated on the spec in parallel, and getting ready for Definite Zero.

But yeah, but I would say majority of the process right now, progress is blocked by merging into development.

Justin Traglia: Got it. That makes sense. But that's great. Promise that they're both traveling this weekend, I see. Okay, thank you. Is there anyone from Lighthouse here? Maybe Mark? They can give an update?

Mark Mackey: Yeah, I mean, progress is ongoing. We're in… working on block processing right now, and some people are joining the effort, so hopefully that should accelerate. But yeah, still a ways off.

Justin Traglia: Got it. And, any other updates, Shane? I think you're also part of Lighthouse, right?

Shane Moore: Hey, yeah, just echoing what Mark said, and we are starting to at least, get some PRs into, like, a conga line of, PRs, so it's supposed to, you know, going straight into, like, a develop branch, kind of, taking it as, like, first starting with the types, for containers, and then we'll have for it. We are in the Congo line. load processing. in the end, when we're ready, we'll merge all that into a developed branch. So, a little bit more, sequential, I guess.

Justin Traglia: Got it. Thank you. Alright, who from tech who would like to get an update?

Stefan Bratanov: Yeah, I can give an update. We've been merging… merging a couple of things to master, in Teku, making some progress. Yeah. pretty much that's it. A few things here and there, but majority… I think I haven't started on fork choice or any database changes, so… I can't speak much about when we would be ready for deadlines.

Justin Traglia: Yeah, no worries. I don't see anyone from Nimbus here. Correct. Okay, could someone from Lodestar, or Caleb?

Caleb: Hi. So I'm Caleb. I'm working on this stuff on Nimbus. I'm joining the team soon, officially. So I've been merging a couple of stops to the unstable branch, I think we just have the networking aspect to complete. We're about 70% there. We are yet to touch for choice at all. But soon, I guess. So that's it from us.

Justin Traglia: Okay. Thank you, and you're welcome.

Caleb: Thank you.

Justin Traglia: Okay, I guess load start next. Who wants to have an update?

NC: Hey, so LOSAR, we have, implemented everything in the… well, at least the first half of the state transition. So everything from EPUB processing, block processing, except for the, Processing the execution payload envelope. And we are passing, about two-thirds of the operations spec us. So we need to continue to debug, like, what's wrong. And afterwards, we'll touch the other stuff, such as fork choice.

Justin Traglia: Okay. Thank you. And last but not least, Grand Dean.

Saulius Grigaitis: Yeah, so we are also progressing on UPBS implementation. But I think we likely are, like, a few weeks from implementing it. So yeah, there is good progress, but we still need to do a lot.

Justin Traglia: Okay. Thank you, everyone. I guess we can jump into the next agenda item. Mehdi, would you like to talk about your proposed changes to attestation data?

Mehdi Aouadi: Yeah, sure. So yeah, basically, I wanted to, to, to address the issue with the, attestation data index field. Where basically we have… we have a field named index, that doesn't hold an index at all, and so in Elekta, we chose to hard, code it to zero. To avoid the complexity. And now we are using it to signal the payload status. Which is, to me, very confusing, from a spec perspective. And, even from an implementation perspective, it could be really Hard to handle, since, we could end up, like, doing a lot of, of checks, to check, which fork we're in, to know how to, to consume that field, basically. So, yeah, my proposal is to rename it to Payload Statues.

And for simplicity, I kept the same type, which is UN64, to avoid any SSE serialization added complexity. So, yeah, basically that's, that's my proposal.

Justin Traglia: Thank you. I don't know if it's… I mean, have we ever renamed a field before in the consensus specs? I don't know how difficult that is for teams. If it's difficult at all.

Mehdi Aouadi: Yeah, I mean, renaming the field would be the same thing as… it basically, I guess, it means introducing a new container, because it's, like, like, removing a field or adding a new one. So, and that was one of the, arguments against this change, because it could, imply adding new… a new GlowOS container for the attestation data.

Justin Traglia: But to be honest, I mean.

Mehdi Aouadi: There is added complexity, anyway, if we keep it like that. like, checking the fork each time to know how to consume the index field, would definitely add complexity and confusion in the code. And adding a new container also would add some boilerplate code, but I guess that it's worth the effort, in my opinion, because it makes the spec really clear and less confusing, and I'd personally prefer that approach, since either way, we would have some added complexity, so… Yeah, that's my take on it.

Justin Traglia: Got it. How do others feel about this?

Enrico Del Fante: Yeah, I think… I'm com- coming from the… Difficulties, let's call it like that. After Electra, that we had a lot of long-tail bugs associated to… Index field, specifically. Due to the fact that from the code perspective, everything referring to that was perfectly fine, but then the interpretation of it, changed it. And, nothing was breaking. But it was, actually, and I think it was the source of several bugs, I don't think only in Tegu. To a f… Facing those changes early by changing the underlining data structure forces us to deal with these things.

Earlier, and once things work, we have the guarantees that everything is fine. Plus, we have a better… spec, reading. So, I think worth, worth, Discussing this and evaluating clearly this.

Justin Traglia: How do others… How do other devs from other teams feel? Otis, how do you feel?

Potuz: Yeah, I'm very strongly against this, but I mean, it's not a hill that I'm willing to die for. So if other teams want to make this change, I'm happy, but For us, it's really a nightmare to include… to change these containers. I definitely recognize that the spec becomes much nicer. Or at least less ugly. And this is already, like, spec depth. from Electra that we probably should have changed it. Because then we actually did Have to change a lot of the attestation paths. So probably then it would have been a little extra, Complexity and implementation. And it was worth it. But this time, I don't see how… how can it possibly be worth it? I don't know how Teco manages this, and how is this issue of, like, checking the fork or not, but the way we process attestations is we get an attestation.

And to be able to deserialize it. We need to know, essentially, in which kind of fork we are. Because, well, we have a different container, with a list of or not for elect or not, but after we deserialize it. we… we just run a simple check. I mean, this attestation is of this type, or this attestation is of that type, and we send it to the corresponding processing, processing function. the only thing that would change now with the current status is just add one extra line. If the attestation data slot is after the… after the glow as fork. to send it to process at the station in Gloas, which is an entirely new function. And if it's before, then you just send it to the previous function that you had.

So it's just a single line, and I don't care… I mean, within that function, which is the gloss function, you're gonna treat the index one way, and without this function, you're gonna treat it, and the index check that it's 0 if it's pre-electra, if it's Electra. So I don't see how that extra complexity is going to be saved. We anyways need to implement this new helper function that is the process attestation in Gloas, and you anyways need to do this branching, depending on the fork that you are. So the extra complexity that would come from changing the attestation data type is a lot of boilerplate. Well, for us, at least, it's just an incredibly large amount of boilerplate. We're gonna need to add interfaces for the attestation data, which… that we currently don't have, because we're gonna have, like, different types that will need to

To implement that interface of the attestation data type. Did I get kicked out.

Justin Traglia: It looks like he got dropped for a second.

Potuz: I don't know where I stopped, but anyway, so… at least from my point of view, I don't see how adding this, it's not increasing difficulty, and strictly increasing difficulty, without removing any of the difficulty. And I don't see how it can prevent bugs of the form of, like, how do you deal with the index, because you do the branching before this. You do the branching on to which function you are… you're processing the attestation before, you need to check what the value of the index is. But again, I mean, even though I'm strongly opposed to this, because I do feel like for us it's going to be a lot of complexity. If other teams, besides just Deco, want to have this, I'm happy. I'm happy not to die on this hill.

Mark Mackey: I… like, Lighthouse could do this as well internally in our codebase, and have a, like… I mean, we have a process for changing data structures from one fork to another, because we've done it many times, and as we saw with Electra, that changing the attestation just the attestation, not even the attestation data, was already a lot. If we changed the attestation data, we would have to do more. And then we would need to… I mean, we could leverage the fact that we've already changed the attestation. It wouldn't be quite as difficult the second time, but… Still, like… I mean, we didn't change this in Electra because it was a bunch of extra work, and we could change… and…

we're adding a bunch of extra work now. Yes, it's… Like, the fact that it's named index is inelegant, but you're adding… I don't know, I don't think the juice is worth the squeeze. Like… Is it cleaner? Yes. But, yeah, it's just… like, if we didn't do it in Electra, I don't see a reason to do it now. Yeah, kind of echoing what Poda said. We have so many things to do, man. And this is a small inelegance. Which… If we ever need to change the… like, if there ever comes a time where we need to change the attestation data. that is when I would propose we fix it.

Justin Traglia: Thank you. Yes, Aliens?

Saulius Grigaitis: Yeah, so for Grandina, it also would be hard to implement such change, and maybe a little… a bit less than the new attestation type we had in Elektra, but we would be against This change, just because of the huge complexity in the codebase. So, I mean… Likely, at least our opinion is that it's… it's too little value compared to the… so much hassle in the codebase.

Justin Traglia: Okay. Thank you all. I think I liked Mark's idea of, like, if and when we need to change attestation data in the future, we… Push fixing this until then. So that would mean not including this in Coas right now. Huh. Does that sound fine to everyone? Alrighty. Maddie, thank you for the PR, but please close it whenever you have time. Next agenda item, I guess, would be Mark's topic. Mark, do you want to bring this up again?

Mark Mackey: Yeah, I mean, I was just looking at the gossip… conditions for payloads, and notice we didn't have one About… oh, this is for beacon blocks, And I put the relevant pieces for beacon blocks in there. I should have linked also the gossip conditions for payloads, but, Let me see if I can find that real quick, because I have it opened in one of these tabs here. Give me one… Certain… Okay. It's not… I have too many tabs open, but we just don't have a, We don't have, like. a condition like this for payloads, and I'm wondering if we need one. Maybe we don't, but… you know, we could have one, and I was wondering if it was intentionally excluded. Here we go, here's the gossip conditions for payloads.

And I'm wondering if we intentionally excluded this or not. Like, we… We just have that the envelopes block route has been seen. Right, we don't have that… this is, like, a timely payload, or… I mean, we do have that the slots are equal, but there's just… there's nothing regarding…

Potuz: But doesn't it preclude the condition? The first condition is about, like, a block being from the future, right? A block from the future slot.

Mark Mackey: Yes.

Potuz: And you couldn't have seen a blog From a future slot. Therefore, if you only import your payload after you've seen a block, then you.

Mark Mackey: Nothing.

Potuz: you're not importing a payload from the future. So I think this is implied already.

Mark Mackey: I suppose, yeah. And what was the second condition? Oh, maximum clock disparity, yeah. So… And the second condition was… greater than finalized slot, so that would… I guess, do we have a condition that says we can't receive a payload, like an older payload? That we have… we have something blocking the future payloads, do we have an older payload that we're… Not going to be accepting.

Potuz: Oh, so the second condition is about a block being older than the latest finalized one. We just don't take it over GoSip, right?

Mark Mackey: Right.

Potuz: Yeah, so I think… I think this is… this is a good one. We should… we should add a line saying that, if the block route is later than the latest finalized, then we don't gossip the payload for that block route.

Mark Mackey: Okay.

Potuz: That's a good catch.

Justin Traglia: Yep, agreed. What do you open a PR for this, Mark?

Mark Mackey: Sure.

Justin Traglia: Okay, thank you. I think that's it for the agenda today. Is there anything anyone would like to talk about before we end the call?

Shane Moore: Yeah, I'm just curious for, like, DevConnect, if there's any ideas for, like, interop, EPBS stuff, maybe things we haven't really sorted out, like… dual PTC deadlines and things like that.

Justin Traglia: I'm unaware of anything, but we should definitely get a group together. To, like, discuss all this kind of stuff.

Potuz: Yeah.

Shane Moore: Yeah. Service available.

Potuz: ideas on the deadlines, on the dual deadlines. It'd be nice to get ideas on the numbers, but I think this whole business of the pre-option problem put influence there. So I think it's going to take us time to be in a place where we're actually benchmarking what's the right numbers for those.

Mark Mackey: Yeah, I have another questionnaire for this, too, actually.

Justin Traglia: Okay.

Mark Mackey: atmosphere.

Justin Traglia: Pretty much we're done with this, but I'll work… I'll talk with, like, POTUS and Shane and try to get something organized.

Mark Mackey: My… okay, so my question is, if we are doing this second validation that it's greater than the… finalized slot. Well… I don't know, that's an interesting… because we have a payload timeliness committee, and payloads have to be timely. I guess blocks do, too. I don't know. I have to wonder why this is a… this is only restricting blocks on gossip to being greater than the finalized checkpoint, and not anything more recent than that, given that blocks themselves should be timely. And is that condition the same? Like, is that modified at all between blocks and payloads because we have a payload timeliness committee? Like, can we make a tighter assumption about how Far back the boundary is with payloads, is my question.

Potuz: why… I don't understand, I mean, this, the timeliness of the payload or not has nothing to do with the propagation of the payload, right? So we want to be propagating payloads Because that's a branching port choice that we want to see. I mean, the timeliness or not of it, I think it's independent. This is something about, like, boosting Or, or allowing for payments, but, But I think we do want to be able to propagate branches that we hadn't seen.

Mark Mackey: Yeah, okay.

Potuz: older than finalized has to do with the fact that we are not anywhere.

Mark Mackey: It's going to advance on that one.

Potuz: branch that is contending with our finalization.

Mark Mackey: Okay, yep. Yeah, I was just thinking through that, because… I, yeah. Okay, that makes sense.

Justin Traglia: Anything else from anyone? Alrighty, thank you everyone for joining. Talk to you all again in two weeks.

Potuz: Thank you, guys.

Justin Traglia: Bye, bro.

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