All Core Devs - Execution #240

Transcript

Ansgar Dietrichs: Hello, can you hear me?

Pooja Ranjan: Yes, we can hear you, Ansgar Akash would be streaming. So whenever you are ready, just let him know to move over the stream.

Ansgar Dietrichs: Sounds good, but it will be like two, three minutes before everyone is trickling in.

Pooja Ranjan: Sounds good.

Justin Florentine: Good morning, Ethereum.

Ansgar Dietrichs: Good morning. Back to you.

Okay, I think we can get started. Can we go live?

Akash | ECH: Yeah, we are live.

Ansgar Dietrichs: Perfect. Hello, everyone. Welcome to All Core Devs. 240. Today we have… the primary topics of Glamsterdam DevNet 7 specs, and then some more Hegota scoping, so let's dive right in. Glam first.st First up, it will be the topic of Glamsterdam. DevNet 7, kind of spec finalization. I saw that, Stefan, you had a comment with several open decisions that needed attention. Are you on the call? Can you?

Stefan Starflinger: Yeah, sure. So this is mainly a follow up and a summary of what we were talking about in act. And there are some issues or discussions that are still open, and we need to kind of decide If any of these are gonna make it into Definite 7. So the first one would be, I think, 80 38. There was some discussion. I think this was from the guest side. That started this discussion. Maybe.

Gary Rong: Yeah, so the idea is… So I guess we need the additional check before we're accessing the slot from the database. And last time, in the last ACDT, and I think Tony and Maria and me, myself, agree with this change, and I guess Dragon has… It's also supportive. So we just need a few more opinions from other clients.

Stefan Starflinger: Okay, could we get opinion, maybe of this one as well.

Luis Pinto: I think it looks good to me. I had a look. It makes sense to charge before.

Stefan Starflinger: And Ergon…

Andrew Ashikhmin: Sorry, I didn't have a chance to look into it, so no opinion.

Stefan Starflinger: Okay, but it generally sounds like that. We can move forward with this one. the next one, I think, then… Unless anyone else has any. opinion. Yeah. And can we get the pull request as well? I I didn't find it. or this 80 38. Thanks. Sounds good. Etheric's also fine.

Maria Silva: Just… just a quick question on that, though. My understanding is, like, it requires a spec change, but it doesn't require an EIP change, right? So it's mostly we need to have a… spec change there. Is this correct, Gary?

Gary Rong: Yeah, I think so, but I'm not sure, like, which… like, where we should put this change in, like, in the A038, or… Or, like, 7, 9, 2, 8. So we just need to find a good place to place to persist change.

Toni Wahrstätter: I'm Gary.

Ansgar Dietrichs: Are we talking about the behavioral change or are we just talking about a documentation change?

Gary Rong: It's a behavioral change.

Toni Wahrstätter: Gary, didn't I put something into 7928? I vaguely remember that I had a PR for that ready. Did I…

Gary Rong: Okay.

Toni Wahrstätter: Did I dream this?

Gary Rong: Let me quickly check. No, in the current, 7928. It doesn't say that we need this additional check. It only… They only mentioned we need to. Check the stipend first, and then send to… calculates the gas cost.

Stefan Starflinger: Hey? Then can we get a Pr for this? So then I can add it to the 7 specs. That would be great.

Toni Wahrstätter: Yeah, I think there should be a PR somewhere. I remember I created one. Let me check, maybe I just, pushed and didn't create the PR. I will double-check that.

Stefan Starflinger: Okay, then, moving on, The next one was already shared by Marius. I can share it again. And it's a change in 80 37. And it's not clear, necessarily, if this is gonna make it in or not. Has there been any further discussion?

Maria Silva: And.

Ansgar Dietrichs: Maybe.

Maria Silva: I can add some context here. So, at the moment we are discussing, different change to 2780 that will essentially mean that this PR is no longer needed because solves the issue that this PR was. aiming to do. So we discussed this on the last ACDT PL breakout. And essentially, the idea is to change how we charge intrinsic costs to only consider chargers that don't depend on state. And then all charges that depend on state for ETH transfers, and this includes authorizations as well, they are processed during runtime, and if there's not enough gas for them, the transaction is still valid, but goes out of gas. So it's a slight change in how we define transaction validity and intrinsic gas costs.

But I think it's a good one. So at the moment, Dragan opened a PR to the EIP with a proposal, and we are… essentially discussing there, some, some details, but we would expect, so what we ask clients is to look into these, see if they can find any issues, and ideally this would go in, in Glamsterdam DevNet 7.

Stefan Starflinger: Sounds great, thanks. for the update and then for the next one. It would be also a draft. Pr. For intrinsic cash. A question that came up. I will share. Yeah, it's already exactly shared. Is this still relevant? as well.

Dragan Rakita: I would say that it's covered in my PR. now, this, like, topic that we need to discuss… They want to handle warming and warm and cold gas inside both the authorization list and for the target, trisection target or trisection two. But yeah, I think it's both of those. Questions are covered in my PR. Basically, it's new mechanism that we are going to introduce to basically allow halting on the pre execution part of the of the code.

Stefan Starflinger: Sounds great, so, we can close, both of the other PRs in favor of your, PR, Dragan. Alright. Then there's, one more. Kind of housekeeping, only, You already merged it, since… Sounds great. Okay. I think that's pretty much done then.

Toni Wahrstätter: This was… this was just, finishing this discussion about the different options where to track something, and now We… as we said, we went for option one, which is keeping everything as is, and since the EIP was already that option. 2, we reverted that back. So, this PR is essentially just reverting back everything. The clients didn't implement yet.

Ansgar Dietrichs: Sounds good. Then maybe before we go to the next item, just also for context, I think the The idea was that we are really trying to get to a final DevNet 7 spec as soon as possible, try to make decisions as much as possible today, and then ideally have any last pending items resolved on ACDT. On Monday, I think at least that was my understanding. Yeah, so with that in mind, just a quick check, Stefan, from all the topics we just discussed, are they all basically in a good place? It sounded like it. Any… Anything we should just make sure has a decision on the call here?

Stefan Starflinger: From the EO side, I think that is pretty much anything. Everything we talked about in ACD Gee, I think it was, that there are not gonna be any more EL VIPs. So, this is pretty much the summary, as far as I'm aware of. And one of us also said that, we might even be faster with the abstract 7 than ACDT. If we can get clients to create Glamsterdam DevNet7 branches. I will update the spec after the call.

Ansgar Dietrichs: Sounds good. Yeah. Then, okay. Sounds good. Then, the next topic there regarding the DevNet 7 was, I think, about the deposit contract. Barnabas, you had a comment?

Barnabas Busa: Yeah, Nico, from Lost Army, the PR. For the system contract, to basically change the, target and the max. Max deposits per block, and… This is basically reducing the target from 32 to 8 and the max from 256 to 64. I'm just curious if, we should be able to merge this in. or if anyone has any objections for this.

Felix Lange: I'm okay with merging again.

Barnabas Busa: So I optimistically already included, this change in the Ethereum Genesis Generator. So now, if you're using Ethereum Genesis Generator, Glamsterdam.net 7, Image, then you will be… you will need to start using the new address. that I have mined for this event, and that is posted here in the chat, and it's also an issue. And I was posted in still chat.

Ansgar Dietrichs: Felix?

Felix Lange: Yeah, I just quickly wanted to raise, so I created another PR for the contract. This is following a discussion that happened on Monday in ACDT. So I created a PR that changes the contract so it allows the system to disable deposits to the builder queue. And I think this might become necessary if we ever want to upgrade the contract or for another reason. And it can also be reversed. So it is possible to undisable the contract also via system call. And I would just appreciate if we could somehow figure out like if we should move forward with this. And, in general, I want to say that for 8282, it entered the process quite late, and so I would prefer to just finalize the contracts now, and then figure out some external auditing for it as well.

So that we can wrap it up.

Ansgar Dietrichs: Sounds good. So is there any open decisions then on this?

Felix Lange: Well, the decision is if we want to do this. It's a bit… I should have put this on the agenda, I'm sorry. I just realized that… I just saw that we were going to discuss the 80-22, so I thought I would just bring it up quickly. We can try to resolve it ASIC. I just kind of wanted to have it so that by next week, maybe we are kind of feel comfortable about the contracts, and then we can just… Hand it off to some people to really audit it one more time.

Ansgar Dietrichs: Right. And then the question is just, is this, would it be important to basically make this, have this make the cut already for DevNet 7 or not? And if so, basically, could we get that decided on like a faster timescale?

Barnabas Busa: I would prefer to have it in, or not have it at all. So if we decide to do it, then we should do it for W7. And if we decide not to do it, then we should just close that PR.

Felix Lange: Yeah, I don't know. I just. I can merge it into the repo, and you guys can just take it from there, if you want. It was just much more the question of, like, is there… who is gonna be in charge of this decision, anyways? I mean, I just made the update because I felt like this is something we could do, but I don't actually know who I should ask. if… I feel like we all just kind of have to agree on the scope of the contract. We can do that in Discord, I guess, but… so if you want to put it in, it's not going to make the contract break, like, the DevNet is going to work no matter what, it's just a question of, like.

No. Do we want this feature or not?

Ansgar Dietrichs: Yeah, I mean, it would be nice, of course, to decide now. I'm not sure that the… given that it wasn't on the agenda, maybe we don't have enough people with context. Yeah, it sounds like it would be really desirable if we at least have this locked in by the end of the week. I don't know, do we feel comfortable making a decision on this now, or should we, like, otherwise at least try to aim for, like, a decision by tomorrow as Does anyone have a strong opinion in either direction? Mario?

Mario Vega: I don't have an opinion on, on it, but I would like more context on why we're doing, why we want to do this. Not, not the technical details of how it is implemented, rather why, and that I think we can make a decision.

Felix Lange: I can give a very quick overview of this. So on Monday, we discussed the possible options for changing the parameters of the contract in the future, and one of them would be to make the make it parameterized in a way where the system will always supply the current target and max values to the contract in the system call. If we do this, we can schedule a future hard fork where we update the parameters which are passed to the contract. The other option would be to just deploy a new contract with different parameters or even different logic. But then if we do this, we're going to have a situation where there's two contracts live at the same time and people can technically deposit into both.

So, in that case, if we ever want to do an upgrade on a contract like that, we have to be able to turn off the old one, in the sense that the system can still read the remaining requests from the contract, but users would no longer be able to deposit into it. And I feel like for the builder deposits, this is especially important, since this contract will accrue quite a bit of balance. So, it's like, if you put your deposit, but the system will never read from it, your entire deposit will be lost, and there's no way to ever recover it again. So, I feel like there should be… just be this option to disable it. And then finally, there is

this case where, like, ePBS somehow turns out completely broken, and we have to just stop deposits. And so this could also be done, then, by scheduling a hard fork that will Essentially set the system call input to a value that disables deposits. It's not like this feature is only triggerable if the system decides to trigger it, so we would have to make changes to the system to actually make it trigger. But it's like, once the contract is deployed, I don't think we want to go to a situation where we then retroactively have to modify it via irregular state transition and so on, and that's why I'm putting this feature in, just so that it's clear from the start that, like, should something

it is possible for the system to turn off deposits. And I just want to know, do we want this or not? I don't want to go… into too much detail there. I just… I just thought this is a nice option to have. Maybe something we should have also added in the earlier contracts, but we didn't.

Ansgar Dietrichs: Anonymous?

Barnabas Busa: How would you handle this? Like, let's assume we require new deposit contracts for a different builder type. How would you handle the forward transition then? Would you expect people to deposit again to the validator contract, and then… In default transition, we would process them into the new contract.

Felix Lange: I'm not really sure what the question is about, but I think it's like, if we would do this upgrade scenario, then basically the system would still read from the previous contract for one more fork, and then it would just stop reading from it eventually. But we would also start reading from, like, any new contract, like, that's how we would do the transition.

Barnabas Busa: You know.

Felix Lange: It's not the most important thing. I agree. I also see it in the comments, Porto saying like this is super unimportant. I also think it's unimportant, but I feel like this is our chance now to just like lock in the contract. We can ship the completely immutable one. It's also fine for me. I just wanted to propose it as an option so we know this is possible and it's actually kind of easy to implement. Anyway, let's just be done with this now. Let's just, like, discuss it on Disc.

Ansgar Dietrichs: Okay, so then the default would be to not accept this change, but if there's enough of a coalition to make, to be in favor of it, we could still decide by tomorrow to… to accept it, I think. Does it sound reasonable? Also… Yeah. Okay, sounds good. Then I think, we can move on for now. Next one is… oh, wait, double, double check, Pandabus. Otherwise, we had everything decided, right, for the, for the deposit contract.

Barnabas Busa: Right, so, like, if PR50 is merged in, then the deposit address and the bike code is correct, and if you also merge in 49, then I will have to basically re… regenerate the bad code. But yeah, it's it's based on the decision. I I think we shouldn't call it in. In this call. Like, I think we should make a decision here, and not wait for another discussion somewhere else. I think this is as good as it's going to get. We have 78 people here, so I think we should be able to make the decision here.

Ansgar Dietrichs: Okay, well then…

Barnabas Busa: Move on.

Ansgar Dietrichs: I mean, obviously, people haven't really had time to look into the like. I mean, we've heard Felix's description now. I mean, from my side, I can say the description seemed like a nice to have, like, if there's no specific consideration not to do it. It seems like we should just do. It seems. Seems good, but obviously there might be some nuanced implication around extra complexities that are not so obvious. And. Yeah, I don't know. I'm happy to just make a decision now if people are strongly opinionated in either direction. Could we have, do we have any client apps that after hearing, hearing Felix's description would lean either into including or excluding that change?

Barnabas Busa: Maybe we can do what Matt suggested, that the default is we ship it. If anyone is opposed to it, then they should speak up.

Ansgar Dietrichs: Sure, Anyone, anyone would prefer to just keep it out to basically anyone is worried that this might include some extra complexities, some something we might have overlooked here. Anyone would prefer to just stick with the old version.

Lightclient (Matt Garnett): I just want to say, I think that this is kind of a no op. In general, like… It gives us this ability in the future to maybe turn it off, but it costs nothing for us to really add as a feature to this contract, or like, it doesn't cost extra gas for users. I think we should just put it in. We probably should have done this for the other ones too.

Ansgar Dietrichs: Yeah, it does seem reasonable to me. It's like, it's really more about, like, extra auditing surface, maybe, like, just having the parameters passed in in the system call. Maybe that's something that we… It's just a little bit extra testing surface or something, I don't know. But it does seem otherwise like a no brainer to just go ahead with it So yeah, seems like no one is speaking up with strong concerns. Then I would just say decision is that we go ahead and accept Felix's changes. Okay. Then, daniel. Then, like, let's do that. So we will make this one more change to the deposit contract. Okay, great. That was then everything on the deposit contract. Then…

other open questions for Devnet 7 that we should address today. My understanding was, for example, that there might maybe was still some repricing related topics in general, or something at least, where we should double check shared understanding about how final the numbers are regarding repricing. I don't know, Maria, could you maybe give a quick update on this.

Maria Silva: Sure, happy to. So, I think this relates mostly to, to EIP, so, AT38, which changes the cost of state access operations, and 2780, that changes ET transfers. So for these two EIPs, we have at the moment the numbers that are in Glamsterdam DevNet 6. They are based on our best estimate of right now how we expect client performance to look like, in order to, So those are what the prices should be for all clients to have 100 million gas per second performance. But at this moment, we still have a couple of clients not hitting that target. So they are still working on optimizations, essentially. We are, we have high confidence that the clients will be able to hit those targets, and those should be the final numbers. But the reason why they are not yet is because we are still working on optimization. So there's two things we need to clear.

In order to say that these numbers are final, first, all clients need to meet these, targets, so we have to finish up the optimizations, and second, we are now starting to run, wider benchmark. So at this point we were only using a subset of our benchmarks for running things faster. And now we are starting to run A larger subset of benchmarks that will. Consider not only the tests we are using for the repricings, but the wider range of, worst cases. And this is the same test suite we were using for the tests we were doing when we were trying to raise the gas limit last year. And so the goal now is to use Glamsterdam DevNet 6.

Spec to run this wider benchmark and confirm that all clients are. Performing at the needed… million gas per second, targets, so that we can have, so we can increase the gas limit. So, we need to clear these two things, yeah, and we expect to have more updates on this, by the next ACD.

Ansgar Dietrichs: And so, so you're saying by the next ACDE, but so that would mean that For now we would operate under the assumption that the numbers as we have them are basically meant to at least be final, but of course. Need one more round of… Of confirmation, but we can for now operate under the assumption that they will not change. Is that, is that correct.

Maria Silva: Yes, correct. So they will change if we find some issues during the bench, the full benchmarks. But yeah, at this point, I think we can call it maybe stable numbers, if not final.

Ansgar Dietrichs: Okay, good. So they're stable numbers, we can use them for DevNet 7, and hopefully no changes necessary for… for the full rollout. Okay, that sounds good. And… then I think that those were all the items that I at least was aware of in terms of DevNet 7 readiness. Is there anything else, any other topics, open threads, anything that would block a DevNet7 rollout. But, for example, you said the ideal target would already be by the end of this week. My understanding was there was maybe one open decision around the specific PTC deadline, or something, that maybe… that's obviously not an ACDE-side decision, but… Is that also on track to being resolved, or does this need attention from anyone here from the CEL side?

Barnabas Busa: Yeah, so… I'm not sure if this is a discussion we should start bringing up now, but The general question is whether we should be changing the Ptc. And possibly the attestation deadlines as well in this work, or should we only touch touch it in the coming of works.

Ansgar Dietrichs: Sounds good. And yeah, I'm not sure if we want to open this now necessarily because yeah, immediately now Tony, Protos, I see the hands up. The question is, do we need to discuss this now or if so, where is this decision to be made of like, do we do something there, DevNet 7 or not? Is the decision basically already that we're not going to make any changes in DevNet 7 or is this still an open question, Barnabas?

Barnabas Busa: I would prefer to have a finance pack on W7, so… if we expect to want to make a change for mainnet in the biggest deadline, then I think we should actually discuss it now.

Ansgar Dietrichs: Okay. Yeah, that's why I wanted to just check, like, then let's briefly see the Tony and Photoshop. Hands.

Toni Wahrstätter: Yeah, I think I always took it for granted that we would change those deadlines, and I think clients are also ready to do that very flexibly, because they are just, putting those deadlines to a certain percentage in the slot. So, for DevNets, it doesn't actually matter where we put those deadlines, but in the final fork. We should definitely make sure to have the attestation deadline at 2nd 2, at 2nd 3, and if we want to be very aggressive at 2nd 2, but probably starting at 2nd 3, and then the payload deadline at 2nd 6 or 7, probably better. to go with 6. And this was discussed in the ePBS Discord channel. Not sure we had broad agreement there, but it felt like rough consensus.

Ansgar Dietrichs: and photos.

Potuz: Yeah, I agree with Tony that we should be targeting not more than six seconds, and I would even go lower, but anyways, not more than six seconds for the payload deadline. regardless if we don't want to change the PTC deadline, which is currently at 9 seconds, we need and we should be putting a different deadline for the payload and the blobs and the PTC attestation, because that's not being tested now. As long as these two numbers are different, it doesn't matter what's the difference, but we really want to be testing this. So this is something that the dual deadline should be, should be, tested. It's not clear to me that clients are actually able to, to handle this. I've, I've tested on Prysm, only TechOne and Lodestar, and it seems to be fine. I'm not sure if every client already handles this, configurable by two different deadlines.

Ansgar Dietrichs: And just to clarify, would this need for two different deadlines exist even if we were to just decide to move both deadlines forward by the same amount? Or is it just not enough?

Potuz: This is already merged. This is already in the spec and clients should already be able to handle it. It's just that we're not testing it and it's not really clear that clients do handle it.

Ansgar Dietrichs: I see. And so then, oh, yeah, Banavas, you're, you're Meeting.

Barnabas Busa: Yeah, so the main reason we're not testing it is because there's no PR to adjust these values in the coincidence spectrum. So like, I think if we have a good idea of what values we want to be using, then. then we should, just go for it, I think, in DevNet 7, and, try to evaluate there. I know that that's not gonna give us a very good Representation because it's not going to be a thousand node network. But we can do a… Like a larger, definite, Later on.

Potuz: The reason we're not testing this now is that we've never had a devnet that was stable enough so that we move into testing for choice. we don't really have the basic implementations table yet. We're having problems with peering, we're having problems with syncing, we're having problems, like, isolated clients, so it seems to me that, like. On top of that, adding the stress of testing something new, it's… it was too much. That's why we didn't… we never tested this. But I think every one of us, we're assuming that these deadlines would be different than what they currently are.

Ansgar Dietrichs: That makes sense. Then the question is, is DevNet 7 then the right moment to now start testing this, to start having two separate deadlines? It seems like the tendency would be to say yes. But then, timing wise, we would probably ideally want to make the decision. I mean, again, by the end of this week, ideally, of course, today, the thing is, of course, this is a question not just for the elfs that directly like it's it's more a CL side question. It does affect the EL. But more CL side questions. So the question is. Whether we could… we have some candidate numbers, and then confirm async with the… with the… on the CL side, that that works for everyone. Do we have good candidate numbers? Like.

Could we today pick, could we now basically pick, pick some sort of candidate?

Potuz: 3…

Ansgar Dietrichs: So.

Potuz: The 9 are very good.

Ansgar Dietrichs: Three, six, and nine.

Potuz: Yeah, that's what is very safe for the target gas limit that we were thinking.

Barnabas Busa: But the other session deadline really doesn't need 3 seconds, does it?

Potuz: Well, read Carlos's report.

Barnabas Busa: Have you got the link?

Toni Wahrstätter: I think the safest will be to start with three. And then after we ship the PBS in Glamsterdam, we can start doing analysis on mainnet and see, for example, if we still observe a second of timing games, then we can likely go to two seconds. like, I would say we just observe how the network is doing, and then push for 2 seconds in Hegota.

Potuz: I also think that we have the slack and the problem of shipping three is that this slack will be taken over by builders. So it would be good to try to target less than 3 seconds. But at any rate, this is not really a hard fork and we can actually coordinate this. So, it's not really a problem.

Ansgar Dietrichs: Okay, so then, can we basically say from our side we would like to go with 3, 6, and 9, and we just confirm with the… And by numbers, would you be able to confirm with the CL clients that they are all okay with 369, so we could finalize this by the end of week and have it in DevNet 7?

Barnabas Busa: So I think what would be a bit more reasonable is if someone made a PR for the consensus pack with the adjusted parameters, and then we could finalize it on ACDT. And then, ideally, we could have a new Alpha 12 release out with the 7688 and this change. And then we could target a launch around next week, Wednesday.

Ansgar Dietrichs: That sounds good to me. Does that work for everyone?

Barnabas Busa: Justin, could you please open a PR for 369?

Justin Traglia: Yeah, I will. Or I guess how I'll put us to it since he's already working on it.

Ansgar Dietrichs: Sounds good. But then, this might have been the last item for DevNet 7. Is there anything else DevNet 7 related? Any other remaining open question? Anything we should bring up now?

Marius van der Wijden: Yeah, maybe just that there's the discussion. happening for for 80 37, and the 2, 7, 80 dash intrinsic dash tx dash gas channel on our ether Rd. And it would be nice for our clients to chime in there.

Ansgar Dietrichs: Sounds good. And I think Dragan had a comment in chat earlier saying that Guru gave a good summary of the alternative. I'll paste the link in high level as well. I hope this is the right link, should be. Okay, and there as well, the idea would be to basically for this decision to be fully made by tomorrow, is that right? Or by, I guess, by Monday's ACDT?

Dragan Rakita: Monte.

Maria Silva: I, I mean, we…

Dragan Rakita: Probably.

Maria Silva: We have, we have a PR already where we are discussing, I would say ACDT would be a good, good goal to reach, so let's have the discussion today and tomorrow and try to Close the PR by Monday.

Ansgar Dietrichs: Okay, cool. Yep, that seems like a good target. Okay, then now I think this might have been all the DevNet 7 related topics. Any, anything else? Okay, then, that's great. Then we can move on. One more quick Glamsterdam item just to shout out. There is the question of choice of mascot for the Glamsterdam hard fork. Do have a look at the comment by Andrew in on the agenda item. Okay, then next up we have. Hegota planning, in particular, from the ACD coordinator side, we got together and we, think that it would be reasonable now to set a deadline for the proposals.

So we can then go over to start, scoping. We gave guidance in advance that that would, we would, we would basically give a 4-week, heads up. To be a bit more kind of permissive here, given… given the ACDE-ACDC split, we would… we would do 5 weeks, so that it's 4 weeks from… from first mention on the ACDC side as well. That would put us to August 6. So, unless there's any particular protest here, I think we would just go ahead and say that August 6th is the deadline for Hegota EIP. proposals. Okay. No immediate protest. So then we we go ahead with that. and then we have a few more Eips proposed for a go to go through today. The 1st 2 were by Thomas.

8250 and 8272. Tomorrow you're on the call.

soispoke: Yes, yes, I'm here.

Ansgar Dietrichs: Then go ahead.

soispoke: Can people see my slides?

Ansgar Dietrichs: Yes.

soispoke: Okay, great. Okay, so hi, everyone. Yeah, I'm very excited to, propose the two EIPs for Hegota today. So the first one is EIP 8250, and it's called Kid Nonsense, and the second one is 8272, and it's recent routes. And so, before I get into what the specific EIPs do, I want to just, like, clearly state sort of, like, the goal. And what these, basically, two EIPs would enable, which is… It's, like, native, trustless, censorship-resistant, private protocol transactions on Ethereum L1. I think it's, like, very exciting. One thing that I also want to say is, like, these EIPs are not about enshrining, like, a full sort of, like, privacy pool in protocol. Instead, the goal is really to let privacy applications and protocols develop their own designs, compete, innovate, and the key thing that key nuances and recent routes enable is basically

I see them as, like, the minimal upgrades we can do, so that private transactions benefit from the core properties that are given by the protocol, and those core properties would be trustlessness and censorship resistance. I also want to say that key nonces and Recent Routes are not the only EIPs that are needed to get there. They really do sit on top of frame transactions, and they, you know, very heavily benefit from FOCIL. Of course, the nice thing is that FOCIL is already CFI'd and from transactions it's CFI'd, but yeah, I mean, the two APIs depend on… from transactions also being specified. Yeah, another thing I need to mention here, just because it runs through the sort of, like, rest of the presentation, is

the relationship between FOCIL and FOCIL. FOCIL is validity-only partial statelessness. And so we are preparing for a world where all nodes no longer to keep the full state, need to keep the full state, just, like, parts of it, I guess, which is, like, the partial, what partial stands for. But, like, the thing is, like, FOCIL included, to do their duties, they still have to check that a transaction… that transaction is valid, before they can put it on inclusion lists. So they need at least some partial state to do that. And VUBS is exactly that part of the state, that's relevant for censorship resistance. It's, like, the bounded state that a node is Guaranteed, and will be guaranteed to keep in the future, so they can validate transactions in the public mempool and build inclusion lists.

And, yeah, it's pretty important for the two EIPs, because it gives us, like, a very neat constraint, that we'll use, to present, both EIPs, because anything… needed to validate a private application transaction or private protocol transaction, like its nonce or its Merkle root, has to live in VUBS, otherwise it can't benefit from, sort of, like, FOCIL, inclusion guarantees. And so we'll see that both 8250 and 8272 are really about moving, one more piece of validation state into VUBS. I'm also preparing, like, sort of, like, an informational draft CIP that will explain this in more detail. But yeah, so I thought… the best way to introduce these EIPs was to give a super, super brief overview of the problems privacy protocols have today, and then explain, sort of, like, why the EIPs actually solve them.

And so, you know, if we take an example like Tornado Cash or Reagan or privacy pools, like, they differ a bit, but the concept is relatively similar. So, let's say Alice wants to swap or transfer privacy on Ethereum today using a privacy protocol, Typically, her balance is hidden inside a note in a Merkle tree. And… When she wants to swap her wallet, build the transaction payload with input nodes that are being spent, sometimes a fresh output commitment, very importantly, a ZK proof of ownership and balance. And then it also generates nullifiers for the spent notes to avoid double spend. And yeah, a recent Merkle route that we'll also explain a bit more later. And then the contract call to the sort of like actual privacy protocol. So whether it's like Railgun, Tornado Cash or privacy pools, it's the same.

Thing. But the big problem is, she can't… send it by herself today, while staying private. Basically, if she uses her own wallet to fund the address and pays for the gas, it links her wallet, which, like, defeats the purpose of privacy, and if she doesn't want to do that, well, she can't, like, she has no gas to sort of, like, pay for. for the transaction she wants to submit, so it doesn't work either. So today, what she does instead is, like. She uses, you know, trusted third parties, and so her transaction payload is sent to that third party, whether it's… we call it a relayer or a broadcaster, it's… Same sort of, like, high-level idea. And it can be via, you know, P2P encrypted networks, like Waku for Railgun. It can be also just, like, directly, or using Tor or Mixnet to try to help hide her IP. But the thing is, like.

yeah, the broadcaster or relayer is supposed to sort of, like, decrypt the payload, build an Ethereum transaction, sign it, and pays gas, so… and pays the gas, so, like, basically, on-chain, the transaction comes from the broadcaster and not from Alice. The problem with that is that using a third party is obviously a very obvious censorship vector, so if the broadcaster, you know, goes offline or doesn't like Alice, then she can't transact at all. And so, the first thing that solves this is 8141, and I'm obviously not gonna get into it too much, because most people know it. But it really does allow to split validation, gas payments, and execution in two different frames. And it's very, very important for privacy transactions specifically, because it means users can now submit native transactions in the sort of like public mempool that use trustless paymasters instead of like…

Using these… Trusted third parties. But the thing is, like, when… if you do that, there's still a problem, and that problem is, very, yeah, specific to privacy, but basically we want the visible transaction sender to be the same for everyone, and so we expect all users to send their transactions to the same sort of, like, privacy BAP contract. So, in that case, Alice would, like, stay hidden inside the SDK proof, and not visible as, like, the actual transaction sender. And so that's nice, it works, like, it gives us, like, a common public envelope, and it's really good for the anonymity set, but it also creates a weird, sort of, like, sender nonce bottleneck, with the current way we are doing nonce.

So it's very simple, but, like, yeah, you know, imagine Alice and Bob, are, both construct… constructing friend transactions with, like, the same transaction sender, that is the Privacy.dev contract. under the normal sort of like legacy nonce model, they both read the same sender nonce, so let's say 42, and we can't really expect them to coordinate. So yeah, one user's inclusion will invalidate the other pending transactions from that same sender nonce. So I think the right mental model is like the nonce race. And this is where 8250 is useful, because it lets many transactions use the same sender while living in different nonce lanes. So instead of like one account nonce, the replay domain now becomes a pair with nonce keys and nonce sequence.

And so if the nonce keys are set to zero, then it reverts to the normal legacy account behavior. But for privacy dApps, the natural thing for them to do is to use nullifiers for nonce keys. And so how it works is like you use nullifiers for nonce keys, you can submit many transactions. It won't conflict like with the transactions of others. And the first use has the nonce sequence set to zero and the keys are consumed when like the payment for the transaction is approved. And very importantly, we will store the key nuances in a system contract that will be part of VUBS. So again, you know, it's part of state that can benefit from FOCIL inclusion guarantees.

And that leads us to 8072, which is recent routes. And I mentioned that a private transaction proves ownership and balance, but ownership against the recent Merkle route. But basically today, the way it's done, it's, like, each privacy protocol keeps that route in its own contract storage, so Merkle routes are, like, scattered all over the state and not standardized, which means, like. if you have, like, a partially stateless intruder, we have no guarantees that they will be holding the root of a given ZK proof that is submitted in a transaction, and that it depends on. So, 8272 is all about fixing that. Basically. it's another system contract, and each privacy dApp writes one new route per block into, like, a standardized recent route buffer, and that route… that system contract is part of FOCIL, so again, like, you have the routes and the key nuances, meaning the nullifiers that are, like.

Both in system contracts, and they are both part of VUBS, so they can benefit from FOCIL. I guess two small design points is that… We keep a window of recent routes, not just the latest, because the tree can change between whenever sort of like Alice builds her ZK proof and when it's actually is included. So the window keeps her proof valid and based time for inclusion. Another design point is that… routes are written once per block, not per transaction. Otherwise, you could have, like, an attacker that could cycle through the whole window in a single block and invalidate every ZK proof that are not yet included. And so if we zoom out a tiny bit.

It's basically, structurally, a very similar object to key nonces, and the transaction will declare upfront exactly which states it depends on, and that state will be used only for validity, and it's also bounded in size. And, yeah, so that's what Les… basically, those two… You know, we've seen that it gives both the trustless, sort of, like, property and the censorship resistance property we want from FOCIL. Yeah, that's pretty much it. Thanks. I… yeah, I do want to say I really hope we can ship these two additional, sort of, like, EIPs in Hegota. I feel like they are quite minimal in terms of actual complexity, and… you know, I mean, yeah, they do sit on, like, two larger EIPs that are for stolen from transactions, but they would allow, like, a pretty drastic improvement for privacy on Ethereum L1.

Also, it allows us not to be too opinionated about enshrining one particular design, which I like, and it's also quite aligned with Ethereum philosophy, I think. Yeah, you know, like, letting app developers sort of, like, innovate and come up with privacy apps that can be only built on Ethereum, and are just… are maybe not just about transfers, it's also quite exciting, because it's a… it doesn't really exist anywhere else, like, private DeFi and things like this. And… yeah, on the resource side, we have a pretty good idea of what would be needed to make private transactions PQ secure in follow-up forks, so we are working on this, but, like. It will only be possible if we ship the sort of, like, core primitives, first.

And then the last thing I wanted to mention is, like, ethrex is already working on a devnet, trying to integrate 8.141, 8.250, and 8.272. And so, there is a bit of work started there, it's early, but please reach out if you're interested in working on this as well. I think there is a lot to do, and we would love some help. Thank you.

Ansgar Dietrichs: Thank you very much, Thomas. Any… Questions for now. I think I would keep it brief here. So maybe only if it's like structural questions. Guillaume. Yum, you're muted.

Guillaume Ballet: Yeah, sorry, yeah, yeah, quick question about 8272. What makes it necessary when you already have 2935? Which gives you the… The root of the block? And, that you could use, since you're using a ZK proof, you could pass the proofs from the block root all the way to the… to the format you're, sorry, to the state root that you're targeting. And this has the advantage that if you ever change the tree format, you don't have to worry about each individual account having a state root. Whereas, with this EIP8272, you would be enforcing forever the… the… what's that called? The… each… each account having their own state route. So yeah, I was just curious, why… why not go for 2935?

soispoke: Yeah, it's, it's not for the block route, it's for the Merkel route from privacy protocols, so it's, it's quite different. It's the literal, like, you know, privacy protocols do maintain their own Merkle trees, with their own Merkle root that proofs has to, have to prove, like, SDK proofs have to prove against, and so that's for this, it's not for the, the block root.

Guillaume Ballet: Those, routes are somehow embedded somewhere in the state, right? Otherwise, no one commits to them, and you don't have any security there.

soispoke: Yeah, I'm not sure. correct.

Toni Wahrstätter: Correct me if I'm wrong, but I think the reason was that you can't… you cannot access the 2935. routes in the verify frame. Was that the problem? I don't remember it exactly. because what what Guillaume says makes sense in general. that you could just prove it against the state. You have the state route. Of course, this would mean more call data. Yeah, I don't know.

Ansgar Dietrichs: Okay, then maybe we can take this question offline, though. No, I don't. I don't want to cut it too short here, but like it feels like, I mean, it seems like a reasonable question to to dive in more, but probably not not right now. okay. Any other… comments on the on the specific on the presentation. Otherwise, then I would move on. Tony, you also had two EIPs you wanted to propose, 7862 and 8146. Do you want to respond?

Toni Wahrstätter: Yes, this will be very quick. One second, I will quickly share my screen. I also posted the presentation to the chat, I hope you can see it right now.

Ansgar Dietrichs: We can see your screen.

Toni Wahrstätter: Perfect. Yeah, those two AAPs are delayed state route and block level access list sidecars. So, let's start with the delayed state route. It's It's an EIP by Charlie, Dan, Justin, and me, proposed two years ago, around about that. And the original idea is to do the same that we are now doing on the CL, essentially delaying the posts, the state route on the EL, which means we don't include the post state route into the header, but we include the pre-state route. So everything is delayed by one block. And the problem we are trying to solve with that is that today. Builders, they construct, like, a few thousand blocks per slot, because they have a lot of different candidate blocks that

are all submitted to relays, and for each of those blocks builders have to compute compute the post state route. And this is a lot of work, and the same work will in the future also face Prove us. So zkVM provers will, if they're the same entities as the builders, they will face the same problem, that for every block. that is built, you need to compute a different post state route. This is prevented by just making sure that each block validates the post state of the previous block. And this is essentially everything. The cost is that, for like clients, for example, proofs will be delayed by Yet another slot. I think they're already delayed because of the, sync committee.

And this will just add one slot of delay in addition. And one nice side effect for builders is that builders can also build optimistically by just using the Block-Level access list of the previous slot, apply it to the state, and then start building On top of the correct post state, while still validating the previous block. So this is mainly an EIP that, helps local builders, professional builders, and potentially in the future, provers. But this is still to be figured out what the exact impact on zkVMs is. The specs are super simple, so what we would do is we would just, Instead of validating the post-state route after execution, we would validate the pre-state route before execution, and the final change would basically be replacing the post-state route field in the header with a pre-state route field.

And then the second EIP is by Raoul and me, which is Block-Level Access List Access List Sidecars. And the idea there is that today we put the Block-Level Access List Access List in the execution payload envelope, and the idea is to take it out and have it being a separate object that is gossiped over a separate gossip channel. And, like, a separate gossip topic. And the commitment from that separate object would be the same as the execution payload envelope, so we would have a commitment to this, to the root of this BAL object in the bit. And the PTC would then… also enforce the availability of this new object. And the cool thing here is that we could make sure that the BAL is received earlier than the payload.

So, CLs would receive the Block-Level access list, they can directly forward it over the Engine API to the EL, and the EL, without having the transactions yet, could already use the BAL for prefetching state and also, calculating the post state route. So this is quite nice for streamlining. And the thing why this works is because with ePBS, builders cannot publish the payload. at the time when they see the commitment to their payload. So at the time when they see the bits being included in the block, they cannot yet release the payload for security reasons. So they might wait until the end Until the attestation deadline. Because there is signed data in the payload. So, for example, builders put their own transactions in the payload, those transactions are signed, and to prevent builders

From being unbundled, they might wait for 1 or 2 seconds at max. until they release the payload. For the BAL, this doesn't apply, so the BAL contains nothing that is signed. and nothing that can be unbundled, so builders have more security in releasing it early. And this would, in the end, like… downstream help ELs execute the block faster. And what we could do is, for example, have a deadline for the PTC at second 5, for example, or second 4, a few seconds earlier than the payload deadline. And it's From a specs change perspective, it's very minimal. You would add the block access list root into the bit. And… new gossip topics and new engine API topics. For the EL, one thing that would change is that the EL would now receive two messages. So, there is the payload, and then there is the BAL, and usually the BAL would be

pass to the EL before the payload, but of course, this must be handled flexibly, because we cannot guarantee that Right. And that's basically, all the changes this EIP would come with. Thank you very much.

Ansgar Dietrichs: Great. Thank you. Are there any comments or questions for this presentation, Justin?

Justin Florentine: Umm. Thank you, Tony. This is awesome. I can clearly see how there's a ton less hashing going on here. Who do you think benefits from this in the protocol? Which different actors in the protocol are going to actually yield the benefits from reducing all of this work that needs to be done to recalculate state routes. Now that the ball is really our representation of where this data is at.

Toni Wahrstätter: So, for the first EIP, for the late stage route, I think the main people profiting are builders and potentially provers. For provers, we still have to look into this a bit. I'm currently in discussions with the zkVM team. And as far as Ignacio and me were discussing, it looks like provers will just benefit Just like builders benefit, so they will have, like, one or two additional seconds That they can use otherwise, because they don't have to calculate thousands of post-state routes, but only one. And for the second EIP, I would say the users are the main… The main entities benefiting, because this would essentially allow us to scale even further. So we would, make sure that ELs can use the time they have even more efficiently, start with the prefetching of the state, which is, among the most expensive operations, start with that very early.

And when the transactions arrive, EL clients potentially have all the state fetched already, plus potentially have already calculated the post-state route. So I would say the second EIP, the BAL separation from the execution payload envelope, is mainly a scaling feature.

Justin Florentine: Thanks, Tony.

Ansgar Dietrichs: Any other questions. Awesome. Well, thank you, Tony. And we have one more EIP. I think it was by Ben, EIP8298. Ben, are you on the call?

Ben Adams: Yep. So this is a set code from… Operation? Opcode? And the idea is merging, EIP7851 that was presented Lost ACD? Or the one before? And AP58. So you, you provide an address, to the opcode. And let me put this in chat. And it copies the code hash from that to the current address. And the idea behind that, why you don't give a code hash, is you need to ensure That the code is on chain, and it's not pointing somewhere random. And also there's no consensus. on what's not There, so, I think if you do a full sync, you'll end up with less, sorry, a snap sync, you'll end up with less.

Contracts. Because some aren't attached. And the idea is, in the… 8… sorry, 7851, which was the… Upgrade for, 7702. There were some additional complex rules to prevent signing and so forth. But the set code from turns the contract in… sorry, turns the address if it was an EOA, Using, 7702. Into a proper smart contract. So, naturally. With the current rules, the transaction pool blocks Transactions being signed from… That address. So you get that for free? And then there's, the other EIP that it would

So the cover is the idea. that I think… 90% of contracts on Ethereum are duplicates. But when they're deployed, you have to put all the code In, in the transaction, even if you're doing it. The alternative is creating a proxy. But… Most users are trained not to trust proxy contracts, and it has additional overhead, so you either pay A lot of gas to essentially just copy a contract. Or you pay additional gas per transaction to do a delegate call. And then this would have… so you could have, like, the Uniswap V2 pool, which… essentially is always copying the same contract, but paying the full gas for, Create 2. It would just be selling the,

Code hash in the contract, which is very light in comparison of trying to deploy all the code. And then you could… From there, you can see emergent behavior of libraries on chain and things like that, where people deploy Contracts with addresses that, you know, like a common token contract, and then people would say, okay, copy the common contract For… for this token. To my… my new deployment. There we go. Any comments?

Ansgar Dietrichs: Okay, sounds like no immediate comments. Thank you, Ben. And with that, that would be all the EIPs proposed today to present it for Hegota. You know, again, reminder, everyone, we have two more Hegota calls. ACDE calls, the one and two weeks and the one and four weeks, for further proposals, and then we will have the deadline for… for Hegota on August 6. Last up on the agenda, we had, in the miscellaneous section, Pooja had a few housekeeping items. Pooja, I think it's probably doesn't make sense to go into the specifics on the call, but could you maybe give a quick rundown of What's in there so people know to look into it?

Pooja Ranjan: Absolutely. Thank you so much, Ansgar. So I was looking into the Meta Eep of Glamsterdam as well as the forecast, and trying to make sure that we have all eips, and we do have a single source of truth. That is Meta Eep. I found Meta Eep 7, 7, 7, 3 out of sync. So made a Pr. Where we are trying to fix Like, put all the statuses and stages in place. I have one question for the group is about EIP 7610. I understand it has been deferred from DevNet 6, but I could not find it in DevNet 7. However, I see that in Meta EIP. So just curious, is it still the part of Glamsterdam upgrade or not?

Ben Adams: Sorry, what was the number.

Pooja Ranjan: 7610. The eip is revert creation in case of non empty storage.

Gary Rong: Sorry, what's the question?

Pooja Ranjan: The question is if it is still part of Glamsterdam or not.

Ben Adams: I, I think it. In theory doesn't need any actual change, it's the clarification of the protocol. But I could be wrong. So yes, it would be in Glamsterdam.

Pooja Ranjan: Perfect. So that, yeah, so that should be part of MetaEIP, right?

Ben Adams: Yes. And it's… it's in effect deployed. Already.

Pooja Ranjan: Very well. I asked this question because I could not find this Eip in either Devnet 6 or Devnet 7. The list that is available on forecast. Well, that's fine, and I understand this proposal is in Cfi, so that should be there. Another quick request for the author of EIP 8282. It seems like the EIP has been approved, but it is not being merged because of some fix that is required on HTML side. So please make sure that you make those changes so the PR is merged. Once that PR is merged, the PR for updating Meta EIP can be merged. And one final request to all the EIP authors whose EIP is in the Glamsterdam upgrade, now that we are towards the end of DevNet, that means we'll be soon moving it to public testnet, we should have all the proposal in review status.

Most of them seems to be in draft status now, so kindly take some time out and update them to move it to review status. So when we are in public testnet, we can move it to the last call. That's all from my end. Thank you so much.

Ansgar Dietrichs: Thank you, Peter. Yeah, and I think this is all, at least everything we had on the agenda. Is there anything else, anything anyone would want to bring up today? Okay, nice, then we can give you 15 minutes back. That's the end of the call then. Thank you everyone for attending and I'll see you again in two weeks or next week on ACDC. Bye, everyone.

Marius van der Wijden: Yes.

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