All Core Devs - Testing #92

Transcript

Justin Traglia: Good morning, Spencer.

Spencer Taylor-Brown: Hey, Justin. I'm good, how are you?

Justin Traglia: I'm doing fine. My day's just starting. And, GitHub isn't working so well for me. Are you having issues by any chance?

Spencer Taylor-Brown: Yeah, there's, there's definitely issues. On their status page, they're saying there's degraded performance.

Justin Traglia: This seems to be a recurring issue.

Spencer Taylor-Brown: To be a recurring issue. Yeah. I think, it's… for the agenda, I think, Refreshing sometimes gets pages for me to work, but it's,

Justin Traglia: Yeah.

Spencer Taylor-Brown: Yeah, it's not ideal.

Justin Traglia: Luckily, I have a…

Spencer Taylor-Brown: I agree.

Justin Traglia: past. Yeah.

Spencer Taylor-Brown: cash.

Justin Traglia: Structure of the page.

Spencer Taylor-Brown: Picture of the page.

Justin Traglia: Also, I hear myself, so I hear my speakers, I think.

Spencer Taylor-Brown: from your speakers. Oh, yeah, sorry, our headphones on, my bad.

Justin Traglia: No worries. Good morning.

Jochem Brouwer: DM, DM.

Justin Traglia: Good morning. Just a minute or two, and then we'll get started.

Good morning, everyone. Just one more minute, and then we'll get started. Alright, good morning, everyone. Welcome to ACDT92.

Yeah, GitHub is also having issues for me as well. I've shared the agenda in the chat, but I have a cached version locally, which… I can use. Let's get started by discussing Glamsterdam DevNet 8. Is there anyone here that can give a status update on things?

Stefan Starflinger: Yeah, I can give a short update. So, we have a blog post that's out now. for, Datnetics. We can share the links in the chat. And also the tweet, if you want to share that. So we will probably be sunsetting DevNet 7, when DevNet 8, does the transition to Gloas. And, I think one of the bigger points, is the comment from Nimbus. I don't think he will be able to make it to this call. But he said that from Luca Sani's, PR, and if we get them quickly enough, these ZR clients, it should be fine. Because I think it was consensus-breaking. But otherwise, 7.8 is looking good, and,

We can get… get ready for a Gloas there.

Justin Traglia: Thanks, and the upgrade will happen in, like, 2 days, 17 hours, correct?

Stefan Starflinger: Yeah.

Justin Traglia: Okay. Do we have, like, a list of things that we're gonna test before or at the fork, and are we planning on making, like, a bunch of, deposits so that builders can Like, onboard, for example.

Stefan Starflinger: Yes, it's best to have a builder, deposit, a few epochs before the epoch transition. And there are some views, that, where you can see your deposits. So we have, kind of, here. Builder deposits view, as well. And you can kind of see when your builder is getting indexed. I think one of the main things also to test is the builder software. Different clients have builders that they want to get tested, it would be good to kind of let us know. And in general, I think… Want to test the fallback clients? As well, I think I have a list in the notes as well, exactly what we want to test. We won't be testing the SSZ side, we will do that in the T.NETs, later.

I think Barnabas didn't end up adding The exited Validator, so Validator set is a little bit smaller, than last time. I'm just gonna share the notes here. And we have a list of testing focuses there as well.

Justin Traglia: Awesome, thank you. I'll go over these after the call. Is there anything else that we would like to discuss regarding DevNet 8? From anyone?

Ahmad Wilson: So, not directly related to, DevNet 8, but, I added a comment just regarding the, contributor program, so that you can hand off. Previously usedatsu, right? But I think, it's been superseded by computer. It's just, you know, more general questions regarding registration. I post in Discord in the Zoom, the Zoom channel and, I believe it's the V, who started, thread, but yeah, just kind of checking in terms of, like, what's the best way to… to go about just getting, re… re-enrolled. I think I registered with Batsu a while back, but, I'm pretty sure all of that is, like, either obsolete or has been deprecated or so. So, yeah, just curious what, thoughts are regarding that.

Justin Traglia: Yeah, is there someone here from ETH Panda Opps that could potentially answer your question?

Parithosh Jayanthi: E. A few of us were, on vacation the last week or week and a half. I think Andrew or… Sam would look at your request in a bit.

Ahmad Wilson: Cool, sounds good, thanks.

Justin Traglia: Alright, anything else regarding DevNet 8? We don't have anything in the agenda for combined discussions between the CL and the EL. So I guess we should jump into the… breakout calls. Or is there anything that we'd like to discuss? Together I guess not. Okay, for the EL, I've just shared the Zoom link. Please join when you can.

This is a very quick call for the combined one, so thank you, everyone, and goodbye. the EL can continue to discuss. I believe there's one agenda item. So…

Jochem Brouwer: Thanks, Justin. Alright, let's wait a few seconds before we move to the point. It is about EIP761.0, so let me know RPCI that… EIP… Yes, so… I want to discuss this. EIP. It is, sorry, it's SFI for Glamsterdam. But we had some recent discussions on our core Devs. There is this thread, which I will also share. Let me see… How do I share it? That's… that's This… Yeah, we had some discussions on this, and I think that Gary is on the call, and maybe Dragon is also on the call, but could you maybe share your opinions or thoughts on this EIP again?

Gary: Yeah. Frog, I can go first. So… Actually, after thinking about it for a while, I think I have convinced myself that probably it's not that necessary to include this EIP. So the core idea of this EIP is, We have very… we have… we have, like, 28 account, very special account. which are… eligible for the contract deployment, but with, like, non-empty storage. But the only way to check this edge case is You need to… You need to have the hash collection, and someone can find a contract address which conlitz one of these 20 accounts. So… The original idea of this EIP is, whenever we try to make the contract deployment, we always check if the… we always check if the storage is empty or not.

But if it's feasible with this hash collection, it means the attacker can also derive a private key corresponding to any Ethereum address. Because they rely on the same security model, like the 100… 60Hz security. it will be a larger issue for the Ethereum. Like, the whole Ethereum security rely on this assumption. And if it's broken, it makes no sense to only protect the contract deployment. So in this regard, I think… I am fine, to remove CSE from this, from the Amsterdam folk.

Jochem Brouwer: Yeah, cool. Thanks, Kerry. I also want to note that I… Start to agree with this. Let's see, is dragon also in this call? Maybe dragon can also… No.

Dragan Rakita: Yeah, I'm here.

Jochem Brouwer: Oh, sorry. Yeah, please.

Dragan Rakita: To be honest, I… I… Every time some auditor or some researcher or somebody points it to me that we are skipping some of the tests. I got, basically, I read something in All Core Devs. That was the reason why they started. Yeah, I think, In Hegota, we should include that EIP that bumps the NOSS for those accounts, and just finish with this. I don't care a lot if this is included in the graph set or not. If the… 7610 is included, collapsed or not. I care for those tests to be removed, and to not have this edge case that, from time to time, like. two, three times a year, I get, like, notification that we are not passing tests, and I really don't like that.

That's my, like, take on all of this.

Jochem Brouwer: Yeah, thanks a lot. Yeah, I know that this is very annoying. Okay, so… Yeah, I also, because I'm also convinced that, because of this testing surface, because EIP 7610, like, the testing surface, or the specification. EXPIC says that you have to check the storage route, that, you need an empty storage root. In order to deploy a contract here. So this also implies that you have this check in your client, which could, of course, be a very expensive check if you go to the disk and check the storage route. The other alternative is to do this hard-coded. It also works, but then you have a problem with the tests. Because EIP 7610 specifies that you have to check the Emptiness of the storage.

So, yeah, that would mean either changing this EIP or, or indeed skipping the tests. So what I would actually propose that's also in line with Gary, and that would also solve Dragon's problem with the, with skipping these tests, is that we, either remove this EIP, or that dragan skips this, this test, and then it includes EIP 8253, For Hegota. I would personally lean somewhat more to actually removing this EIP from Glamsterdam. I also PFITIS, I believe. So yeah, I don't know. Does anyone else have any thoughts on this?

Gary: Yeah, so I also want to mention that, from the testing's perspective for the EIP-8253, we probably will have the similar issues for the testing, because we are targeting Sir… 20 accounts on the Ethereum net only, and, so for the testing, we should also only focus on these 20 accounts. And with the current testing… with the current, test case for the 7610, it's, like, a very general, scenario, not only, like, specific… specific for these 20 accounts, so I guess we will have a very similar issue for the… for testing. Okay, it's nothing I want to say.

Jochem Brouwer: Yeah, to add on this, EIP 8253 does not have this problem with the tests, because it explicitly states that it only applies to these 28 accounts, and not in the general sense. So, if you have another non-mainer chain, then this change would specify these accounts themselves. Well, EIP7610 is the more general sense, so it would also target other chains. Yes, Mario?

Mario Vega: So, my question would be, what is, Red's behavior on this test when you run them? Do you deploy the contract, or what happens?

Dragan Rakita: We ignored them. We don't even run them. Because this requires… we don't check the storage route, so it depends on It would behave differently in Reth, and it would behave differently in RED, because it depends on how you set up your, basically, framework of the testing. I don't know exactly how the rat is going to behave, to be honest. But in this point of time, in the next 10 years, it doesn't matter. This cannot be triggered, basically.

Mario Vega: So basically, just treat it as undefined behavior and not even producing a test, right? That's your suggestion.

Dragan Rakita: True. Yeah.

Jochem Brouwer: Yeah, so what this will do is, and with this, I mean removing EIP 7610 from Glamsterdam, what this will do is remove these tests from the, EVM specs tests. Since that Reth can now also pass the canonical test, and also all the other clients which skip these, because I think that Geth currently also skips these tests because of these hard-coded addresses. And… I wanted to note another point, yeah. So, if we ship EIP 8253, into Hegota, then this unspecified behavior is not, is really not possible anymore, and by that I mean that these accounts are then not part of mainnet anymore, so this cannot, even if we would find, like, a hash collision, would not be able to be triggered on mainnet simply because these accounts do not exist.

But again, like, I am, I… like, this was, for me, like, a very long journey, and I… I feel like I should have landed maybe on this completion, like, much earlier, but I somehow got into this tunnel vision that somehow hash collisions are easy to do, or something, that we should specify this behavior, just for the sake of it. Because, if you think about it, I wanted to also add that, that in Solidity, if you have, like, a mapping type, so let's say, for instance, an address to an UINT, so, like, a balance mapping, for instance, in Solidity, what happens is you actually hash your adverse. With, a storage, location. So it would theoretically also mean that if in Solidity you would find an account which has a collision with another account, you could basically read or target another account's balances, which is, of course, not possible.

Because this would, well, it, like, again, like, as Gary also mentioned, and Dragon has also mentioned multiple times into, into these discussions, that, if a hash collision, is produced, then we have, like, a much bigger problem than, well, these, EIP7610 accounts. Okay, so what I will do is, I will… raised this again at, I guess, ACDE in one and a half weeks, by the decision of ACDT that we will remove this EIP from Glamsterdam. And we've also, we have, like, a very clear, clearly written message that currently there are… well, there are two, clients which are already skipping these tests for EIP7610. which are Geth and Reth, and maybe there are more clients, and that this, removal is not a, well, it does not read, like, not a spec change.

But, it is not a change in any behavior. Any, any comments on this?

Gary: Yeah, sounds good to me.

Jochem Brouwer: Alright, okay, then I want to, to thank Dragon and Kerry for these discussions. Also, especially Dragon. We had these discussions multiple times, and I think I should apologize for taking so long to get convinced about this point.

Dragan Rakita: to apologize for, like, bringing this up, this, like, nuisance, small thing, it… basically, it's something that… That is more like the pain and does matter a lot. Sorry, everybody.

Jochem Brouwer: It's okay, it's okay, we are all in this shit together, right, so it's fine. Alright, yeah, for Spencer's topic. I… yeah, I will just place it at ACDC. Yeah, let me do that. Because we can just point back to this conversation, As a reference, yeah, that sounds good. Okay, I think this is a nice result, because that means that clients can now pass these canonical tests after we remove this. And… Yeah, this all sounds good. I also believe that this was the only point today on… the EL breakout? Yeah, let me ask, is there anyone else who has an EL breakout topic? Alright, if not, then this was a very short HTT call. I will call down from 5, and then we say goodbye. 5.

4. Tree. 2. Well… Yes, goodbye, everyone, and thanks, sir. Thanks, everyone.

Marius van der Wijden: Go ahead, thank you, Johan.

Mario Vega: Thank you so much. Bye.

Nikos: So you…

Jochem Brouwer: Bye-bye.

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