All Core Devs - Execution #203

Transcript

Tim Beiko: Awesome. Thank you. Um, welcome everyone to ACVE number 203. Uh, bunch of things on the agenda today. Uh, lots of Pectra spec stuff. Um and then discussions around the gas limit on holki RPC standardization uh node requirements and uh EIP editing. Um to start I believe DevNet 5 has just gone live. Um Perry, do you want to give us a quick update on the DevNet?

Parithosh Jayanthi: Yes. So uh yeah, DevNet 5 uh went live like half an hour ago or something. Uh you can find all the tooling links here. Um Electra activates at epoch 4 and since then we do see some um issues with gas estimation I think on Ericon but we'll um yeah collect some logs and post it in there. Um I'll uh share the link of what images I'm using but essentially it's it's mostly just an updated version of uh what's been on the interop channel. And thank you to all the client teams for sprinting and moding stuff in so we can get this.

Tim Beiko: Thanks. And yeah, did Electra activate right before the call? Is that what she said?

Yeah, like 3 minutes before the call.

Tim Beiko: Nice. Um, great. Any team want to share anything else on the DevNet? Okay. Um if not then uh we can discuss all of the potential spec changes falizations perra and see what uh where we go from there. Um I'll go in order from the agenda but the first one there was a PR uh from Powell on EIP7623 about uh the gas refunds. I see it's

been merged already, but was there anything uh that people wanted to discuss about this? Uh I don't know if Powell's on the call. Yes.

Um yeah, I think this this issue has been solved to the point that tests were fixed and all of that. So the issue is uh if I remember correctly um like the final tuning to the transaction gas cost when you need to apply this this minimum gas cost that was computed before um I mean it wasn't clear by the spec uh that it's supposed to be done this step should be done after refunds are applied

or before the refunds are applied and I think we agreed that it make much more sense to apply this cap after the refunds but actually the tests and the reference implementation did the other way. So that has been corrected in EOS and then in the execution spec tests and I think everyone is on the same page. So yeah consider that solved.

Tim Beiko: Thank you.

Anything else on this issue? And I assume this PR was not included in DevNet 5. Is that correct?

Parithosh Jayanthi: Yeah, it hasn't been included yet.

Tim Beiko: Okay,

Parithosh Jayanthi: got it.

Mario Vega: Wait, it is uh it's on the 1.2 uh release of East. So, if they're passing the test, then it should be.

Tim Beiko: Yeah,

then it has fitting. Yeah.

Tim Beiko: Okay, great. Thanks for clarifying my um Okay, then the next one. um was about EIP7840.

Mere had a PR updating the base fee update fraction. Uh Marc, are you on the call?

Marek Moraczyński: Yes. Okay. So I can give quick context. So we introduced blob parameters in the EL configuration to specify the blob target and the max blob value per fork. However, in in meantime, we introduced another EIP for blob increase EIP 76 91 which modified the block fraction constant in the petra fork. So this created an inconsistent situation where some blob parameters were hardcoded while others were in the configuration.

So uh it was a little bit messy and this PR uh resolves that by moving the blob fraction into the E configuration alongside the other parameters. So target and max and actually I think we have support for this PR from all EL client teams and testing team as well. Yeah,

Tim Beiko: thank you. Um yeah, does this seem like there's support uh on the PR directly? Anyone thinks we should not do this?

Okay. If not, then I think we should go ahead and merge the PR. Um and once we're through the specs uh discussions, we can decide whether um we think we need another DevNet to test this or uh and other changes or if uh we may want to move straight to test nets. Um but we should move forward with uh the PR7840. And I guess somewhat relatedly, uh, oh, sorry. Uh, Yokam said we should clarify the PR a bit more before merging. Um, and that there was a comment on it. Um, yeah. Do you want to maybe expand on

your comment, Yokim?

Yes. Sorry. And like there was a comment also by Marrick about the defaults and I think we should uh clarify that but that was just a comment which I got on discord. So we will check after HD.

Tim Beiko: Okay. So that's maybe aim to have this merge before Monday's testing call if makes sense.

Yeah that will work. Yeah. Cool. Okay.

Tim Beiko: Um anything else on this PR? Okay. If not, uh, next up, uh, Alex brought up the, uh, blob base fee at fork boundaries, I believe. Um, there

was a testing issue. Um, yeah, that that that got triggered here. Um, I don't know if Alex, you want to give it a bit more context and suggest how we should update EIP7691 to make this clearer.

Sure. Uh, can you hear me? Okay. Yep. Yeah. So um yeah this came from an issue during testing and my understanding is that um essentially it's a question of like when do we make the changes as we go to change the bulb count. Uh the reason this is sort of tricky is because the way the base fee function update like the the function we use to update the

base fee the way it works is it uses the parent uh parent header I believe and so then the question is like at the fork boundary do you use the header which is like a bit weird because it's like new logic at the fork but you're going back to the previous fork or do you just want to go ahead at the fork boundary with the new fork rules and I think that was the issue. Uh there was a clarification, the reason I brought this up is because there was a clarification to 7742 around the same behavior and I think this is analogous behavior for 7691, whichever the Bob EP is. Um yeah, so I just wanted to bring it up and check with clients what they would prefer.

I don't think it really matters which thing we do, but we should all do the same thing.

Tim Beiko: Uh, Andrew.

Andrew Ashikhmin: Oh, guess that was a mistake. Um, oh, sorry. Yeah, Snot can correct me if I'm wrong, but I think in Aragon what we implemented is that when we use when we calculate the excess gas uh actually for that you you feed the the parent block and you use the parameters uh of the fork of the parent block but then uh when for for other methods you you use

the current block. So it's a bit tricky. Yeah. Because you might need for the same calculation you might have to use two blocks. But I believe it's actually it's consistent with EP 4844.

Right. So at the fork we'll use the parent header still uh to calculate excess gas.

Andrew Ashikhmin: Uh yeah.

Um yeah,

there was some other consideration from one of their client team because I think it's just easier to write this way. Um and it really shouldn't matter either way. So do we just want a clarification?

Uh and again, it's probably 7691, I believe, is the number. Um I'm happy to go clarify in the in the EIP. Yeah, I think Yep.

Andrew Ashikhmin: I think it would be great to clarify it. Yeah. Okay.

Tim Beiko: Roman.

Yeah. Clarification is great. Uh again, what is what is the outcome? It it's unclear. So for the fork block, do we use for the Prague fork block parameters or Prague parameters?

So how I see it for when you actually calculate the excess gas you use uh canon parameters uh for for for in that calcul excess blob gas but for the rest of the things uh you use uh factor parameters. Uh so that that does not make much sense to me because uh in in most language uh I read it said like once the fork is activated use the the new PRA parameters and well that the way I understand it is

the fork block is the fork activation. So we should use PRA parameters but Right. Right. Right. But for for excess blob guess the parent is used right. So and the parent still belongs to the previous folk. I mean for for I don't know the another example would be uh validating the gas limit increase or decrease for that the parent block is used as well you know but these are like these are pure functions I don't know I don't want to bike shed too much because like I

think this is insignificant I just want us to agree on something

Tim Beiko: and I don't know Mario do you want to give context from the testing perspective

Mario Vega: Yeah, basically just to echo Raman, I think I think it it it feels to me that if we use canon parameters on the first block of bra, it doesn't quite make sense. It feels like a one-off logic deviation to me. Uh also for for testing uh we should like we we never pass like um whether when we're filling a block in the test, we never pass whether this block is the fork is at the fork boundary. We always just pass brag and that's it. So for this to work we we would have to pass okay this block is

the far for granary because eels would have to know uh that it needs to use the the cano parameters which doesn't make sense. So yeah bas basically just I I agree with Roman uh uh just just favor the the using the the bra parameters at at the first bra block. Okay.

Tim Beiko: And this is what the testing behavior does today already.

Mario Vega: Exactly. Yes. Yeah.

Tim Beiko: I would then default to just clarifying the words in the EIP to match the behavior that we have in testing if that's okay for everyone.

It works for me. Okay.

Tim Beiko: Um great. So, if we can uh yeah, try to get this done as well before uh the the Monday testing call, that would be ideal.

Yeah, I should be able to make a PR to the EIP today. Nice.

Tim Beiko: Um, anything else on this?

The client is

saying it will make the G logic more complicated.

Tim Beiko: Oh, and Robot is saying that G already does this. Um, yeah, I assume some clients may have to change. Uh, regardless of what we do, it should not be a major change. Assuming that's correct, I think we should, uh, yeah, should just move move forward with this.

Yeah, in the interest of speed like client. Okay. He says he's okay with either way.

Tim Beiko: Okay, great. So, let's copy the behavior from the test to the EIP, get this merged in the next couple day, and then um yeah, if get or others need to update their code, they can do that.

Um and Melo, if you want to post maybe Oh, yeah, you did post already the PR the execution spec tests. Nice. Um, okay. Anything else on this one? Then moving on. Um, okay. The other uh spec change uh was one for the BLS pre-ompile that there were updates uh to uh the multiplication cost of the G2. Um I'm not sure if the author uh of this PR is on the call right now.

I can I can talk about it.

Yeah. Okay.

Um so like quick background is that um like original BLS EIP spec put some um like careful attention to the uh constants that are there and there is explicitly a sentence confirming that. So the the gas constant were picked in a way that they are divisible by 1,00 and in the end some formulas that are later used in the IP.

How to calculate the end gas costs for multiscal multiplication. Um it's in this formula there's division but it doesn't really matter what kind of division it is. By kind I mean usually we use integer division but uh it's mathematically also the same in this case. However over time we changed the gas costs constants and uh we didn't notice this detail and in the end now it matters and also the order of computation in some formulas matters.

So at least I can argue that the spec is kind of inconsistent with itself. Um and the easiest fix to the spec is this what has been proposed by radic which just corrects the constant. So it follows the previous assumptions. This is however not the easiest fix for the implementation because we need to update the tests and um I actually prefer to fix the spec rather than fixing implementations. I mean, yeah, I prefer to fix a spec and update the test, but I think there was some other opinions about it.

And um I also commented about these other options in the in the pull request. Uh but that's more or less the story about it.

Tim Beiko: Thanks.

Um sorry. So K, I don't understand. So if everyone agrees uh to divide in the same place or use the same uh formula using integer division um then that's the only change we would have to make.

Yeah, I mean that's that's is one of the fixes. I just for me it's like the the the least preferable one. uh because like this is why we noticed the issue is that we actually implemented it differently and that's why we actually spotted the bug. It wasn't that by reviewing the AP, it was just by implementation difference. Um secondly there are some like annoying small things that coming up from this because um at least on like some analysis level you will still have fractional gas costs. um like for example if you compute the the

cost of P compile for some number of points and then you will compute what is actually the cost per per single point you will get fractional values. So if you do any analysis outside of pure uh implementation you will need to handle this fractional cost somehow.

When

you

Tim Beiko: mean an analysis, is this like benchmarking?

Well, like plotting or like doing Yeah, it's it's something outside of the consensus, right? So, it's it's not like huge deal. Um, so I agree that's like the like the lowest effort fix is to agree that the formula that most of the

clients implemented is the way to go. But it's it's definitely not my preference. But if this is definitely the preference of all others, I think I'll be fine with that.

What

Marek Moraczyński: what is your preference to update this gas cost?

Yeah, that's that's the easiest. But we can also update the formula but in some other way. So there are three options we in my opinion we can select from update the gas cost as in the p request then this is like minimal spec update.

The secondly we define it division we mean is is just integer division but the order of uh we can modify the formula that it suits the current implementations more or less or we can modify it in a way that it actually also needs test updates and implementation update and we need to fix some like wording in some other parts of the spec. So I I I can see three options. Um yeah, but one of them gives you no work on the clients and tests and like more work on the spec.

Tim Beiko: And uh I don't have like an intuitive sense for this, but like what's the difference to like an average user if the gas cost for this multiplication goes up 500 gas? Like is this something that's called once 10 100 times uh in like transaction?

Um I think the diff the difference is is mostly I think aesthetical to my understanding because we already lowered that by more than two times.

Tim Beiko: Okay.

So it was now it's in the range of 23,000

Tim Beiko: right? So it's like Yeah.

So it's I don't know how many percentages is but it's like one digit one but we lowered that from around 4 40,000 to to my if I remember correctly. So I think it's it's not a big deal but uh if someone really cares about that to be uh precisely yeah so so I I think the change is rather in the like rounding and we just pick the the different rounding factor. Sure.

Tim Beiko: And then alternatively when we say like we would like require um like require specifying that everybody uses integer division like what's the where would we specify this? Um basically like how how do we enforce this? My fear with that approach is we all agree on this call to do this and we do this with the fork but it's like not clear to me where and how we can have test conditions for the the way in which this gets calculated.

Um no it's I think it's it's relatively easy. We we definitely can do that clearly in the specification and the test already covered it somehow that we can make sure that this is yeah because the test caught our our like difference in implementation.

Tim Beiko: I see.

So tests are there already. uh we can actually make sure that there's maybe specific tests that but uh seems yeah if you run just like different examples of different multiscolar imple uh multiscal multiplication cases with different number of points this is already covered

Tim Beiko: I see and would any if we if we did this

if we enforce using integer division would any client team have to change anything aside uh from obviously EVM1 but like would any like mainet kind team have to change everything or are they all passing those tests?

If you already pass DevNet five tests I think you're fine. If you didn't try it then you can find the same issue.

Tim Beiko: Yeah, in this case, if we can specify it in the spec clearly and we already have test cases for it, I would lean toward just enforcing integer division. um

it feels a bit uglier than changing the gas costs but also um yeah uh if we already have this and yeah I'm not that keen to delay the fork um over just uh yeah having another entire iteration cycle just over this but anyone object to Okay. So, let's have a couple thumbs up in the chat. Um, let's verify the spec to do this. Uh, Powell, is this something you can do in the next couple days?

I

I can do it.

Tim Beiko: Oh,

right. Sure. Handle that. Yes.

Tim Beiko: Yeah. Thank you. So, yeah, if can uh can clarify the spec ideally by Monday session call as well. Um it shouldn't require anything on the client end but at least we will have clarity. Um anything else on this topic? Thank you very much. Um last uh potential spec change for Peterra today. Um a bit of a bigger one.

Uh so there's uh hacken that was uh created to make a case to allow for delegation introspection. Um Julian, do you want to give context on the proposal?

Yeah, GM everybody. Um so yeah, if uh Oh yeah, great. Thanks for dropping it Tim. Uh so a little bit of background. I think over the past couple of weeks we've kind of talked about this idea of like code introspection and Xcode op codes. Um you know having sparked a new discussion in terms of like the way that we build things on 7702.

Um it kind of sparked this for us as well cuz you know after you know building with and then without you know prefix plus delegate address kind of realized it's actually a great a great feature that um is very useful wouldn't change the behavior of EF contracts but I realized it was a big sticking point. So, we decided to take the time to break down like what does that even mean just by saying it affects it may or may not be affected by eof is it aligned by eof um and kind of like breaking it all down um in this doc. So I would say you know the first maybe 70% is is is a lot of

background and then towards the end is an actual analysis on why we believe actually you know allowing Xcode op codes to act on the full EIP72 delegation designator for de delegated EOAS instead of just the prefix is like the best way forward and you know we hope that this final upgrade is update is like kind of the very last thing that we would want to add to 7702. Um, you know, leading into Perra, uh, you know, Dave is, you know, one one of the main authors and the the protocol engineer behind this deep dive, so he's

more than happy to add any additional comments, but I hope this is a a good background um, in terms of like what we wanted to get across and hope to get done today.

Tim Beiko: Thank you. Um, yeah. Is Dave on as well? Any additional comments? Hi.

Yeah, I'm here. Um, I think that that hits it all pretty much. I would just say that um there's some discussion um on discord about like oh should this make us reconsider EIP7702 mutability

or EOF uh code introspection behavior and we don't like recommend either of those things. We'd say that basically just this change for Xcode behavior um for 7702. It simply like would improve um like safety for relayer schemes. it doesn't like completely um you know warrant the need to change like mutability for 772 or definitely definitely not um code

inspection behavior for eof.

Um thanks Dana. So as far as features for eof um once

Danno Ferrin: something's added it can't be removed. So probably where we're going to start with with the EOF and introspection is the delegates is it's not going to be there because there's no code introspection in EOF. Um but because it's a thing that can be fixed by adding an op code or making a new op code perhaps a extate um it's not like we're stuck there. So just the plan going forward on this for you know initially for EF my my prediction is we won't have introspection of the delegate in EF code because it can be undone easier than adding it in and removing it later. we figure out we don't need it. We're really committed to trying if if you listen to the call there's a lot of

places we're trying to get rid of code introspection including how we're calculating hashes for eof create. So we're really committed to make no code in respection be the default.

I think we're we're completely aligned with that um vision like in in the doc it lines up or outlines how um we think that the removal of code introspection is a good thing um and that we you know hope that eof can include some notion of delegation introspection in the future but that it's not necessarily um needs to be included in the first version. Um also that yeah kind of differentiating between

code introspection and delegation in introspection. Um like imagine interactions between EOF contracts that have no external code introspection um but can only just check the delegation designator for EOAs then it would act you know simply like an implementation identifier um which I think would be beneficial for EOF contracts while like nowhere in that interaction would there be real code introspection ction. So, I think I mean it it'd be something to consider down the line like you said. Um, and yeah, I'm I'm not, you know, intimately

like aware of the details um for, you know, if that would make certain assumptions about code inspection, behavior breakdown. Um but I think we think that simple delegation introspection is like a far less uh complex like way to reason about interaction than fullon introspection.

Tim Beiko: I guess one question I would have is um

yeah to to what extent this is a big change um in in clients uh theoremJS seems to be like a pretty small change. yeah, does any other team feel strongly uh in terms of either the work that this represents or just the general uh yeah value of the feature Okay, I guess no strong opinions. Um,

my sense is people probably have not had the time to like fully review this. Um, I don't know how accurate this is. Um, I just read the talk the first time this morning. Um, yeah. So I I know I on one hand I would like us to make a decision today about what to do because if we are going to change this um we should do it as soon as possible um to not delay uh either like another devet or potentially moving to test nets. Um yeah, on the other hand, I think we

should make sure people properly review this. Um yeah, and I know maybe like a a question for Julian and Dave is like how problematic would it be to not have this change included?

I I'm not sure if Dave wanted to answer that. I I was going to say u Oh, go for it, Davis. You unmuted.

Uh yeah. So we outlined in the doc basically a um a front running attack that can be carried out against relayers um in like

relayer schemes that the EIP intends to like service. Um and so we were just pointing out that like to make interaction with delegated EOAS safer for relayers um this change would this would be beneficial for that while it wouldn't change any behavior for eof contracts and it also wouldn't change like safety for interactions with delegate delegated EOAs such as um like self sponsor sponsorship where you where the submitter of the transaction can trust themselves. Um, so this is really

just about like safety for relayers with

Tim Beiko: Got it. and yeah, Justin from Bazu says he's unclear and would like to talk to some of the wallet devs. Um my yeah my sense is if we're not uh if people need to review this more before making a decision um perhaps we can finalize this on Monday's testing call um unless people really want to move

forward with this today but I think maybe getting two three days to review this uh over the weekend and tomorrow would help us make a big decision.

Lightclient: Um, I mean, I think I'm I'm pro this decision and my only hesitation has been the interplay between this and EOF, but if people don't feel like this is creating some kind of precedent for how we'll deal with things in EF, then, you know, I don't really see a specific issue with this. if they need to add a new op code the you know is delegated op code something along these lines you know that's not that's not a big problem

for this change and it will come with

the thanks so the op code um I'm waiting to

Danno Ferrin: see on that to see if the market develops and if we need it it can be added later so I think the initial eof position would be to keep our existing code introspection And if the market shows that we need this, the path to fix it is to add the op code. So we have a way out. And I'm I'm kind of wait and see to see if we really need this. But again, this is another thing. If we put it in shortened now, we could never add it into legacy.

So it's kind of a sticky wicket to be in. Um but you know, as far as whichever way you go, um EOF has a way out. Um it might not ship in Susaka, it might ship in Amsterdam to get the full solution. Um, but that'll give us time to see how the market reacts to this and if there's a need for delegation introspection.

Lightclient: Yeah. Okay. Yeah. I mean, I'm supportive of it. I don't really see something that like uh Frasier said, this was sort of a tossup between the two behaviors when we were making this decision. And the reason that we went with the two byte specifier is because it was more similar to how

things behaved with respect to eof. And now we're in a kind of a weird situation where only the external code reading operations are getting this uh ef uh prefix where the code copy code size are actually getting the executing the executing code the code that was delegated to. So I find this the difference in behavior between these op codes weird. So this could be an opportunity to just like unify all of that together in a better way.

Tim Beiko: And I guess there was yeah one comment in the chat by Justin about uh wanting to talk to some wallet devs. Uh there's some responses that this has been talked about in the forums. Um, so yeah, I know. Do people prefer to move forward with this now in order to have sort of a a final spec or do we want to wait a couple days and make a decision on Monday? If we do make the decision on Monday, like are there specific people we'd like to bring in on the testing call or reach out to um in the in the upcoming days?

Justin Florentine: Don't we already need a DevNet 6 for the um GMOL stuff?

Tim Beiko: Potentially. Yes.

Justin Florentine: Um I think that's enough time for me to you know talk to the people that I'd like to talk to.

What we need six.

Tim Beiko: So we have two small changes. We agreed to the changes. Uh actually like the GMO the GMO we would not need the def because the um this is the current behavior that clients do. Um but then yeah we have already these two pretty minor changes around like the base fee uh update fraction and the blob base at the the fork boundary. Um I

don't know if we want to set up an entire new devet just to test these two relatively minor fixes. Um assuming we did then yes we should include the 7702 change. Um and then if I don't know if this 7702 change is the thing that you know goes from it requiring not requiring to require to requiring a

net

Marek Moraczyński: just small comment about block base fraction I don't think it will require uh the devet because um we can just update uh e clients with the new configuration and that's it. I think we can coordinate it without fet.

Tim Beiko: Okay. So, this 772 change then would be the one I I don't know would we actually want an entire new devet for this or would we be comfortable um you know having obviously static tests um and then potentially going straight to test nets with this change that has not been deployed on the devet.

Parithosh Jayanthi: So that I'd planned a shadow fork anyway um likely hostki and potentially mainet as well. Um so if we want we could just avoid a net life cycle and just integrate the change with the shadow fog. That would still give us let's say a weekish basically until uh enough time for everyone to pass hype tests um before we spin up the shadow fork and

then ideally we've made this decision by then and we either include it in the shadow fork or not.

Tim Beiko: Okay. So, I think what I would do in this case then is push this decision. Oh, like trying to said, we can put this in DevNet 5, meaning like we'd update the client versions. And

Lightclient: I mean, I don't know how far on people are. I think, you know, we're kind of at at the bleeding edge of DevNet 5, I suppose, and it feels like a very easy thing for us to update. I mean we are already determining if the thing is a 772 uh de delegating account and you know adding in the address to the

designator that we return is you know it's extremely simple.

Tim Beiko: Okay. So clearly regardless of whether we put it in DevNet 5 or if uh if we um just test it in a shadow fork, there's a path to testing this without requiring an entire new DevNet iteration cycle just for it. Um my proposal would then be to give people a couple days to review this and make a final call on Monday's testing call. Um, and if there's anyone we need to speak to or we want feedback from, either try to do this uh today or tomorrow or have

them come on the testing call. Um, does that seem reasonable? And then yes, uh, actually the other point is having a a PR to the EIP. If we could get this today, I think that would help. Uh yeah, that'll help us reason about the change. Um but yes, we should not launch an entire new demo cycle just for this. Um and then if it is uh if we do move forward with it, then it should be a pretty simple change. We can implement it after Monday.

And

Parithosh Jayanthi: in case someone can't make the testing call and has objections/s support then please at least leave a message on ether and so we can read it out of the testing call. Ideally we'd want support from every year

Tim Beiko: and yeah uh one last comment I'll hide from the chat is that we had this behavior in 72 before and we are now bringing it back. So, um, yes, it's something that clients have implemented in the past.

Anything else on this proposal? Oh, sorry. Okay, there's other comments in the chat now saying it was a different behavior that was implemented before. Um, so, okay. So then I I will close by saying this emphasizes the need for a clear PR proposing the changes. If we can get this today uh review it uh on Friday and then um discuss this on Monday's calls that would be ideal and I believe this was the last uh spec change proposal for uh Pectra. So uh summarize we have the 7623 change that

was merged already. Then these two changes around uh the blobs. So one around the base updates uh one around the fork boundary for 2537. We agreed we're not going to make the gas cost change. We're just going to clarify the EIP with regards to what uh division method to use and then make this final decision about 7702 uh on Monday's call once we have a PR up to property review. Anything else on the specs? If not, um, yeah, wanted to also highlight the audits we've done for the system contracts in Perra. Uh, I believe Frederick is on the call. I can give a

quick update on this.

Yeah. So in September as uh some of you might know we did a request for proposal for uh basically by code audit of the system contracts impra uh we had quite a lot of proposals uh I don't recall the exact number but uh maybe 15 something like that um and uh basically we moved forward with a handful of these entities um the these have now been completed by these uh firms. So uh we now have uh all the reports uh available for them.

So in the call in two weeks from now, I would propose that we invite them to uh to present the the findings that they have had um in yeah in their audits basically.

Tim Beiko: Thanks. And I guess just to be clear, all of the changes and suggestions from the audits have already been implemented in the contracts, correct?

Yeah. Yeah. Yeah. And we did like this, we can talk more about this, I guess, in in the follow-up call, but we we did this type of rolling audit where we had the first one do it, then we implemented a lot of the proposals, then we had a second one to do it and basically rolled

the audits like that to be able to cover as much as possible. Um, but yeah, they they've been implemented and there were no major findings. Um, thanks.

Tim Beiko: Thanks. Yeah, I think uh that seems reasonable to have a discussion about it and and answer any questions in the next call. I think if we can have sort of the actual reports um ideally a week or so in advance so that people can review them and and raise any questions ahead of time. That would be great. Um yeah, we can do a deeper dive on the next ACD.

Yeah, exactly. Yeah, we'll we'll add them to a repository. I can um make sure that they are distributed that way. And uh yeah, I will uh post where to find the the old docs. Sweet.

Tim Beiko: Any questions, comments on the audits? Okay. Uh yeah, thanks Frederick. Next up, um yes, I wanted to follow up again on um starting to think about test net releases and uh scheduling. Um so we

have the net 5 up right now. Um I expect we'll need to do a bit of work on this. Um and we have some like final spec changes to consider. Um I guess my first question would be you know how are clients generally feeling about moving to test nets? Do people feel like we want to start getting this done in uh say you know the next couple weeks? Um are there things that uh teams feel they need a bit longer to work on or to finalize? Um, and I guess related to this, do we want to um potentially fork both test nets uh using the same client releases or do people prefer to have two different

client releases and potentially a longer break between the two test nets? Um, yeah, how are people feeling about um yeah, moving this test sets And if there's no strong opinions, maybe my starting proposal would be something like we should set testn net fork blocks on the next ACDE in two weeks. Expect um expect client releases in the week after that. So the week of February 3rd and

potentially have a first test net fork on the week of um February 12th. Depending on how we do releases, we could have the second test net fork either the week after or two weeks after, which would be week of the 17th or week of the 24th of February. Um is that a schedule people feel is reasonable? Um okay. So no objections. I guess what I if there are no objections what I would do is yeah I think on the next um either

next week on the consensus layer call um or at the latest on the week after that we should um yeah start looking at at dates. Uh Perry has a questions about whether teams have started merging changes to the release branches. Seems like Basu has Oh yeah, getting a bunch of thumbs up. Uh, Basu, uh, Teu, Nevermind, um, breath. Okay, great. So, it seems like things are generally moving forward well. So, what I can do is I'll propose um I'll propose some potential dates and

fork blocks uh on next week's AC/DC and um we can take it from there. But we'll roughly target something like um the um sorry the last week uh or sorry the the early February basically for the first test nets working um which would give client teams like two weeks or so to get a a ready release out um and it seems like there's no objections to Great. Um, and then related to this, uh, Sophia wanted to bring up, uh, something

around setting the gas limits, um, as we, uh, as we put these releases out for test nets. Uh, Sophia, do you want to give some context on the gas limit?

Sophia Gold: Yeah. Um so for context, we're all aware that recently there was a push by validators to increase the gas limit to 60 million. Um in response to which some here found what is essentially an edge case uh preventing us from doing that immediately. Um I don't think this will be a one-time thing. We would like to more or less continually increase the gas limit over the next several hard forks. Um and there are currently uh se several threads of work that people are doing to enable this. Um but that also

means that we'll need to know what increases are safe uh well ahead of time and foresee uh problems with them. Um and uh so I' I'd like to suggest that the the way to do this would be to have Holki always have a higher gas limit than mainet. Um and unless there are any objections to this um and then I would ask uh client teams uh now to set the default limit on holski to 36 million and then when it forks to pectra uh go to 60 million and we can proceed from there.

Tim Beiko: any objections to this? Okay. Um, yes. So, we don't quite have a way to expect this, but I think as people start to uh work on their test net releases, we um yeah, we should make sure that um we include these changes. Oh, and okay, there's a comment saying BU already has this um TU as well. So great um Prism as well. So yeah, so the test net Oh, Prism Nether. So great. So test net releases can go with 36 and then

when we have a main net release, we can bump the defaults for the test nets to 60 million as well. Um and then there's a question by pus in the chat about the test net forking schedule around whether uh we have enough validators and hosts key to actually make it happen before mainet. Is there risk here that like holki doesn't finalize or something for long enough before mainet? Perry says we have enough validators under our control. Okay, we should be good for whole seat.

Okay. Anything else on um test net schedules or gas limits? Okay, sweet. okay, next up on the call, uh different topic. Um, Felix had a proposal around RPC standardization. I don't know if he's on the call. I think so. Felix, you want to give context on this?

Felix Lange: Yeah, I'm here. Can you guys hear me?

Tim Beiko: Yes.

Felix Lange: Okay. So, yeah, I posted this document a couple days ago just to clarify. Uh so um what I posted the document mostly so that people who aren't super familiar with this whole thing can can read a bit more but ultimately what I want to discuss on here isn't so much the document but some specific things that we should probably do now to move to move this process a bit forward. Um so first of all um this kind of started because I asked uh Perry from uh to include the RPC compatibility test as part of the hive run for the devet and

um the reason why this is because we have this cycle for this fork cycle we were actually pretty quick with adding the uh uh RPC compatibility tests uh for Prague. So there are some prog tests already in there and we are adding more right now. And so um it's actually very interesting. Uh basically we can use these tests to check if the clients implemented the more optional parts of four correctly. Like for example if they have support for the new 7702 delegations in ETH call and things like that. Uh and this is something we've never done before. But um unfortunately this testing doesn't really work because um yeah the clients still have issues

just you know with the basic test setup and uh so this is why kind of I started this effort. So I feel like you know I've been working on RPC standardization for a long time and um yeah it's just very frustrating because there's very little feedback from the client implement and I never really know if like these they find these tests actually useful or yeah if there's any interest to move the spec forward and then there are some open questions in general just like how are we going to be handling updates to the spec and what should be the scope scope of the spec and all of these things.

So on the specific question uh that I wanted to ask is just more generally do can we get some more support on trying to pass these tests and um should we have like a dedicated breakout call related to these things? Like maybe that could be a good start here.

Justin Florentine: Yeah. Hey, this is uh Justin from Bayu.

We're very interested in improving the RPC um specifications as well as potentially, you know, a lot of the things that were discussed in Discord I found very productive and we have a lot of interest in this. So um if the first steps in doing that is to make the um the testing um a little bit more of a gate to moving forward. I think we're all for that.

Marek Moraczyński: So we at Never mind also interested and we are actually checking those tests. I know that we are not passing all of them uh but uh sometimes there are like weird issues uh between for example G and

Netherm and actually I think we just need to discuss it more together.

Felix Lange: Yeah. Yeah. So there isn't there is a JSON RPC channel in the discord uh where we generally discuss it. Uh I've brought up some of the things before. So mostly the like there are two classes of issues. So that some clients do not pass a test because they cannot load the test chain or because they have some other issue with it that prevents them from even running the test. This is currently the case for Aragon and Bizu. And Aragon has been broken on these tests like at least in the runner that we use for more than a year. So I have actually no idea what's the status of of Aragon and related. I just gave up trying to make it work. Um the um

other issue is that once the tests are actually running we see that there are some minor details in all kinds of places and I've tried to elaborate a bit on the document like kind of the the specific kinds of things that happen on there and we do have to come to an agreement and generally I think we do have to come to an agreement of like what's in scope for example specifically for the core devs to decide on event because ultimately what the RPC interface It's implemented by so many people in so many different contexts that it feels weird to just only have this be like a core dev thing where we like we make these decisions. However, there's a subset of the API that which it's the subset that's currently in the specification. that thing I do think the Ethereum core devs have some authority

over and we need to figure out like is this it or do we ex do we want to expand this set of of of functionality or yeah what how should we handle these these kinds of things and it's more like a process question I don't I just want to know like where is the forum where we can come up with a decision um ACD was used as a forum in the past but it's just kind of weird And so yeah I just I just don't really know

like

Tim Beiko: one question I would have for you uh what are the other people you think or projects we need to include in these discussions like is it like you know infrastructure providers basically or like L2s that um it's more about the

users of this than like the forks of the clients on say L2s

Felix Lange: I mean yeah so it's the the wallet the wallet also provide this API. It's the infrastructure providers basically everyone kind of

Tim Beiko: okay got it

is

Felix Lange: is somehow involved with this and I mean we cannot define everything for everyone I mean and for even now it's not even clear if the wallet should be included in this process or like if they should have their own process which they don't it's just this is a very organic thing like the RPC is one of these things that is just like a inherently very organic thing because it just grew out of everyone trying to kind of support the same thing and with the standardization we are sort of like

postfacto trying to figure out like what can even be standardized. So that's like this that is why it's so messy is because there wasn't really a spec for the longest time and now we're basically retroactively trying to create one and trying to align everyone as best we can. But I mean, a lot of these actors will just not be won't even be looking at the spec.

Tim Beiko: Got it. Uh Roman, you've had your hand up. Wow. Uh yep.

Andrew Ashikhmin: So very much in favor uh of this effort. Uh my only request would be if uh standard in this case would be considered the minimal subset of functionality that every client should

provide. But the clients are free to extend their method uh their responses with any fields they want. And uh so basically changing the uh assertion equality test to be more relaxed regarding additional fields.

Felix Lange: Yeah, this is this is this now goes bit into the detail. I also don't really know how much time we honestly have on here. So I uh so I don't want to go too much into the whole detail, but this is actually kind of a good point. So the thing is that at the moment we have the situation that all of the clients have

various extensions to the spec and um I've tried to highlight a little bit in the document one way out of the situation would be to just freeze the extensions at their current state make all of these a part of the spec as they are right now and then basically we we would be in agreement on the current state and then in the future we would have to come up with some other process where the clients can add extensions if they want to. I think the current method is not super sustainable with like everyone just sort of like adding the extensions when they feel like it because it means we will never reach uh this point where the standard stuff is supported like we can never fully agree on the API in the current state and

that's why yeah I kind of put in this request that would be good if actually this is something we always kind of wanted is like that clients would somehow push back a bit against users who want to put in these extensions and just literally say that like okay there are certain extensions you can make but when it comes to certain other extensions it requires a much more extensive uh governance process and um yeah basically I don't know I know you you don't necessarily agree with this but you know from the perspective of standardization it really hurts things when basically it's all like a moving All good.

Tim Beiko: Okay. I think there's a yeah rough consensus in the chat that we should have a breakout on this um and maybe start with a call with just client teams and then potentially have a follow-up call where we kind of open it up to more people. Um and Justin says he's happy to heard the cats on this and try to find a time. So, let's maybe have a poll in the JSON RPC to find the best time and try to set up a call in the next week or two to go into into more details. Justin, are you okay running with this?

Justin Florentine: You got it.

Tim Beiko: Thank you. Anything else? Um, anything else to discuss on this before we wrap up? Okay. Yeah. So, thanks a lot for uh the write up and bringing this up. Uh and we'll follow up in the JSON RPC channel. Next up, um Kev had a comment around um finalizing requirements uh around uh hardware limits and potentially opening up the discussion about bandwidth. Kev, do you want to share a bit more here?

Kev Wedderburn: Yeah. Can you hear me? Hello? Yep. Um, yeah. So, yeah, we've been collecting feedback on the hardware requirements do stock for a while now and uh it seems like we can start calling for some sort of finalization on there. Uh, and I just wanted to alert everybody just in case people haven't looked at it. Um, people have like strong opinions that they want to still uh put across uh feel free to like put it in the Discord or on the HackMD document so that we can see. Um ideally we start finalization on the next um ACD. Uh so if you have time to look at it between then and now if you haven't already that'll be great.

Um should we make it Yeah, the question on making it into anformational EIP I would ask the EIP maintainers. Um but yeah, Tim, do you want to

Tim Beiko: Yeah. So I think the one advantage of something like this is then it's easy to reference and people are aware of it and it's kind of part of the you know set of things you reference. The one downside maybe is that uh once we have an EIP final we don't like to update it. So um you know to the extent that we expect these hardware requirements to change it means we would probably just have another informationational EIP say in two years you know we revisit this and things have changed. Um then we would

just create some new EIP that says it supersedes the previous one. Um, but yeah, I I do think having it live somewhere a bit more permanent than like a HackMD document or a ET research blog post uh would be would be good. Yeah, Nico.

Uh, yeah, we could keep the EIP under the living status and having like anformational one that is leaving. Yeah.

Tim Beiko: Yeah, that's true. We can do that as well. But

um so we don't have to open.

Tim Beiko: Yeah.

Yeah.

Kev Wedderburn: Yeah. Mhm. Yeah. I I have no strong opinions on sort of where it lives or so. Yeah, we can probably discuss that offline if like the EIP maintainers don't have any strong preference towards

Tim Beiko: Yeah, I think we can we can do this and that's kind of a good way to move this towards like a more finalized state. Um and you know at some point you can literally have it in last call as an EIP and then you mentioned bandwidth as well. So with the idea here to also have like a similar dock for bandwidth requirements and go through a similar process.

Kev Wedderburn: Um yeah so there is a dock for bandwidth. Uh I kind of wanted to push towards the TLDDR of it to see where the descent and opinions are first. um just because it's a bit more controversial. Um possibly we could just put that the bandwidth requirements inside of the same EIP. Um if it's not too controversial and we can sort of finalize it before the along with the hardware requirements. Um but I I have no strong opinions on whether we have one or two either.

And

Tim Beiko: what are the controversial uh do you have the link to uh the bandwidth ones?

What do you feel are the controversial uh bits?

Kev Wedderburn: Yeah, so I can uh I need to modify it a bit more, but uh I put it inside of the GitHub issue. Essentially, I want to start a discussion on going for 25 download, 25 upload. Uh given we have Fossil and you're using MEB boost and 50 download, 50 upload given we have Fossil, but you want to self build. any notice?

Potuz: I think I was one of the one that sent in on this document. Uh I think Ethereum today doesn't have a way of differentiating nodes from proposal proposal and validating nodes from just full nodes and and I think this this documents were based mostly for validators that have hardware that is over determined in general. uh I think we unless we have a way of differentiating the duties of validating nodes and nonvalidating nodes we should really aim to have hardware requirements for full nodes that are typically required to have less hardware and less bandwidth uh than validating nodes

Kev Wedderburn: right uh yes so I think I replied in the

GitHub uh discord with that since you're a full node you're not as latency sensitive. So you can have less requirements than a validating node or in particular someone who's trying to do a local block building and a testing. Uh and uh I think what I said was that we should ideally have a document for full nodes as well even if most of the stuff are sort of the same right now like storage would still be the same for example.

Uh your your hands are still up process did you want to say something?

Potuz: Oh, I apologize. No, that that was my only comment that I I think this is hard to differentiate. As you say, storage is the same. Most of the things everything is the same except CPU time and upload uh link when you're proposing. Everything else is essentially the same. Right.

Kev Wedderburn: Right. I I think it'd be good if when we make protocol upgrades, we sort of have this distinction, which is what I think two documents would uh sort of make very explicit. uh if we make a protocol upgrade that pushes up full nodes uh it should become quite

the point is

Potuz: that if you're if the

document that says for validating nodes you need to have um this bandwidth or this storage then you cannot have a document that says for full nodes you can have less storage. So since the bottleneck for storage is the full node I think we should focus on the full nodes first establish that number that is the smallest number and then then we can talk about validators that are anyways going to be overdetermined so I think it's it's we should have started with the full nodes before the validating nodes because the full nodes require less

Kev Wedderburn: right I mean I don't think it matters because we can say if you're a full node and you want to keep up with the chain

uh just as a validating node, then you'll need to have the minimum requirements just like a validator. But if you sort of want to be one slot behind, for example, then you can have uh less than uh let's say 25 megabits per second. Uh the storage I do agree the storage would still be the same over both. Uh but yeah, I don't think it matters which one we started with. Sure.

Potuz: I I I don't disagree with anything you're saying. It's just that the optics of this is you're going to present an EIP which is for requirements for validators. No one would disagree because validators I mean all of these requirements for validators are reasonable. But the problem is that then

later those requirements that are reasonable for validators might not be reasonable for full nodes and there's no way back from that because once you require something for validators for storage for example then full nodes will require the same. So I think it's more reasonable to start with full nodes that require less and then you can require more for validators and then becoming a noop.

Tim Beiko: So what I would propose here is we have a single document for hardware bandwidth that's anformational EIP and then you have two columns one that's for validators one best for phone or two sections whatever um I agree these requirements should be different and you

know they might evolve differently over time and I think even if you zoom way out into the future you know we have these ideas around a tester proposer separations or whatever so you could imagine having a third column it's like full node the tester node proposer node whatever. Um so I would move towards having like a canonical reference document. Um and then yeah try to just have different categories um as part of that and our starting ones are bandwidth hardware full node validator node. Does that make sense?

Kev Wedderburn: Yeah, that makes sense. Uh, I would say it's probably easier to have uh, well, maybe I need to think about it, but it seems easier to have separate documents, but then have one EIP that sort of merges them together.

Tim Beiko: Oh, sure. Yeah. Yeah. Like we can we can do the discussion like independently, but I think like once we have some consensus on these things, they should all come together in like a single EIP Okay. Yeah. Yeah.

Kev Wedderburn: Um yeah, that makes sense. I guess uh does anyone have a dissenting opinion on the bandwidth recommendations? Um I guess the the rationale behind it is that once we have fossil

um local block building is not as important for censorship resistance. Um so if you do want to go down the local block building route, you will need to have sort of sufficient uh bandwidth for it. Um that's true. Fossil doesn't currently include blobs.

Tim Beiko: Is there uh I I forget if we created a channel to discuss this in the R&D discord or where if not where were we discussing this?

Kev Wedderburn: Um most we had a I think the general ACD channel initially.

Tim Beiko: Okay, got it. Uh does it make sense to also have a separate channel to discuss this because I expect we'll come back to the topic uh over time.

Kev Wedderburn: Yeah, I think it'd be useful.

Um yeah, just a bit surprised no one has any dissenting.

Maybe once we post

Tim Beiko: the doc in a channel desenters will come out. So, okay, perfect. So, let's do this. Um I'll create the channel after the call and then Kev, you can uh draft the docs based on Yeah. Okay. your current specs and uh we can take a turn there.

Kev Wedderburn: All right. Thanks.

Tim Beiko: Anything else on the node requirements? Okay. If not, we have uh one last quick announcement uh around EIP uh editing. I believe there's an EIP editor workshop

tomorrow. Um Sam, do you want to give context on it? Sure.

How's my audio? It's good. Okay, good. I never know with Zoom. Uh yeah, so we're doing a EIP editing um like workshop tomorrow. It's for anybody who's interested in becoming an EIP editor or an EIP reviewer. Um one comes with governance responsibilities and the other one doesn't. Um just pulling up the time here, but my computer seems to have died a little bit. Um, yeah. So, that'll be tomorrow at 1,600 UTC. Um, we're going to go through how an EIP like goes through the the

workflow. We're going to talk about the types and categories of EIPs and then I'm going to do a few uh live EIP editing uh so people can ask questions and uh just kind of see how that works. Um, and then we'll have some questions if anybody wants to to ask anything. So yeah, coming out tomorrow 4 uh p.m. UTC. Um looking forward to seeing you all

Tim Beiko: Thank you. Um and yeah, I'll add this is something where um current EIP editors have a lot on uh their plates. It would be amazing if we could eventually move to a world where like this is spread out much more evenly. Um my dream is something like every client team ends up

with an EIP editor um and others obviously can participate as well. going from a spot where we only have like two or three people actively doing this to where we have five to 10 um I think would help improve one the just basic operations of the EIP process and then to you know give us more bandwidth to potentially um evolve it in a way that's uh yeah more useful to everyone. Um, so if you've been curious about EIP or intimidated by them, um, please join tomorrow's workshop. I think, um, yeah, it'll be a good starting point to bring in more people.

And there was a comment in the chat about whether it'll be recorded. Yes, it will. Any other questions, comments? Okay. Um, anything else people wanted to bring up before we wrap up today? Okay. If not, um, then yes, there are a couple PRs to be open and reviewed before Monday's call. I'll put a summary in the Discord, but please, uh, keep an eye out for those. And I will see everyone next week. Thanks everybody.

Thank you.

Bye. Bye. Bye. Bye everyone. Thank you. [Music] Heat. Heat. What's up?

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