Justin Traglia:All right, thank you. Hello, everyone. Welcome to ePBS Breakout Call 26.
Transcript
Justin Traglia: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.
Justin Traglia:Epbs DevNet Zero, that is.
Justin Traglia: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.
Justin Traglia: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.
Justin Traglia:And there are starred, though, there still are two open, like, to-do.
Justin Traglia:Things that need to be fixed if anyone wants to make a PR.
Justin Traglia: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: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
terence: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.
terence: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.
terence: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.
Justin Traglia:Promise that they're both traveling this weekend, I see.
Justin Traglia:Okay, thank you. Is there anyone from Lighthouse here? Maybe Mark? They can give an update?
ethDreamer (Mark):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.
ethDreamer (Mark):But yeah, still a ways off.
Justin Traglia:Got it.
Justin Traglia: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.
Shane Moore:We are in the Congo line.
Shane Moore:load processing.
Shane Moore:in the end, when we're ready, we'll merge all that into a developed branch. So, a little bit more,
Shane Moore: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.
Stefan Bratanov:Yeah.
Stefan Bratanov: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…
Stefan Bratanov:I can't speak much about when we would be ready for deadlines.
Justin Traglia:Yeah, no worries.
Justin Traglia:I don't see anyone from Nimbus here.
Justin Traglia:Correct.
Justin Traglia:Okay, could someone from Lodestar, or Caleb?
Caleb:Hi.
Caleb: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,
Caleb:I think we just have the networking aspect to complete. We're about 70% there. We are yet to touch for choice at all.
Caleb:But soon, I guess. So that's it from us.
Justin Traglia:Okay.
Justin Traglia: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.
NC:So everything from EPUB processing, block processing, except for the,
NC:Processing the execution payload envelope.
NC:And we are passing, about two-thirds of the operations spec us.
NC:So we need to continue to debug, like, what's wrong.
NC:And afterwards, we'll touch the other stuff, such as fork choice.
Justin Traglia:Okay.
Justin Traglia:Thank you. And last but not least, Grand Dean.
Saulius Grigaitis | Grandine:Yeah, so we are also progressing on UPBS implementation.
Saulius Grigaitis | Grandine: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.
Justin Traglia:Thank you, everyone.
Justin Traglia:I guess we can jump into the next agenda item.
Justin Traglia:Mehdi, would you like to talk about your proposed changes to attestation data?
Mehdi Aouadi:Yeah, sure.
Mehdi Aouadi:So yeah, basically, I wanted to, to, to address the issue with the, attestation data index field.
Mehdi Aouadi: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.
Mehdi Aouadi:To avoid the complexity. And now we are using it to signal the payload status.
Mehdi Aouadi:Which is, to me, very confusing, from a spec perspective.
Mehdi Aouadi:And, even from an implementation perspective, it could be really
Mehdi Aouadi:Hard to handle, since, we could end up, like, doing a lot of,
Mehdi Aouadi: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.
Mehdi Aouadi:And for simplicity, I kept the same type, which is UN64, to avoid any SSE serialization
Mehdi Aouadi:added complexity. So, yeah, basically that's, that's my proposal.
Justin Traglia:Thank you. I don't know if it's…
Justin Traglia:I mean, have we ever renamed a field before in the consensus specs? I don't know how difficult that is for teams.
Justin Traglia: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.
Mehdi Aouadi: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.
Mehdi Aouadi: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
Mehdi Aouadi: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…
Mehdi Aouadi:Yeah, that's my take on it.
Justin Traglia:Got it.
Justin Traglia:How do others feel about this?
Enrico Del Fante (tbenr):Yeah, I think… I'm com- coming from the…
Enrico Del Fante (tbenr):Difficulties, let's call it like that.
Enrico Del Fante (tbenr):After Electra, that we had a lot of long-tail bugs associated to… Index field, specifically.
Enrico Del Fante (tbenr):Due to the fact that from the code perspective, everything referring to that was perfectly fine, but then the interpretation of it, changed it.
Enrico Del Fante (tbenr):And, nothing was breaking.
Enrico Del Fante (tbenr):But it was, actually, and I think it was the source of several
Enrico Del Fante (tbenr):bugs, I don't think only in Tegu.
Enrico Del Fante (tbenr):To a f…
Enrico Del Fante (tbenr):Facing those changes early by changing the underlining data structure forces us to deal with these things.
Enrico Del Fante (tbenr):Earlier, and once things work, we have the guarantees that everything is fine.
Enrico Del Fante (tbenr):Plus, we have a better… spec, reading.
Enrico Del Fante (tbenr):So, I think worth, worth,
Enrico Del Fante (tbenr):Discussing this and evaluating clearly this.
Justin Traglia:How do others… How do other devs from other teams feel?
Justin Traglia: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.
potuz:So if other teams want to make this change, I'm happy, but
potuz:For us, it's really a nightmare to include… to change these containers. I definitely recognize that the spec becomes much nicer.
potuz:Or at least less ugly.
potuz:And this is already, like, spec depth.
potuz:from Electra that we probably should have changed it.
potuz:Because then we actually did
potuz:Have to change a lot of the attestation paths.
potuz:So probably then it would have been a little extra, Complexity and implementation.
potuz: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.
potuz:And to be able to deserialize it.
potuz:We need to know, essentially, in which kind of fork we are.
potuz:Because, well, we have a different container, with a list of or not for elect or not, but after we deserialize it.
potuz: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,
potuz:processing function.
potuz: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.
potuz: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.
potuz: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.
potuz: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.
potuz: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
potuz:To implement that interface of the attestation data type.
potuz: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
potuz: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.
potuz: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.
potuz: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.
potuz:If other teams, besides just Deco, want to have this, I'm happy. I'm happy not to die on this hill.
ethDreamer (Mark):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
ethDreamer (Mark):just the attestation, not even the attestation data, was already a lot. If we changed the attestation data, we would have to do more.
ethDreamer (Mark):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…
ethDreamer (Mark):Still, like…
ethDreamer (Mark):I mean, we didn't change this in Electra because it was a bunch of extra work, and we could change… and…
ethDreamer (Mark):we're adding a bunch of extra work now. Yes, it's…
ethDreamer (Mark):Like, the fact that it's named index is inelegant, but you're adding…
ethDreamer (Mark):I don't know, I don't think the juice is worth the squeeze. Like… Is it cleaner? Yes.
ethDreamer (Mark):But, yeah, it's just…
ethDreamer (Mark):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.
ethDreamer (Mark):We have so many things to do, man.
ethDreamer (Mark):And this is a small inelegance.
ethDreamer (Mark):Which…
ethDreamer (Mark):If we ever need to change the… like, if there ever comes a time where we need to change the attestation data.
ethDreamer (Mark):that is when I would propose we fix it.
Justin Traglia:Thank you.
Justin Traglia:Yes, Aliens?
Saulius Grigaitis | Grandine:Yeah, so for Grandina, it also would be hard to implement such change, and maybe a little…
Saulius Grigaitis | Grandine:a bit less than the new attestation type we had in Elektra, but we would be against
Saulius Grigaitis | Grandine:This change, just because of the huge complexity in the codebase.
Saulius Grigaitis | Grandine:So, I mean…
Saulius Grigaitis | Grandine: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.
Justin Traglia:I think I liked Mark's idea of, like, if and when we need to change attestation data in the future, we…
Justin Traglia:Push fixing this until then.
Justin Traglia:So that would mean not including this in Coas right now.
Justin Traglia:Huh.
Justin Traglia:Does that sound fine to everyone?
Justin Traglia:Alrighty.
Justin Traglia:Maddie, thank you for the PR, but please close it whenever you have time.
Justin Traglia:Next agenda item, I guess, would be Mark's topic.
Justin Traglia:Mark, do you want to bring this up again?
ethDreamer (Mark):Yeah, I mean, I was just looking at the gossip…
ethDreamer (Mark):conditions for payloads, and notice we didn't have one
ethDreamer (Mark):About… oh, this is for beacon blocks,
ethDreamer (Mark):And I put the relevant pieces for beacon blocks in there. I should have linked also the gossip conditions for payloads, but,
ethDreamer (Mark):Let me see if I can find that real quick, because I have it opened in one of these tabs here.
ethDreamer (Mark):Give me one… Certain…
ethDreamer (Mark):Okay. It's not… I have too many tabs open, but we just don't have a,
ethDreamer (Mark):We don't have, like.
ethDreamer (Mark):a condition like this for payloads, and I'm wondering if we need one. Maybe we don't, but…
ethDreamer (Mark):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.
ethDreamer (Mark):And I'm wondering if we intentionally excluded this or not. Like, we…
ethDreamer (Mark):We just have that the envelopes block route has been seen.
ethDreamer (Mark):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.
ethDreamer (Mark):Yes.
potuz:And you couldn't have seen a blog From a future slot.
potuz:Therefore, if you only import your payload after you've seen a block, then you.
ethDreamer (Mark):Nothing.
potuz:you're not importing a payload from the future. So I think this is implied already.
ethDreamer (Mark):I suppose, yeah. And what was the second condition? Oh, maximum clock disparity, yeah. So…
ethDreamer (Mark):And the second condition was…
ethDreamer (Mark):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?
ethDreamer (Mark):That we have… we have something blocking the future payloads, do we have an older payload that we're…
ethDreamer (Mark):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?
ethDreamer (Mark):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.
ethDreamer (Mark):Okay.
potuz:That's a good catch.
Justin Traglia:Yep, agreed.
Justin Traglia:What do you open a PR for this, Mark?
ethDreamer (Mark):Sure.
Justin Traglia:Okay, thank you.
Justin Traglia: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…
Shane Moore:dual PTC deadlines and things like that.
Justin Traglia:I'm unaware of anything, but we should definitely get a group together.
Justin Traglia: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.
ethDreamer (Mark):Yeah, I have another questionnaire for this, too, actually.
Justin Traglia:Okay.
ethDreamer (Mark):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.
ethDreamer (Mark):My… okay, so my question is, if we are doing this second validation that it's greater than the…
ethDreamer (Mark):finalized slot. Well…
ethDreamer (Mark):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.
ethDreamer (Mark):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.
ethDreamer (Mark):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
ethDreamer (Mark):Far back the boundary is with payloads, is my question.
potuz:why… I don't understand, I mean, this,
potuz: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
potuz:Because that's a branching port choice that we want to see.
potuz:I mean, the timeliness or not of it, I think it's independent. This is something about, like, boosting
potuz:Or, or allowing for payments, but,
potuz:But I think we do want to be able to propagate branches that we hadn't seen.
ethDreamer (Mark):Yeah, okay.
potuz:older than finalized has to do with the fact that we are not anywhere.
ethDreamer (Mark):It's going to advance on that one.
potuz:branch that is contending with our finalization.
ethDreamer (Mark):Okay, yep.
ethDreamer (Mark):Yeah, I was just thinking through that, because…
ethDreamer (Mark):I, yeah. Okay, that makes sense.
Justin Traglia:Anything else from anyone?
Justin Traglia:Alrighty, thank you everyone for joining. Talk to you all again in two weeks.
potuz:Thank you, guys.
Justin Traglia:Bye, bro.
Chat Logs
00:06:12
potuz:have one approved :)
00:06:49
potuz:they'll be merged starting today
00:07:05
potuz:problem is both Terence and I are traveling this weekend :(
00:07:20
Barnabas:Replying to "problem is both Tere..."
I’m happy to merge in whatever is open 😂
00:07:47
Barnabas:Replying to "problem is both Tere..."
just give me write access lmao
00:15:46
terence:same
00:17:34
NC:I think renaming is fine, but I probably wouldn’t implement this in Lodestar. So internally (in Lodestar’s codebase) it would still be index and not payload_status , and probably wrap it as payload_status when dealing with beacon apis
00:20:14
potuz:renaming still deals with JSON changes on the API and a bunch of other boilerplate that is kinda of a nightmare
00:21:06
kev:Would changing it lead to less bugs in the future?
00:22:16
Barnabas:+1 mark but I’m not a client dev
00:23:28
ethDreamer (Mark):https://github.com/ethereum/consensus-specs/blob/master/specs/gloas/p2p-interface.md#execution_payload
00:25:58
terence:potuz and i not going to be there : (
00:26:08
Stefan Bratanov:No one from Teku would be at Devconnect
00:26:25
Barnabas:oh really?
00:26:37
potuz:Replying to "No one from Teku wou..."
essentially no one from Prysm either,
00:27:00
Barnabas:Replying to "No one from Teku wou..."
whaa
00:28:23
potuz:Replying to "No one from Teku wou..."
well, no core dev events there
Summary
12 highlights
· 3 action itemsExperimental
Summary
12 highlights · 3 action itemsExperimentalspecifications
client updates
- Prysm: 8 PRs implementing beacon chain passing spec tests; blocked on Fusaka release00:06:25
- Lighthouse: Block processing in progress; multiple devs now contributing00:07:36
- Teku: Progress on master merges; fork choice and database work not yet started00:08:42
- Lodestar: State transition ~70% done; passing 2/3 operations tests; fork choice pending00:09:57
- Grandine: Several weeks away from ePBS implementation completion00:10:32
proposed changes
gossip validation
- Missing gossip validation: payloads should reject blocks older than finalized checkpoint00:22:34
organizational
- DevConnect attendance: minimal Prysm/Teku/Grandine presence; interop planning needed00:25:46