All Core Devs - Consensus #178

Transcript

Parithosh Jayanthi: Let's wait another minute for everyone to join, and then we can start off.

Okay, let's start off. So we want to start today with, DevNet scoping. We're gonna start with Glamsterdam, DevNet 4, and one of the first agenda items… oh yeah, before I start off, Josh, etc, are we streaming? Are we good to go?

Josh Davis: Yep, you're good.

Parithosh Jayanthi: Okay, perfect. Yeah, so the first agenda items, Glamsterdam DevNet for scoping. Can someone give us a status update on ETH70 and ETH71? I think Tony proposed it to be included in the next DevNet.

Toni Wahrstätter: Yes, I can do so. I think both are ready, I can definitely tell so for ETH71, but what I hear, ETH70 is ready too, and all clients have implemented it. For ETH71, we had it on earlier about definites already, so… Yeah, things are good to go.

Parithosh Jayanthi: Okay, and I think Bozel had an associated PR with engine get blobs v4, right? I think that's the execution API PR I'm listing here. Is there…

Barnabas Busa: The main issue we did 782 is, we currently do not send any blobs on Amsterdam, because, Lighthouse, for example, cannot handle blob transactions yet. So, there's really no benefit in including 2. Also, it is not yet implemented by any client on the CR side, as far as I know. It's, only implemented by Geth and Nethermind on the ER side, so it's also lacking support on the ER side. We could say optionally to include it, in case, you just want to start merging in stuff, but I would not, I would not require it. Also, I just see no benefit for including it for granted. put it based on top of, got blobV3, and… And this is just adding GetBots before, basically. Functionally, it's the same for the CSI.

Yeah, it's, it's implemented by Prysm and Lighthouse, so far on blob.net Zero. But I would actually prefer to roll it out on blob.net0, rather than… And transfer them.nets.

Parithosh Jayanthi: Okay, how about we include each 70 and ETH71, and then keep 72 for blob DevNets? Would that work?

Barnabas Busa: Yeah, sure. Blobdev.0 is already running.

Parithosh Jayanthi: Okay, and I see that the Execution API PR has already been merged, so people can coordinate with you, Barnabas, about inclusion and block DevNet 0 for EATH72, and for Glamsterdam DevNet 4, we would, include ETH70 and ETH71.

Barnabas Busa: Yeah, it's… it's gonna be a bit of a mess, because we don't have Gloas on Blob Devna Zero. So I'm not sure how 872 would work if it depends on 871, which depends on Amsterdam. So we'll need to launch, Love Design, which is based on top of, Gloas. I'm tested there. But for that, we would need support for… from Lighthouse as well. And Lighthouse would need to support blob transactions for that. And at that point, we might as well include it for our glamsterdom.net. So, it's a bit of a… A bedlock situation.

Parithosh Jayanthi: Okay, but for this, it sounds like we can also just wait for a bit more maturity on the Glamstad and DevNet side before adding it, right? And I think Pozel has been looking into getting some support so that we can get some early tests in for each 72.

Barnabas Busa: Mozu, could you verify if the spec is already frozen?

Bosul Mun: I'm sorry, waldo's still Christian.

Barnabas Busa: Is the specification for 872, is it already frozen? Is it done? Or do we expect any more changes to it?

Bosul Mun: No, I… Have some local changes, and it's… the, the overall… This pack is gone. Some… just some, details.

Barnabas Busa: Do we have a… yeah, could we get those details ironed out and finalize the scope of 872, and then we can get, client teams to actually look at implementing it?

Bosul Mun: Yes.

Parithosh Jayanthi: Okay, but then it sounds like we're all aligned. Stefan also posted that block-level access list DevNet 7 has ETH70 and ETH71 as a requirement. So it makes sense to also include it in Glamsterdam DevNetCycle, so we don't feature Drift. And then EATH72 will still get some work from Bozel, and once the spec is frozen, we can discuss including it. Any comments or questions on this? Okay.

Barnabas Busa: So, the engine fork Trace Update V4, That will probably have to be changed, based on today's call, on this PR, on 11444. If we end up including the target gas limit in it.

Parithosh Jayanthi: Yeah, I actually wanted to have that as the next topic, so maybe we can just continue into that. Do you wanna, is Nico on the call, or do you want to introduce the topic panelists?

Barnabas Busa: I hope Nicole is on the call.

Nico Flaig: I'm here, I'm here.

Parithosh Jayanthi: Okay.

Nico Flaig: So what was it about the engine API change?

Parithosh Jayanthi: It's about the add target gas limit to payload attributes. So, you have two PRs. consensus specs, and the other to the execution API. Could you introduce it, and then we can start discussing it?

Nico Flaig: So I guess the engine API PR has all the relevant context. So essentially what it does, I listed the three main points in DPR itself. is that, currently… or yeah, the status quo is basically we have a static flag on the EL side to configure the gas limit, and we have it on the CL side. With this change, we basically moved the, gas limit, like, the target gas, to the CL only, and when you prepare payload, you… the CL will pass the target gas limit. So that means, it's easier for operators. It also means that It allows, to configure per validator, so you can have different, different configs, per public key. And also, for cloors, we will need this if we want to use vanilla ELs as builders, because the clock you produce, or the payload, rather, needs to adhere to the gas limit of the proposer.

And the static flag won't work here, because you need to… you might need to use a different gas limit per slot, basically, when you prepare payload and submit a bid. So yeah, I mean, this is mostly pending, because we need some approvals from EL devs. I think from the CL side, it's pretty… we got a lot of feedback, and I didn't see anyone that is not in support of this.

Parithosh Jayanthi: Yeah, I guess we would still bring it up on ACDE one more time, unless it's extremely urgent to merge it in soon, but, has any ELDev looked into this yet? Do you guys already get the problem? Or the reason why we want to include this change?

Barnabas Busa: Yeah, the target word might be a bit misleading here. Could we maybe use a different word for it?

Parithosh Jayanthi: Tony?

Toni Wahrstätter: Yeah, maybe just to clarify, so what would happen is the EL clients could then deprecate their, flags for the minor setting the gas limit. And instead, the gas limit would come from the CL, but not the final gas limit that includes, like, obeying the 1 over 1024 rule, but the gas limit that the validator wants to get to. For example. we are at 60 million, and a validator wants $150 million, then the value getting to the EL would include the $150 million. So, ELs would then pick that value and would have to adjust the gas limit that they put into the block accordingly. And I think, yeah… Gas… the target gas limit, sounds like a good name for it.

Parithosh Jayanthi: Is this okay for the ELs? Because then you guys can, like Tony said, deprecate all of your gas limit flags, and you're fully reliant on the CL to provide you the gas limit. Okay, if there's no objection on this front, is there anything on the CL side? Any issues, etc, that we still need to talk about? Yeah, maybe to Mario's point, what happens if there's no configured target on the CL? I would assume that clients ship with a default, so unless the validator overrides the default, it would use the default in the client, right?

Barnabas Busa: Yeah, so just to be clear, I think this should be then… 60 million. Currently, right? Not the 30 million target.

Parithosh Jayanthi: Exactly, yeah.

Łukasz Rozmej: So, one potential alternative is just to take the parent's block gas limit and don't change it at all.

Parithosh Jayanthi: But then, how would you signal as a validator that you want the gas limit to change? If you use a time block.

Łukasz Rozmej: Well, through CO. I mean, if your seal doesn't supply it.

Parithosh Jayanthi: Okay, got it, got it.

Barnabas Busa: This should be a mandatory field, I think.

Parithosh Jayanthi: Yeah, I think so too. I think it should just be part of the required fields. porters?

Potuz: Yeah, so there are two PRs, one that I mentioned in the chat, another one that Justin mentioned in the chat. One is about, changing the… the bid validation, for… over P2P. To do the computation to check that it's compatible with the target that the proposal preference expressed. I think we need this together with Nico's PR on the engine. And so this is exactly what we talked about in ACDC. And the other one is, changing the withdrawability delay for builder deposits, for builders. Which, I don't know if it's merged, but it's a… is, 5223 that Justin just merged and just posted in the chat. I think those two should be on the next DevNet, for sure.

Justin Traglia: I agree. I would like to merge the two.

Parithosh Jayanthi: Okay, so this is consensus specs 5223 as well as 5227, right?

Potuz: No, it's… the first one is a little bit up in the chat, it's 5236.

Parithosh Jayanthi: Okay, let me just summarize all the required EIPs. So it's a tool that, requires PRs, so it's a tool that Nico posted. 5223, as well as 5236. Okay, I guess from the EL devs… on the CL dev side, there seems to be no pushback, right? Is there any CL dev that doesn't want this change? Okay, then, I guess it's mainly a question of EL Devs. It would be great if, EL devs could have a look before Monday and already start approving the PR to indicate support. And to Mario's point, I don't think they would need to introduce a new flag, because they currently send this information to the builder.

So instead of sending it to the builder, they would send it via the engine API to the ER.

Potuz: But it's important that the EL does implement this, because otherwise it's going to break something like a Barat's tool to send bids. Because now we're gonna put the bid… in the bid, we're gonna put the target that is mentioned, by the EL. And that's, well… one, that one.

Barnabas Busa: The engine API will have a mismatch if the CLs are pushing this field, no? Not like, we're gonna notice.

Potuz: Well, so the thing is that the ELs should deprecate their flag, and actually just not listen anymore to their flag. If we send something over FCU, but then they return a block with the gas limit. That was, because of their default flag, then we might have a mismatch there, and we're only going to see it on propagation of bits.

Barnabas Busa: No, we can check this on this new pair as well. We're gonna be able to see that very quickly. We can verify that, quite easily, I think.

Parithosh Jayanthi: Yeah, this seems relatively straightforward to test as well.

Potuz: Yeah, no, to test is fine, it's just… I don't want this to be broken from the start.

Parithosh Jayanthi: Yes. Yeah, I agree. We agreed that we wait on all of these changes for Glamsterdam down at 4, so all of these changes go into the next DevNet.

Barnabas Busa: Yep.

Parithosh Jayanthi: Okay, then, I guess priority would be, EL devs to have a look at these changes ASAP, and leave approvals on the PRs. And we can bring it up again on Monday if there's any questions. Yeah, potents.

Potuz: Could we merge dual deadlines and even put the… if we want to keep the timelines as today, just put the same timelines for the payload availability and the DA availability, so that that requires no code changes on clients, but I would want to have already merged dual deadlines so that we can actually start benching soon. This is a sort of, like, a requirement if we want to cap Well, I guess for those… if you guys are not following, the… there is a problem if a payload executes into the next slot. in which any builder can actually reorg the next block, and we cannot solve this, on the consensus side. We need to cap execution in such a way that payloads cannot execute into the next lot.

And the way to do this is by just not allowing gas limits that would execute into the next lot. And the only way to do this is by reorging late payloads. And the only way to, like, enable this in a reasonable way is by having these dual deadlines as well. Otherwise, today, we just have 3 seconds.

Parithosh Jayanthi: Could you link which PR this is?

Barnabas Busa: Just near that.

Parithosh Jayanthi: Okay. Use different deadlines for payload and blob data availability.

Potuz: There's two of them. One is that, and the other one is forcing the proposer to reorg. I am… we will have an implementation for this in Prysm as soon as the other clients, have… as soon as we are allowed to, like, start reorging blocks. Today, the DevNet is not stable enough that we can actually test this. But I would want to have these PRs already merged in the spec, so that it's not a hard fork, and we can just start reorging blocks, and we can just start, sending these different timelines and PTC attestations whenever everyone has already implemented them.

Parithosh Jayanthi: Attorney?

Toni Wahrstätter: Yeah, I would very much support that, because the dual deadline seems like it gives us a lot of scaling for trading off a little bit of time for worst-case propagation time, but we have enough for that anyway. So, yeah, very supportive. The only thing I was wondering is, why would we ever end up in a situation where we execute into the next slot, assuming… we know exactly how much time we have for the execution. Basically, when we set the dual deadline, for example, let's say it's at 8 seconds, then we know we have exactly 4 seconds until the next slot, and based on that, we would never pick a gas limit That would end up with a worst-case execution time longer than 4 seconds.

Potuz: Yeah, no, that's absolutely fine. It's just that today we're testing already on, by default, on 200 million, and that's far more than the 3 seconds we have now to execute them.

Toni Wahrstätter: Okay, great, perfect. Yep.

Parithosh Jayanthi: I guess the main feedback here is from the other CL teams, right? Has any other CL team looked into this? Are there opinions? Okay, Nico said it looks good to him, Yeah, Justin also said it looks good, but needs clients to weigh in. Dustin, could you expand on a mechanism designed to be disabled?

Dustin Brody: Sure, yeah. So, yeah… I want to be very clear that I'm not… this is not for, against, or around, etc, dual deadlines in any specific way, what I'm… what I'm saying. This is a more, quasi-process point to a degree. What it is, is that… if POTUS is introducing this as, let's not change… no Ys of code need changing, etc, fine, but then there's no value in the spec and changing either. If the spec, And if he wants to start the benchmarking, which, again, that sounds… that sounds great, but then it's effectively custom, because… by… exactly by saying none of the code needs to change, that this is quasi-hard fork material. I mean, it's, you know, we're in DevNet territory, so hard fork doesn't mean quite as much here right now, but,

So it's… it's one or the other, but trying to pretend that, oh, the mechanism's there, but it's not implemented, but actually, the spec is there, so it's okay, we can start using it, is incoherent. I either have it be real, or don't bother with the spec change. That's my position.

Parithosh Jayanthi: Yeah, photos? I guess photos was mainly responding to…

Potuz: Oh, I'm sorry, I was muted. So, the point is that the deadline As in the CIP and this dual deadline, and even just the PTC deadline itself, is completely irrelevant at the moment. And the reason that it's completely irrelevant at the moment is that we are all ignoring PTC. we just build on top of whatever our head is. So if we see the payload, regardless of whatever PTC did, we are going to build on top of the full payload. So, changing the deadline or not, enforcing it or not, it's just completely irrelevant at the moment. And it only is going to start mattering when we actually start reorging blocks that the PTC voted against. So… so that's… that's the reason why I am… I don't mind any sort of deadline we put.

Having said so, I do think that we need to put different deadlines instead of the same deadline as I suggested, and as Justin mentioned. And the reason, again, is that today, it's irrelevant. We are not using it. And anyways, on any testing that we're doing on DevNet, the payload is being revealed at second zero with the block. So… so it's not going to change if we put it at 6 seconds.

Dustin Brody: Okay, sure. I mean, again, I'm not against dual deadlines, and I understand, sort of, the reasoning here. there's a… The… hmm. Okay, to the degree that this is, as you're saying, kind of ignored already, then it's kind of… there's a no-op aspect or quality to it, yes. I agree with that. However, this is… explicitly asking for… I don't… I guess I don't know what… if… I'll start over. If one is going to have to customize this anyway to do benchmarking, because as you say, nobody has been implementing it, or maybe some people have, but it's not broadly implemented, then… what is the gain in having it in spec one way or the other? Because you're not going to get interoperability across a DevNet at that point. You're going to be doing some custom thing with one or maybe two clients.

So what does it matter whether it's in the SPAC conversion?

Potuz: Oh, no, I wanted to have it in the specs so that we start running now without any changes, and when every client… because I want to give time to clients to merge this. So we… I don't want to delay the DevNet 4 because of this, but if we agree that this is going to be there, we launch DevNet 4, whenever we get a green light, because every client already has implemented this correctly, then we're going to start reorging payloads.

Dustin Brody: Okay, sure, I… Okay.

Parithosh Jayanthi: I guess it's more of a blocker for when we start the testing, but not for when we launch the DevNet, right?

Potuz: Exactly. I don't want to delay the DevNet, but as soon as everyone tells me we're already good with this, we're gonna start reorging blocks and actually checking this… actually benchmarking this.

Parithosh Jayanthi: Yeah. Makes sense. Barnabas?

Barnabas Busa: Yeah, so just for Dustin's point, we usually go from spec to the tooling side, so… If there's a new value that needs to be tested eventually, then it's better to be in the spec than not be in the spec, because we usually don't add the fields until they are merged into the spec. So, if we know that we want to be, you know, testing this in the coming weeks, we should actually merge it in, and then we can add support For these fields in all of our toolings, and then we can, start, Moving those, fields around in, like, glutosis and on the debts as well. Without requiring a hard work.

Dustin Brody: Okay.

Parithosh Jayanthi: Yeah, okay, sounds good to me. Then, Justin, would you be able to merge them in today?

Justin Traglia: Yep, I think we can.

Parithosh Jayanthi: Thank you. Yeah, I'm guessing there's also going to be a spec release, and then we can target the new spec release for the next appnet. Sounds good. The next, is there anything else to discuss on this agenda item?

Justin Traglia: There was a note I wanted to, merge about… Pre-validating pending deposit signatures. I can try to find the PR. Pretty much I realized that if there were a lot of new I've loaded deposits at the fork, it might, Stall some clients. I would just like, some reviews on this, and if it's a good idea, we can merge it. Or just a suggestion.

Barnabas Busa: I mean, you could technically make a deposit right now with Xerox03 credentials, right? So… Following. cash live.

Justin Traglia: No, because, Sorry, it would have to be in the pending deposit queue at the time of the fork. If you made the deposit now, it would be processed well before class. And it would actually just be lost.

Barnabas Busa: I mean, we have a 4-month… queue right now.

Justin Traglia: Oh, I mean, if you think, oh, yeah, maybe.

Parithosh Jayanthi: Yeah, please have a look at that PR, and I guess the note can also be merged in. If there's no pushback.

Justin Traglia: Yeah, maybe. It's also not critical. You can always see this later.

Parithosh Jayanthi: For sure. The next big agenda item… oh, sorry. Did anyone want to say something?

Barnabas Busa: Yeah, so the entry queue right now is 63 days, so I'm just not sure how big of a… Cash we are prepared to work with here. We don't know, like, how the queue system is gonna go, and may not in the incoming weeks and months, so this might be a bit more hard than…

Potuz: We start putting them as soon as we put them in the queue. As soon as we process a deposit request, we can just start, like, validating signatures right there on the free time, and just make sure that we keep them in the queue already tagged. That's an easy change.

Justin Traglia: Yep.

Barnabas Busa: Sure.

Parithosh Jayanthi: Yeah, Spencer?

Spencer Taylor-Brown: Yeah, I just wanted to ask a question, because I'm a bit, a bit confused on, like, where the EL side fits in with, DevNet. So, this new DevNet now, Glamsterdam DevNet 4, I'm assuming is going to use the BAL DevNet 7 branches for the EL, or is it using the… about DevNet free branches, and is this DevNet mostly to test the CL? And then I'm assuming the next Devon after that, Glamsterdam Devon at 5. We'll have the remaining ELE IPs included.

Barnabas Busa: It really depends on how people bought the 7 will go. If we still see some 80, 73, issues, then we're just gonna run again with a single DL, because there's no point of debugging two different issues on the same DevNet. So, depending on when Ball 117 launches, I think Stefan mentioned that they want to launch on Monday. We could possibly launch, either a few hours after that, or on Tuesday.

Spencer Taylor-Brown: Awesome, nice. So is it safe to assume that the remaining EL EIPs will be included in a Glamsterdam DevNet 5?

Barnabas Busa: Yeah, I would not think…

Parithosh Jayanthi: Everything is… Yeah, I think if everything is stable on PAL 7, and we're able to merge it into Glamsterdam 4 is also stable, then let's assume that the remaining EIPs go into Amsterdam 5.

Spencer Taylor-Brown: Thanks, awesome.

Barnabas Busa: Also, it would be nice to discuss if we want to include anything else in Glamsterdam 5 on the CL side. the remaining CLR period.

Parithosh Jayanthi: Yeah, but I'm guessing we can do this in the next CDC.

Barnabas Busa: I think it would be good to… to set out a target, because realistically, by the next ACDC, we want to have devnet 5 up and running already. or very close to it, so it would be nice to know which EIP we're going to be working towards in the next few weeks.

Parithosh Jayanthi: Yeah, that's fair. I just don't have it on the agenda item for what comes in next. Maybe we can do this on ACDC, so we have some time to prepare for it. And also, we just have a lot to test, so I would stop… I kind of follow Porter's message here. I think there's a lot of implementation and features to test. If we keep adding more stuff, then we're already kind of… We're chasing a moving target, and at some point, we have to start testing what we have. The next agenda item I had was, relating to builder deposits. So, we've already discussed, increased withdrawability delay is gonna go in. But there's also two EIPs, one second, there's…

There's the cap deposit request per block EIP? Do we… do you want to introduce that, Barnabis? I've mentioned the EIP yet.

Barnabas Busa: Yeah, so… The CIP basically proposes that we're gonna be limiting the number of deposit transactions on the ES side, instead of on the CR side, and multiple people raised that this could lead to different kind of those factors on the side, and… It would be rather difficult to implement it. In an efficient manner. So, I'm not sure if this is still, the best idea going forward.

Parithosh Jayanthi: Okay, maybe as an introduction to the topic, we're still missing the data for making… for knowing how big of a problem it is, right, with builder deposits? As far as I know, only Teku has a log line that prints out how long they take to process the deposits, and we're not… we don't have the data from the other clients.

Barnabas Busa: Never gone.

Parithosh Jayanthi: Yeah, Terrence?

Terence Tsao: I think benchmarking or, having a more complete design around this over the last few days. So, I think from where we are standing, and keep in mind that the machine I'm using this is like an M1Mat, so it's slightly more powerful than what typically people use, is that for 8,000 deposit, 8,192, I can batch verify everything in, like, 800 milliseconds already. And then if there is failure, then I think the most optimal algorithm I found is, essentially, you essentially, batch verify in the chart size of 8, and then you just recursively, and that… get us to, say, if today there is, like… I think… I found the worst case is, say, today, if all signatures are failing, then it will take about 6 seconds to verify that.

And, And, so, so, so that's one thing that I have, is the dashboard verifying number. The second thing I have is that I added, post-processing cache. Meaning that as soon as you get a payload, you can already start verifying the deposit, and just… and just cash the result, right? And so that kind of depends on when the payload is revealed. So if today the payload is revealed. At the 6-second mark, then it's probably fine. But if the tailor's revealed much later, then there is a chance that, basically, that we will not finish, and the proposal of the next slot will not have enough time to, like, propose a block. But that also assumes the attacker

will have to make ML deposits, so, like, essentially, burn some ETH. In order to, do this. But yeah, but I guess, like, in the happy case, it's perfectly fine. In the unhappy case, where it's up to how many invalid deposits are there, then the next proposal may be screwed.

Parithosh Jayanthi: How are you getting the processing times from Prysm? Is there a branch or something that we can run? Because we have reference hardware, We can probably add in a search law test for having invalids, and then benchmark, now we would have potentially two plans to benchmark, PRISM as well as Teku, and we have a few more numbers to work off of.

Terence Tsao: Yeah, so it's in the branch that I've shared in the Discord. I think it was in the thread or something, it's called Glamster then.net3Deposit. I will type the branch name in the chat right now.

Parithosh Jayanthi: Okay, perfect. So… yeah. Banavas?

Barnabas Busa: Can you imagine this is not just merged into your Amsterdamnest 3 branch?

Terence Tsao: I don't, like, merge, like, code that, like, I'm not, like, 100% sure into Definitely, so I think what I will end up doing is… like, I don't know, like, how urgent you guys think this is, like, can you guys live with a separate bench for a few days? Then… and then I will open PRs for review and get those merged, and you will be much cleaner from our end. Yeah, so… so, yeah, basically, you let me know how… urgent this is, like… I'm happy either way.

Parithosh Jayanthi: Yeah, I think a few days is perfectly fine, so we can watch.

Terence Tsao: I'll go for it.

Parithosh Jayanthi: Branch for a few days. We'll probably just start testing and benchmarking, with Prysm and Teku, and then add the other clients. And regarding…

Barnabas Busa: from others as well, if they are making progress on this.

Parithosh Jayanthi: Yeah, is someone from Lighthouse around? Would we also be able to get a Lighthouse branch for this? Okay, perfect. I think there's a Discord thread, Kingy, could you post the branch when you have one over there? We just need processing times from Lighthouse, and then we should have… Everything to gather the benchmark numbers. Okay, I guess the next follow-up question is for the overflow issue. One option is, of course, fixing it via 7688, so that's forward compatible, structures. But is there any other options we have on the CL side?

I know that there were discussions even.

Barnabas Busa: I'm doing.

Parithosh Jayanthi: soon.

Barnabas Busa: we could increase it to, like, a million or whatever, but I would prefer not to introduce a new variable when we're gonna be just removing it, 87688. So I would just say that for Glenser, I'm definitely not, 4. We're gonna cap the gas limit to $190 million. And then we're not gonna be able to reach this. Nobody can accidentally trigger it. And then, once we include, 7688, possibly in… 5, or 6, or 7, or wherever we decide to include it, then we can actually push the gas limit up to 200 mil.

Parithosh Jayanthi: Okay, sounds good. Anything else on builder deposits? Great, Jeanette, yeah, go ahead.

Justin Traglia: Oh, sorry. I was gonna say, I think Terrence has proven that it's not strictly necessary to have a queued the builder deposits. I think that client optimizations Is the path we should take.

Parithosh Jayanthi: Yeah, I definitely like that more than a new deposit contract path. Great. Okay, the next agenda item is, adding SSZ to Engine API, and there were two, proposals. one from Marius, and one from… Barnabas? Has, And is this something that you want to propose for the next DevNet, or is this something we can delay a decision on?

Barnabas Busa: This is an optional thing, so anyone can optionally include it or not. I know that Nethermind now has merged it in to their master branch already, so that's, That's actually from trading an ETL. Teams as well, so I'm actually quite surprised.

Łukasz Rozmej: If I can add something, yes, we merged it to our master branch, we also supplied a few PR changes on top of Julio's changes to Prysm. Which we tested it with, because, the spec changed, between Julio's initial proof of concept there. And we achieved, actually, quite a big improvement over JSON, around 5 to 10x, depending on, scenarios, on a very, like, congested scenarios, on very, like, heavy scenarios of, I think get blobs, and… get payload. Those are the ones we tested.

Parithosh Jayanthi: Yeah, Barnabas, can you first explain the difference between the two PRs?

Barnabas Busa: Yeah, so my PR is basically, translating the whole, existing API structure into REST. And, using basically the same names at the same, endpoints, just, using a different, virtually… type how you would do in Rust. And, Marius basically wants to, use named fork, so, like, instead of, instead of engine new payload version 1 or 2, it would just be, like, Amsterdam Payload. And, Osaka payload, and he would want to basically back-implement it for Cancun, he said, but yeah, he didn't even specify how far he wants to back implement it. And my proposal would be basically to implement all the versions, all the way back to all, version 1 for everything.

Parithosh Jayanthi: Lucas?

Łukasz Rozmej: One more comment from us, it was easier to go with Barnabas version without changing the spec at all, because it… we reused the same types internally, and only did a different transport layer and the coding layer, and it was relatively easy to implement. So it was fairly straightforward to add. And the… doing SSZ in a… because we have our own library and our generators for SSZ, so doing SSZ for us was relatively hard, although, Alexei is working on SSZ for, for… years now, so we are in a good place, but it was still relatively not easy, and also we made it in a relatively optimal way, so we also, like, serialized and deserialized directly from the wire, so…

Yeah, without, like, copying buffers, so… because we wanted to do this for performance, so… not touching the actual structure of engineering API made it a lot easier for us, and we could focus on those concerns.

Parithosh Jayanthi: Yeah, that sounds, good. I guess the main… it also sounds to me that Barnabas' approach would be way easier and quicker for clients, as opposed to Marius's, but, maybe for now, since it's optional anyway, if there's any CL with some spare capacity, would you guys be able to work with Nethermind to… Prototype, try out both options, and see which one you like more. And then we can make a decision in the future. Yeah, I like that it's optional, that we don't have to tie it to a hard fork, or… So I tried for DevNet or anything.

Barnabas Busa: It would be actually quite interesting to see, DevNet deploying both SSZ and, GSM with, like, Different versions, and see if you can actually see a huge benefit, and I would.

Parithosh Jayanthi: I'd assume that you'll notice the big benefit once we start doing a lot of blob spamming.

Barnabas Busa: Right, yep.

Parithosh Jayanthi: Yeah, okay, Potos said there's another PR under review, and… Okay, so we.

Potuz: No, no, no, this is just in the implementation for Prysm. Julio opened this a while ago, and then Nethermind, on top of that, fixed the PR from Julio, and there's several team members, I think they are here in the call that are reviewing those PRs.

Parithosh Jayanthi: Okay, awesome. Then it would be really nice to see the next Glamsterdam.net, so we can actually see some real numbers. And in the meantime, if someone has strong opinions about if you want to refactor the entire naming scheme, then please speak up, but otherwise, I guess we go the lazy approach.

Barnabas Busa: Yep. My main question would be whether we want to start merging this in, now that we have a client implementation, and then iterate maybe on top of that.

Parithosh Jayanthi: I guess the main objection against merging it in is we don't know if we, which approach we want to go with. If we want to rename the whole thing, or if we want to just add SSZ on top.

Barnabas Busa: Maybe someone from Gas can speak on behalf of Marcus? I'm not sure if you guys discussed this internally.

Parithosh Jayanthi: Yeah, since this isn't a blocker, maybe we can just leave it as is, and then collect some more opinions, and yeah, agreed with you, add it to the ACDC agenda, and then we can, merge it in once we have the Once we have consensus. To LightClient, the question is if, there's two PRs for the engine API for, SSZ-ing it. One reimagines the whole thing, and the other one just essentially renames stuff and adds SSZ. So which one… does Gets have a strong position on which one they want? Okay, let's move on from the topic, Yeah, we can bring it up in ACDC and take it up there. Any other Glamsterdam topics for today?

Okay, then let's move on to Hegota. The first item on the Hegota agenda was, committee attestation broadcast specification. This is from Sukun. Is Sukun on the call to introduce it?

Sukun Tarachandani: Aw, hey guys, hi. You can hear it.

Parithosh Jayanthi: Yeah, go ahead, yeah.

Sukun Tarachandani: Declanation… Yeah, you can see my browser… So yeah, first, just to… briefly. give a background of the current attestation thing, it'll, like, be very quick. I presented some of this work at the interop, I'll just go through all of this quickly. And the aim here is to basically increase the subnet sizes, like the committee sizes in subnets which we use for attestations. And to increase them by 4X, at least, so that we can cut down the epoch time by 4, basically. And get to 8 slots per epoch. To do that, basically, what we need is to just to reduce bandwidth used for attestation propagation. Like, attestations are the reason why epochs are 32 slots. Like, rest of the traffic flow

does not really change within the slot. Like, the only thing that Is the bottleneck is how much time we have for attestation propagation, and, like, how many validators are voting on a committee, and, like, how quickly can we disseminate them and aggregate their votes? Okay. So, like, Gossip Sock currently works with a mesh size which is, of 8, and a mesh peer is basically someone whom you would always forward your messages to, like, this is not a push-pull thing, you just always push everything to your mesh peers, and every heartbeat 700MS, you do a… basically sync with some set of your peers who are not your MeSH peers, and tell them these are the list of attestations I have.

And that peer subsequently can request those attestations from you. Like, they are called I Have I Wants, but, like, that is generally, like, that is the mechanism here. A brief overview of what's happening currently is that all beacon nodes subscribe to two subnets. So… Oh, and this, basically, subscription stays for roughly a day. Like, they're supposed to stay in a subnet for a day, provide a stable backbone. And then every slot, a different committee of validators will vote on that subnet. Importantly, these validators are not participating in exchanging these messages to other peers. Like, they are just voting on the subnet. They will pick one of these nodes on the subnet, and just give them their message that this is my attestation, and these subnet peers, like, take care of, like, forwarding to everyone in the attestation in the subnet. The whole point of having the subnet is that there are 16… 16-ish, I think, like, yeah, it depends on that specific store.

Validators who are given aggregator duties. who are also part of the subnet, and the entire subnet only exists to be anonymized… to anonymize the aggregators, so that you don't just DOS these 16 nodes on them. on the network, okay? But other than that, subnet nodes play no real important role here, like, and the smaller the subnet, the better. Like, if 128 is Nodes are enough for us in a subnet to anonymize, like, we should keep it at 128, not increase it to have more beaker nodes joining the subnet. So, jumping into, like, the proposed changes, and, like, why current system is inefficient, and how we can improve this thing greatly. So, basically, yeah, the biggest inefficiency is that we send every message independently, so every message has a test station data and the signature.

And this roughly comes out to about 200 bytes in total, 220. And then, on top of it, you have the gossip subtopic name, so this goes to 270. And, like, on the wire, you'll also have IP packet sizes and all, like, so that adds another 40, but it's not counted in the measurement. And we simply proposed this idea that wait for a few milliseconds, like 20 to 50, and then basically batch all the attestations that you have with the… which are attesting to the same attestation data, and just send their list of signatures, along with, like, their validator ID, committee IDs. Oh, okay. So, this basically reduces the data transferred over the subnet to half.

Okay. Oh… Moving on, there is another inefficiency in Gossip Sub, which is this part that I mentioned, that For non-mesh peers, you will send your gossip, I have, I want things. And, the list of messages that you exchange with your peers, every heartbeat. They take 20 bytes per attestation, but we can do much better What we can do here is to… We can basically only send attestation data along with the bitlist of validators who are attesting to that attestation data. Okay, I don't have the details… oh, okay, yeah, I have it in the slide. Yeah. And so, this change reduces the total, basically, gossip happening on the subnet from, like, 10KB times the number of PLV gossip to, to about 220 bytes. Like, no, it's this total number just negligible.

And, like, on, running beacon node, I am measuring that about 30% of the traffic is off this gossip, basically. Oh, yeah, so that is another thing to review or improve here. Similarly, Gossip Sub has this topic that we send on with every message that we send, which is, like, 40 bytes. And so… We can cut this down to either 0 or 4. Like, if we make a bigger change, we can cut this down to 0. If we make a smaller change, we'll cut this down to 4. I'm not seeing the chart, if there are any. Comments people want to see notes. Stay at home.

Parithosh Jayanthi: We can do comments at the end if you want.

Sukun Tarachandani: Yeah, sure, and that also works. Yeah, the other thing is that our D value is high, 8 is pretty high. We can… like, anything between 4 to 6 should be fine for us, like, which I'll share the numbers later on. D value is basically your mesh size. These are the piers you will unconditionally forward to. And so, this number is always D-1, because as soon as you receive a message which is unique for you. you will queue it to all your other peers, other peers, I mean, I mean, you will exclude the guy who gave you the message, but everyone else will be just in queue. So you'll just eventually end up forwarding to D-1 peers always.

8 is pretty high, you can cut it down to 4, and, like, yeah, I think 4 is good. So, like, to give some background about, like, what how to think about this number and how to think about, like, the time of propagation for attestations. It's like a function of the subnet size and the committee size. The more committee members you have. the more data you have to transfer over the subnet, right? And this increases your, like, transmit time, which is, like, the total time it takes for you to put things onto the wire. Like, it's roughly the amount of data you transfer by your bandwidth. On the other hand, there is another factor, which is subnet size, that if you have a smaller subnet, your graph is small, your graph diameter is small.

And so, it's just faster to propagate within the subnet. Like, to think of it this way, if the subnet size were 2, it would just take you one hop to send it over across to your peer. So, yeah. And then, if you increase your subnet side, it's actually worse for latency. But you do want some… threshold amount of subnet to anonymize the aggregators, in our case, not chain that property. And so, I have this proposal which does all of these changes. It's currently in each P2P. I will move the consensus changes into the consensus spectia, but roughly, this is the idea, basically, that we have this attestation data. And rather than sending it again and again, you send it… you… the attestation data once, and just send a list of signatures, which are signing to it, and a bit list for

who is… who… the signatures, basically, who are the validators who have sent those signatures. And same way for gossip, you send the attestation data with which attestations you have, and basically which attestations you want from the peer. The current proposal builds on top of the partial messages proposal, which is being done for blocks. Oh… I intend to try a custom protocol as well, and then see. The benefit of partial messages is that we get backwards compatibility very well. Because you will share your mesh peers with peers who don't support partial messages. And you may potentially be able to just deploy it anytime you like, sort of, like, after testing, of course. But it does not need to be coupled to a fork, and, like, it's just much easier to deploy that with.

Yeah, so now for some, like, numbers, basically, as to, like, the simulation numbers. Yeah, so this is… The red line that you see here, which is, like, the current state of And these numbers roughly correspond to a correspond to current mainnet. There are 500 members in a subnet, and 500 committee validators who vote on that subnet, okay? And yeah, so the proposed design is the blue curve, the current thing is the red curve, and we move from about, yeah, 800-ish for maximum propagation to around 500 to 600 demos. We get the expected, basically, reduction, ignore the idealist here. a bunch of things I was trying. from, yeah, basically 1.2 MB cent per… Mesh to about, yeah, one-third of it, basically.

Because of all of these improvements that we showed before, and, like, primarily because, like, we reduced the gossip overhead also brought. Okay. So then, this is basically the simulation for 1000 validators, voting on the subnet. So basically, no subnet assignment is changing. We're just saying we reduced the slot size, basically the epoch size by half, so we have twice the number of validators voting in the committee. And we basically get this curve, like, D equal to 8 curve, which now has shifted from previously 500 MS to around 600 MS. And more importantly, if we reduce the mesh… like, fan outside, like, the V value, we are now getting, like, much better numbers. Basically, this reduces the bandwidth used to.

And, like, yeah, if you have 2,000 validators voting in the committee, you get much better numbers with, like, 4 peers in your mesh. But the important point is we can… we roughly get the same performance with 2,000 validators in this new system on a committee as we got on… as we get in the current system with 500 validators. So, yeah, it's a… Plausible paths to, like, reducing the epoch a lot. That's about it. I just want to highlight it. Basically, I would like to propose it for Agata, at least, and I'll try to make it in such a way that it's backwards compatible, so we can just deploy it without a fork. And, yeah, there are some of the other steps.

updated.

Parithosh Jayanthi: A couple of, questions. Sukun, do you want to maybe take those? We wanted to.

Sukun Tarachandani: gimbal.

Parithosh Jayanthi: for 5 minutes from now, and then there's a few more EIPs to discuss today.

Sukun Tarachandani: Yes. Okay, do people just want to ask?

Potuz: Oh, I have… I have a bunch of questions. I very much like this, and I think the high-level discussion we should be having is as an approach for faster finality. It's contentious… it's contenting this thing of, like, having more, committee members per slot, and having less slots per epoch with shortening the slot. And I very much like this approach of shortening the number of slots per epoch. What I do worry, though, is how does this play, for example, with the faster confirmation rule? If we get a less stable vote… voting per slot, then perhaps this would make the fast confirmation less effective. And today, we could, presumably, with the current status, be confirming or getting a good signal that we're final with just one slot. But if we go with this, it's not really clear to me how it would affect. It would be good to have numbers as to what is the vote, how the vote effectiveness is going to be changing.

Sukun Tarachandani: That's right, and I will consider it. I don't have any analysis here, but intuitively. Like, say if we just moved to, like, cutting the number of Slots by half. The system would have actually better transmission properties than the current system, and, like, the fast confirmation rule should work better with this one. Like, it in no way degrades it from the current status quo. Though, yeah, we… it's a fair question that maybe putting it at 4x might be a stretch, and yeah, that requires a bit more analysis.

Potuz: And just quickly, the other two is that on the technical side, I don't really understand this thing of, like, trying to make better the I want, and I have. If, in Svalbard, you guys told us that it's essentially useless today, and even if we drop it, the only thing that would matter is that some aggregator might not get some good, single attestations. I would just drop the entire system, instead of, like, trying to make it better. And the other one that I wanted to highlight is that on the attestation data, if you're going to be changing it, we should really study dropping completely the checkpoint, the target checkpoint, and the source route, because those can be derived from the block route itself.

At the cost of not being able to slash invalid attestations that are anyways useless, because they're not on-chain.

Sukun Tarachandani: I can consider that, yes. So both of them, like, intuitively, I felt that I have and I once probably help these nodes were not, like, in Europe and US, and, like, I was just really finding it difficult to paint the mesh, because, like, over time, we have these subtle rewards and gossips up for giving you a good message, like, giving you the first to deliver a message that meshes tend to move towards, like, your nearby peers. So, intuitively, I think I have and I won't help those peers, but I would like to, like, measure it on the mainnet and then take a call. So, but yeah, I am on board for it, of course. If it does not help, you should just remove it.

What was the second point? Yeah, in terms of attestation data, I will also consider that. Basically, yeah, actually, for the… I have an I want GOS, and we actually don't want the whole attestation data, right? We want the checkpoint. But it's fair that, yeah, if we just get the spinal blocks both, get us correct, and I guess it also simplifies things a bit. So, yeah, that is a great part. I'll… I'll take startup. Okay, answer other questions? Barnabas, what's the rollout plan for ETH B2B? I actually don't have a good answer to that, but you'll have some amount of overlap with LibP2P, I think it feels like, or I think if we don't have a lip P2P overlap, we need a way to say, this is how you run gossips over each P2P, which might be also a fair transition plan, but nothing's finalized here, so I don't have a good…

Ow. Answer to your question. I don't know. What are the other questions? Does anyone want to go ahead?

Barnabas Busa: Just for the rollout plan, I would actually recommend to basically have some feature flags to enable the different, like, P2P and disable P2P, or enable both at the same time. And that way, we can actually just test if, everything is going smoothly, and we don't, like, require twice the bandwidth, to send stuff on it, P2P and on the P2P, ever on… in production.

Sukun Tarachandani: Yeah, I think that's a good point. Like, Jasek also mentioned that we have, like, 5 networks now, or something, if we introduce ETP2P along and everything else in parallel. So, yeah, that's a fair argument. On how does this affect the fast finality roadmap? In general, it does not affect much if we are doing a decoupled consensus thing. What will help, like, I removed that slide because it wasn't relevant to what I'm proposing for Hegota, but is that This method actually is fast enough for, like, aggregating 8,000 committee members in, like, 2 seconds, so it will actually help a lot in a decoupled consensus where the finality chain has a completely different slot, where you just have a lot more committee members voting on a slot.

But using just the same method. Does that answer your question, Greg?

Greg K | Lido: Yes, thanks.

Sukun Tarachandani: Okay. Yeah, I think that's it, like, I just wanted to highlight that we are working on this, please, like… talk to me, whatever feedback you have, or if you have any questions, yeah. And I'd like to propose it for Hegota.

Parithosh Jayanthi: Awesome. Thank you. So we would still wait for 2 weeks, before we accept it, I guess? But yeah, if there's any questions, etc, please reach out to Sukun. Yeah. The next item on the agenda is, EIP8025 from Optional Proofs. Is there… .

Francesco Risitano: Yep, I'm…

Parithosh Jayanthi: Is that English? Yeah. Yes, Francesca, go ahead.

Francesco Risitano: Can you hear me?

Parithosh Jayanthi: Jessica, go ahead. Yes.

Francesco Risitano: Yeah, okay, cool. Let me share my slides. Can you see the slides?

Parithosh Jayanthi: Yes, looks good.

Francesco Risitano: Perfect. Yeah, so it'll be, myself and Ignacio, presenting this. We're both, part of the, EF, ZK EVM team. The ZK EVM team have been kind of collaborating with the broader community for some time of this… on this effort, and I will kind of provide an update on the status of that progress, at least on the CR side, and then Ignacio would do the same on the… on the EOS side, so… Yeah, the proposal here is to include EIP 8025 in, Hegota, and it is, an optional proofs EIP. So, TLDR, on a high level, the EIP essentially covers the introduction of execution proofs into the protocol. So an execution proof is essentially a cryptographic proof that allows a validator to, efficiently assert the validity of an execution payload.

So we introduced this cryptographic proof into the protocol with two additional modes. Now, it should be noted that these modes are opt-in. This is a completely optional EIP, so standard validator mechanics are unchanged if they don't opt-in. The two modes are proof generating mode and, proof verifying mode. So, for the proof generating node, essentially an active validator will kind of enable this mode on their beacon node. And whenever they receive a block, they validate it via re-execution, and then they will make a request to the proof engine, which I will kind of describe in more detail later, but essentially there's this component called the proof engine, which is responsible for both generating and verifying proofs.

So the active validator will, yeah, request the proofs from the proof engine. There's an external proof node, which, you know, potentially has GPUs and, and other kind of hardware required to generate these proofs. The proofs will be returned back from the proof node to the proof engine, and subsequently to the, beacon node, essentially the validator, who will sign the proof, and subsequently gossip, the proof on the on a new execution-proof, gossip topic. Then the second mode is, proof verifying mode. So you've got another node which is… which is opted in to, to verify proofs. So, this node will essentially receive the proof over the gossip topic, and it will send the proof to the proof engine, which will subsequently, send the proof to the proof node to be verified. And yeah, that's kind of the high-level flow.

we, as I say, this is opt-in, and in addition to the standard, kind of, duties and, node operations, so we… we still expect that, nodes will do re-execution in addition to these additional modes. Yeah, and I'll dive into the reason for that later. But just to give some context in regards to the motivation. The key benefit of this is that, we make payload, validation sublinear and stateless. So, specifically, it's sublinear in the gas limit and the state size. So this has nice properties in regards to the hardware requirements for nodes. And the implication of this, kind of sublinear relationship is the fact that, payload validity or payload validation is, remains accessible even with, gas limit and, state growth increases, or state increases, state size increases.

In regards to why optional, the technology is still relatively novel. There has been a lot of development and progress over the past few years, but in the first instance, we'd like this to be optional, such that we can kind of Collect data and, build confidence in the system, make optimizations, etc, before we do, you know, potentially, enshrine this in a future hard fork. In addition to that, we, we don't want the, this proof verification, to be load-bearing on consensus. We essentially want this to… as a, as a phase where we can build confidence and, Yeah, just kind of test out the various components of the stack before we enshrine and make this load bearing on fork choice and consensus.

So wine, Hegota, the… the tech… as it's mentioned, the technology has matured, substantially over the past few years. L2s have deployed roll-ups, and they've had them operating in production for a number of years now, and, proof systems have, improved in regards to efficiency and performance to a point where, real-time proving is a practical reality. So… Yep, that's the first point. In addition to that, as I said on the previous slide, this is kind of the first step towards enshrining. So, like, the general community would be Would have more confidence and be more comfortable with enshrining, proofs, execution proofs. Once we have data to kind of… and evidence to, to prove the fact that this is, in fact, you know, reasonable direction and sound.

in regards to, kind of, the status, we have, both the consensus layer and execution layer specs, defined and largely settled. I suspect that once we get some more eyes on this. you know, we may have some questions or disagreements which we can resolve, but I don't expect them to be huge divergences to what we currently have. We also have both consensus layer implementations and execution layer implementations, so, the stack is reasonably… is maturing, it's in a pretty good state as is. And yeah, it's fully opt-in, so in regards to validators that do not opt-in to either of these modes, there's no changes, no implications on, you know, on performance. Just a high level on the consensus layer. As I mentioned, we have the two modes, proof generating mode, proof verifying mode. I provided a link to the specs here, if anybody wants to, to review them or provide feedback.

We have two client implementations. Internally, we've worked on a Lighthouse implementation in Rust, and the Prysm team, Manu specifically, has kindly, supported us on this effort with an implementation in PRISM. We have deployed some ephemeral DevNets, so we have a DevNet, we've spun up some DevNets with, Kurtosis, and we've performed, some, some interop between the two clients, in addition to having a, a GPU-based prover. So just to provide a bit more context on the proof engine, the proof engine can be considered analogous to the execution engine. So, where the execution engine is a payload validity oracle of sorts, that uses re-execution for. uses re-execution as the backend. The proof engine uses execution proofs. The Proof Engines API is modeled on the Engine API. This is intentional to make the integration into the protocol relatively seamless.

So it has methods for, verifying proofs, requesting proofs, and also, for notifying of fork choice updates, We have, the kind of the core type that we introduce is this signed execution proof. So this is the proof that is generated by an opt-in proof generating node, essentially a validator who signs the proof and then gossips it on the subnet. On the request response domain, we have 3 new, methods, so proofs by range, proofs by route, and execution proof status. And then for discovery, we introduce a an additional key-value pair, which is e-proof, and that just signals to peers that, we are, you know, we support the… we support execution proofs. Just quickly to touch on infrastructure, we have collaborated with PandaOps, and implemented support for this EIP, in addition to, GPU prover support, so it's in a relatively good state, and it's pretty, efficient and nice to deploy this, the deployed network, DevNet, sorry.

In regards to observability, we've implemented observability, so, essentially Prometheus, metrics for, both ZKBoost, which is the, Prover backend, and, Lighthouse as well. We have, block explorer… block explorer modifications where we can, kind of observe these proofs. And I've also provided links in case anybody wants to run, one of these DevNets. I'll hand over to Ignacio for the EOS stuff. Ignacio, are you there?

Parithosh Jayanthi: We can't hear you, Ignacio.

Francesco Risitano: Yeah, maybe, maybe I can, I can cover… his section.

Ignacio Hagiopan: Hear me now?

Parithosh Jayanthi: Yes.

Francesco Risitano: Perfect.

Ignacio Hagiopan: Oh, sorry. Yeah, I will touch briefly on the execution layer side of the EIP. On the execution layer, we have to define, mainly what is the program that we are proving execution. Because at the end of the day, from the CL perspective, what we are trying to swap is, the engine API call to execute… to validate a payload with a cryptographic proof that this execution was done correctly. So, the high-level parts of the guest program, which is this program that we are proving execution. Are the input validation of the program and transformation. Into the correct input for the, state transition function that we already know, and we have already a spec in the execution specs repo.

And finally, we have to do some public commitments to these inputs, such that the proof verifier can understand Which inputs were used, in this guest program execution. So, basically, the program that's being proven is a stateless Validation of an execution payload. So apart from the program itself, we also, define which is this input, from the guest program. This call, we call this the stateless input type. And basically, what this stateless input type has is what you already can imagine, what you already know is our inputs in the engine new payload RPC. So, you have the execution payload and some extra fields. But it also contains cryptographically verifiable data that is required for execution. This is mainly because a guest program that runs inside a CD VM is a pure function, so it does not have access to a database, to… with the whole state.

So, all the data that is required for execution, such as storage slot values, or balances, or things like that. Should also be provided as inputs. And not only it is required to receive the input, the raw values, but also requires to be provided the data to verify that this data is correct. So, the specs also contains, yeah, a full definition of what… how this data is provided. And the main goal here to fully spec the guest program and the inputs is to reduce complexity on running provers, because there's a reasonable chance that we will require multiple crews using different guest program implementations, in the same way that today we have different ELs. And if each guest program receives different inputs.

That simply complicates, generating proofs, because you might need, like, different libraries to construct the correct input for the proof. And another pretty obvious benefit of standardizing the input is that This is the stable boundary that we need to properly create tests in the execution specs repo. Such that we are sure that we are covering all the important angles of new logic, for the guest program execution. So, probably the first… good step for people to understand this EIP is to just read the IP. We have been iterating on that these last days, and it's in a really good new shape. But if you know… if you want to know, like, further details, here we have some links to the spec. No, just go to the previous one.

so, yeah, so you can see here, like, more detailed, structs of the, definitions in the spec. We also have a bunch of tests already that cover Most of the, important angles of, The guest program doing, validations correctly, and with correct and incorrect input. We are also doing releases, which are usually based on the… on the latest, valid DevNet, so this is trying to always. simplified ELs running these new tests on their main working branch. So, maybe… now, next slide. So if you want to join the discussion about EIP, we have monthly zkEVM breakup calls. So here we leave the link. Also, in the R&D Discord server, we have two main channels for discussions. We have the L1 zkEVM channel, which is mainly focused on concrete zkEVM infrastructure discussions.

And we have the L1 zkEVM protocol channel channel, where we usually discuss CL and EL-related, topics about this EIP. If you want to read the latest version of the EAP, we leave the unopened PR that is still under review. Please try to read this new version instead of the currently active one. Because it's a bit stale. And yeah, you can also drop your thoughts or questions in the If Magicians thread. And usually, we also… write articles about this topic, mainly touching in other dimensions, such as security, in our team's website and blog. So, yeah, you are also invited to read that, that thing. Yeah.

Parithosh Jayanthi: Do we want to do some questions? I think we still have 5 minutes on time. I'm happy to end the call today with just questions on the topic.

Ignacio Hagiopan: Yeah, sounds good.

Parithosh Jayanthi: Open floor for people. So, if anyone has questions, please speak up. Yeah, I guess, that plant has a question, what would… he didn't catch why we would need protocol changes for an optional mechanism?

Ignacio Hagiopan: Right, I think this is a really good question, and probably the main one that we have been receiving from people. The way we think about this is that Doing this change requires a lot of work. on two things. The first one is… For example, in the execution spec, work for EIP. It also requires a lot of changes in the testing framework and main architecture of how a lot of tooling works. And… I see also, asking for scheduling an EIP into a forecast, having a slice of capacity of many themes. To really look into this stuff, because there are some, like, architectural changes that requires, also capacity from other people, and I think, like, trying to do this in a one go in a single fork will be quite challenging, and it makes things pretty hard.

And I think the other reason is… We want to… gather much more real data about how this would work in the real network. So, we are trying to Do as much work as possible. To discover, like, more unknown unknowns that we might be missing, and trying to push this as, like, as an optional feature into the network is… The best way to do this without putting at risk, You know, main comp… main core part of how the network works.

Parithosh Jayanthi: Okay, thank you. Yeah, that makes sense. It's mostly about teams allocating time, effort, testing effort, and so on for the feature in the slotted fork, right? Portals, do you want to go next?

Potuz: Is the verification of the proof, the reply that it's verified or not, does it come as in the reply to new payload call to the engine, or does it come separate?

Francesco Risitano: No, that, that comes separate, so the, the, notify new payload Essentially just makes the proof engine aware of the payload. But the actual verification of the proof is a different, it's a different path. So let me just show you on this… so, yeah, notify a new payload, that just lets the proof engine know that a new payload has arrived, such that when the verify execution proof, path is invoked via the receipt of an execution proof, it can associate the two via a, via a commitment, but in any… in any case, it can… it can associate the two. And just on the question in the chat, there is no gating of attestation on… proof verification, so as far as I'm aware, the gate for attestation is validity, the validity of the block to be… the block has to… the payload has to be verified, before an attestation is made, and the fork choice,

block validity is exclusively gated by re-execution. So, and this notify new payload is fire and forget. There's no, yeah, there's no actual verification done here, it's just a notification, essentially.

Parithosh Jayanthi: Thank you, Barnabas, and then Tony? Okay, Tony?

Toni Wahrstätter: Why would we do that for validators and not for full nodes, assuming that, validators would then opt into propagating additional objects over the wire, and could be slowed down through that?

Francesco Risitano: So, I'm not sure if I completely understand the question, but, all nodes can certainly opt in to be ver… they can opt in to the proof verifying mode. The reason that we want the proof generating mode to be done by a validator is primarily for DOS. Such that we can have a validator kind of sign the proof. But… yeah, that's kind of the general intuition. I'm not sure if that answered the question.

Toni Wahrstätter: Yeah, thanks a lot, and we can also take it async as we reach the end of the call, but thanks a lot, I think I get it.

Parithosh Jayanthi: Yeah, thank you guys for presenting. There were two EIPs we didn't get to today that we can start off with next week. We have return deposits for distinct credentials and custom suite thresholds for validators, but we'll push that to the next ACDC. Thank you everyone for coming, and see you next time.

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