SSZ Engine API Call #1

Transcript

Justin Traglia: Good morning, sir.

Tamaghna Choudhuri: Good morning. Let's wait till the time stops, I guess, let's see how many people show up.

Justin Traglia: Yeah. Say some more words. It's a bit hard to hear you, actually.

Tamaghna Choudhuri: Oh, is this a bit better?

Justin Traglia: Yeah.

Tamaghna Choudhuri: Thank you. You're good.

Justin Traglia: I see that the call is recording. That's good.

To Magna, have you confirmed that Marius is going to be here?

Tamaghna Choudhuri: No, I mean, he wrote that he had some personal… Things, like, he said that he might not be coming, but he left all of his, things he would like to discuss in the comment and the issue. That would be best.

Justin Traglia: Alright, bye.

Tamaghna Choudhuri: Alright, then, I'll stop. Welcome, everybody, to the first ever Assisted Engine API breakout kickoff. So basically, the goal of this breakout room would be to help us do everything regarding the Assisted Engine API. This would involve, let's say. Reviewing the specs… We're discussing implementations, the testing and everything. So I am Tamagna Chaudhary. I am currently an intern on the testing and testing team with the consensus spec and I will be leading the breakout. So let's get started. So, regarding the first issue that I'd like to bring up is basically the goals and non-goals of this course. So, I'd say the goals of this course would be to, interact about interaction about, definite discussions, vetting, and, what features would be more, would be implementing for this.

So, that would be a short form, and… I'd like to start off asking if every team has had an opportunity to look at the current spec, that would be… this run. I have seen already another, and other people have already had the suggestions, and some from Yasek. just a Hands up if you have maybe looked at the spec. Alright, I'll take it, like, somebody from the team has already looked at the specs, so… the first thing that I'd like to discuss, regarding the specs is… basically, would we be moving… would we be okay with moving the fork into the headers out of the URL? This just seems something that, both Marius and Nazir had already hinted at, and…

I guess it should be something that everybody agrees on, but, like, The floor is open. Any discussions are needed regarding this. Or, we'll move into the next one then. How would the versioning of this be? Would this be of engine V2, or the engine V1, or let's say, or, Like, that's something also that was a question. What do everyone prefers?

8. Regarding this, another question that I do have is… Yeah, like, this is also a question I had. Let's say, would we keep both of the listed JSON channels and the SSZ channels intact and open at the same time? And like, or would the communication be on either of the two? And how would we say prevent… miscommunications regarding that, so… this is also something that Nader did bring up, and review here.

Łukasz Rozmej: So I think if we can all have both open. Then clients can roll it out on their own schedule? We don't have to have a rollout that is in any way coordinated. And then… my opinion is good. And how we… neither do we implement it, we basically call the same things from both, so… It's kind of just a different wrapper at the end, so… we will… we could work if we get, I don't know, new payloads through SSZ and FCU through JSON-RPC, or, like, whatever combination, we wouldn't care.

Tamaghna Choudhuri: Any other teams have any other viewpoints regarding this?

Jun Song: Yeah, for… Yeah, yeah. For Prysm, we already implemented this spec. So what I implemented is the way that we have a fallback to JSON-RPC if the capabilities call is failed or 404. So I think that we should have some transition window that SSZ engine and JSON RPC engine, should coexist in those windows. So I think, yeah.

Dustin Brody: as a general point, from a CL perspective, anything which needs exchange capabilities or similar is, kind of talk-to prone, So there's no stable endpoint, so to say, and that's a problem. And what that means is anything optional is a problem long term. And this is… this will become problematic if it ends up being that because of some ambition to have, let's, you know, all the ELs opt-in just whenever they kind of feel like it, they… that… that… that means that there is no hard fork boundary beyond which CLs can just assert that the way to communicate with the EL is with this new protocol, because then that means using this sort of… unreliable, intrinsically unreliable detection.

Oh. And fallback setups.

Tamaghna Choudhuri: Like, the question about making it Hegota would also come down to, like, let's say, deciding on the timelines for everybody to, ship it by then, and… I would think that, like, from what I see in Hegotah would be more of a decision that we might take in the later calls when we have implementations, but, like, reflecting what Dustin said, and…

Łukasz Rozmej: Yeah, but we don't have to wait to Hagata to ship it. We can ship it tomorrow, basically.

Tamaghna Choudhuri: Yeah, yeah.

Łukasz Rozmej: Exaggeration, right? And I want to ship it, maybe even before Glamsterdam. And, you know, have this transition period, and okay, in Glamsterdam, we shouldn't require it, because… teams, can be overwhelmed, teams are something, but between Glamsterdam, Hegota, for example, or, Next Fork. past Hegota, whatever, we can actually make it mandatory, and probably it will be, just by, design, like, everyone will have it earlier, so… That's… fine. My opinion, this is optimal, but… That's my opinion.

Tamaghna Choudhuri: Alright, that does seem reasonable, like, would any other, like, team have any other opinion personally regarding this? Alright, I mean, then… I guess we can move to the next one. The next one would be more about, repeated retrievals of payloads via GetPayload, and also the time to live comment that, Nazar had posted. So, what are everyone's thoughts on that? And I'll just drop a link to them right in the chat.

Then I'll take it that not everybody had the time to look into it, then maybe we can push. This to the next one, After this, I'd like to bring up, let's say, regarding unifying the new payload with witness. If Ruchi is here on the call, maybe you might like to speak on this?

Developer Uche: Yeah, sure. So the the goal is to more like Currently, the paths for the new pillar with weakness as the slash engine slash new pillar with weakness is not so compatible with the proposal for the REST SSA specification. So all we'd like to do is to look at. from the link. I'll drop it now in a bit. Okay. Yeah, from the link. I'll just send in now, and there's a comment there. Yeah, I'm Building. All right. So if you click on this comment, you could see what Lucas dropped. And I kind of like that also. So that's the engine, either V1 or V2, whichever we go with, then the fork, then the payload, then we click next.

So, if we all agree that this path is going to be much more compatible and easy for clients' team to work with, which I do agree, though. Then we could, go in that direction, and I can make that, not updated.

Tamaghna Choudhuri: Maybe the EL teams would like to have a say on this? If you have looked at it, Lucas has already looked at it, I guess, like, if you'd like to see something regarding this.

Jun Song: Just a quick question. So how can we specify the payload ID with those endpoint engine V2 fork payloads witness?

Developer Uche: What do you mean by the payload ID?

Jun Song: So, there's a query parameter in engine payloads endpoint. But we don't have this one in the witness. So I can paste in the chat. I'll post a call. Oh, alright.

Łukasz Rozmej: I think this is a postcode, because you're sending a new payload, and you are… Getting the witness. Yep. So, it should be a post call. So there shouldn't be a… parameter there. Might be good to clarify.

Tamaghna Choudhuri: So… I guess the default decision would be to use the… This version, let's have this as the default, if not, other client teams have any objections to this. Then we'll go forward with this. The next item on the list would be, how would we like to roll this out? Like, we all, like, we already heard on this call, maybe… Let's, we can have this as a flag for the clients, and then they start rolling it out as soon as they can, and maybe post checkout or post iStart, this becomes the mandatory version. Like, what would be the client dead, timelines on this? So, like, that would be something, and also the client updates. How much has the implementation for this moved, and…

Yep, so that door is open.

Łukasz Rozmej: So we have everything more or less implemented. The we've witnessed part, is a bit hacky and needs more work. I think, you know, there's still small, spec changes, like we're discussing, so we have to probably adjust to it, and then the main bottleneck is testing with a real, CL client, or maybe against some test suit, if it will be created.

Tamaghna Choudhuri: regarding the testing, so I can drop the updates, so… basically, I started writing the tests for, containers, and, the randomization is there, but, like, I'd like to add a few more things into the randomization using, let's say, hypothesis to get it done. The, there's… I have a draft version of the containers you are interested in. So, this would be… a version of the SSD static tests that is there for the CL, which has been implemented for all of the containers. I'll be further refining this, and I'm waiting…

reviews from the SEAL teams to get this merged, PRs getting that merged on an internal call. Are you doing full random values, or that would be a container? For now, it would be full random values. Maybe with, hypothesis, I can get them done to the valid values, but, like, I… that would be something I'd be able to say on the next call. using, let's say, Hive or maybe the consumer side, that also depends on how fast I can get the reviews from the Steel team and getting all of the code and the vectors up, so maybe I'll have a better Info regarding that next week. So that could be something regarding… The testing site, so… yep.

Also, like, we'd like to have maybe, discussion about the general status of the different clients. I know the EtherX have been working on it, June from Prysm has been working on it. If any other client teams or any other ETF fellows wants to have a look, maybe do let us know in this call here.

Justin Traglia: Is Prysm mostly ready, or what is the status of that? on the CL.

Jun Song: Yeah, so from Prysm, I think that we are most ready. For all the things are implemented based on the current stack. So I think the only remaining task is applying the fixes that will come after this call. So for example, excluding fork from the endpoint, et cetera. So yeah, most of the setups are ready for Prysm.

Justin Traglia: Is there an EL that you can… Mike. have a DevNet with, or have you tried doing that yet?

Jun Song: I've tried with Erigon. It worked quite well. And with gas, I guess we don't. it doesn't work well, because there's some kind of spec, deviation, from the Geth, so I think that, yeah, mostly matching with Erigon at current status quo.

Justin Traglia: OK, cool. Thank you. Yeah, from the chat, it seems that ethrex and Nethermind are also ready.

Tamaghna Choudhuri: Shobhit, you did mention that you tried to run the DevNet with Erigon and Prysm, and you're having some problems, so, like, would you like to speak on that, or, like, where are the results, and maybe you can be ready for a DevNet soon? Alright, let's go. I mean… Sure, but then, from the CL side, we have Prysm ready, and I'll take Etherex and Nethermind already. We also, I'll take Erigon into the loop, and… So… about the DevNet, do we want to launch it as soon? If we do want to do that, how… week would that be? Would that be by, let's say, next week beginning, next week mid-end, or do you guys need some more time? So, any…

What are your general thoughts about that? Alright, that's it's on. Now…

Justin Traglia: Yeah, I agree that I don't think we need a DevNet for this. It's not like a consensus breaking thing.

Tamaghna Choudhuri: Yeah, then that's… that's… that would be the better option, to have it on the Glance Zoom database. Alright, then… yeah, that's all of the talking points I had for today's call. If any other further discussions or anything that's related to this would be required, the floor is open, we can have questions.

Justin Traglia: I have a quick question. So yesterday at ACDC, we, Sort of agreed to do, 7, 6, 8, 8 stable containers. Are we gonna use, Stable containers, progressive lists here. and the Engine API.

Tamaghna Choudhuri: Personally, I am in favor of using stable containers, but, like, the thing is, if… I was waiting for the decision on… 7688, but, like, hmm… That would be a question to the clients, so, like, would you be… Well, if it works with you in your schedules, would you be ready to have it on 7 containers and 7, 6, 8, 8 things? So… I mean… If you'd have a say regarding that, that would be great.

Justin Traglia: Yeah, I'd be curious to hear what clients think. One option might be to just continue without stable containers for the next few weeks until 7688 is SFI'd. Whenever that is. Or we could optimistically go with 7688 now. And, revert if it's not SFI'd, but that's a bit risky.

Tamaghna Choudhuri: I mean… I'd be on the scaler of… Having it… On 7688, but, like, If any objections regarding that are there, maybe you can… voice it out, but, like, I'd say having it in progressive lists would be better. But, like, I guess then that would require some work on Prysm and other clients, so, like… Would you like to then push your deadlines a bit?

Justin Traglia: I think the default decision is just to keep it the way it is now. updated in the future. It would also probably just… Okay. make it more difficult short term. I, I don't know.

Tamaghna Choudhuri: All right, and then let's move with the courage, however it is. If it's specified in due time, we can transition to that. All right.

Barnabas Busa: That's all.

Tamaghna Choudhuri: I'll be.

Barnabas Busa: Do you understand why progressive list would help here? For the engineers, is it? For the engineer, yeah.

Justin Traglia: I think someone else probably. Describe it better, but we wouldn't have to define as many limits. But we'd just be using the more modern types.

Barnabas Busa: Yeah, I would just keep it as simple as possible. Especially as the speed improvements will just come. This isn't not necessarily from this set of containers.

Dustin Brody: Well, one… Oh, sorry. One general consideration here, and… so I would distinguish, sort of, two dimensions of this. One is the question of if slash when, say, to use 7688, and that's a different point, I mean, and I'm not actually super opinionated there, but one, Because, as has been pointed out, certainly this is not on the Glamsterdam… this is not in a mandatory way on the Glamsterdam… timeline. I mean, hopefully various teams will ship for Grand Strand, but it won't be required for that. So the, the other, however, the, the advantage that's still there is if there's. And. it avoids having to calibrate, either, sort of, the containers being too small or too large, and this has a certain specific technical advantage. Now, we aren't…

hashing anything, which is… which is good, for this purpose in general in the Engine API. But if there… but there's still… but even if we're not hashing things, as we've seen with the, deposit requests, from, for example, on the, in a slightly different whole discussion happening elsewhere. I mean, anytime there's this kind of limit, this arbitrary limit, there's gonna be this question of, is it possible to exceed it? And either you specify a very large arbitrary limit, is what Justin, is sort of getting at. or you risk having to redefine the type later. And if you have to redefine the type, that is a new API. Or at least a new version of an API.

Because that's how SSZ works. And and the with the advantage. in this context, specifically, would be… it would avoid pointless, sort of, oops, we ran into arbitrary limit, we have to create a new version of the API.

Justin Traglia: Oh, yeah, I totally agree. But yeah. Like Barnabas said, I guess we should just keep what we have for now for simplicity and consider using 7688 sometime in the future, like a month or two from now. I don't know.

Dustin Brody: Sure. That, I mean, yeah, I actually don't think it's particularly urgent, for the time. I think, I mean, there's a totally, totally different question for the timeline on the, per se, Amsterdam stuff side, and that's a different discussion, not in for this meeting, but for the, for the SSE Engine API, I, I completely agree.

Tamaghna Choudhuri: Alright, then, since GANs will have the normal types, I'll maybe introduce, 7688, one of the support plans for everyone. I'm personally in the favor of using 7688 types, but, we'll do that a bit later. So… Any other open questions, or anything anyone wants to talk about? Maybe we'll give it 5 more minutes, and then we'll call it a day.

Justin Traglia: Is there anything that we can do to… Make this faster, like unblock you or like just. in general.

Jun Song: I think that we have to update the Pr. 7, 9, 3 as soon as possible, so that we can Because it has a single source of truth. So yeah, I think that's the one blocker on my head right now.

Justin Traglia: Yep, that's Marius's draft PR, correct. It'd be nice if you were here.

Dustin Brody: So the other sort of, we don't have to discuss this here, point that I would generally just That should be discussed in some ways. Do we, like, jacek's comments about the Top-up sync, and he wants some specific semantic changes, and again, we don't have to discuss it now or here, but… That, that's… It should be discussed at some point. He wants specific features from the Engine API, and he describes them in the… 793.

Justin Traglia: Another question is, does this time for the breakout call work for everyone? I guess generally seems okay to me, but we could move it if necessary.

Barnabas Busa: Do we need weekly breakouts? Till everyone ships, or what is the plan?

Justin Traglia: I don't know. I don't know, I mean, weekly, bi- Whatever people want or feel they need. What is it currently? I don't actually know.

Tamaghna Choudhuri: I mean, we can have a vote in the chat, I will, and then maybe we can go on that schedule.

Justin Traglia: I'll work to make this a bi-weekly call instead of a weekly call.

Tamaghna Choudhuri: Alright, then I guess we can move it to a bike PC call if… that's what everyone suggests, then sure. I mean, nothing else to talk for… Then maybe we can call it a day today. Thank you so much for joining. Take care, bye-bye.

Justin Traglia: Hi, everyone.

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