Block-Level Access Lists Breakout #4

Transcript

Toni Wahrstätter: Okay, how are we doing with the streaming link?

Pooja Ranjan: I just shared in the chat, it seems to be working, but I… can someone else confirm if they can see the pre-streaming?

Jochem Brouwer: Yep, I can see it.

Pooja Ranjan: Awesome. I'm gonna move over the stream now.

Toni Wahrstätter: Perfect, thank you very much. Welcome, everyone! Today, we have the fourth EAP7928 breakout call. It's October the 8th. And we have a rather lightweight agenda today. So, first, we wanted to talk about What we couldn't finish, or what we couldn't, take a decision on, two weeks ago, namely the topic of block-level access list hash versus block-level access list root. Then… I'm hoping we can get some updates from clients about progress, about, yeah, testing, and how everything is going. And finally, we can talk about, Yeah, definite, and how we get to a first block access list definite as soon as possible. Great, let's start into the discussion with BlockHub Access List Hash versus BlockHub Access List Route, and I would be curious, if clients have, like, changed their opinion or updated their opinion last week. The default was, more on the

keep it as is site, so that we keep the block lab access list as it is, and consider moving to a block lab access list route in the future, when partial stateless nodes become a more important thing. But, yeah, the pre-confirmation team shared their work with everyone here, so I'm curious what clients think about this topic. If there is no update, then I would just assume that… We just stick with the block lab access list hash. And don't change it at this point.

Great. Then let's keep it as is. Before we get into, client updates, I wanted to bring up this point by March Hill in the Discord. Namely, he wanted to… open the discussion around precompiles. We already discussed, how we treat precompiles. A few calls ago. But I would still want to give Marshall the opportunity. To voice this opinion here.

Marc Harvey-Hill: Yeah, I just wanted to quickly bring this up. So yeah, most people were against it last time, but, I just kind of had a look into the code to see sort of what it'd be like to implement this way. And it just seems cleaner to me to not include the precompiles if they're… they're just called, or if you take, like, the code size. or copy code, then in all these cases, or certainly never mind code, like, this doesn't access the state at all. So whereas for all of the other block accessor stuff, like, you can quite neatly do it by just… sort of, you know, noting the change whenever you kind of go into the state. This goes down, like, a different code path, so… I mean, it's doable, but it just seems a bit more, like.

ugly to me. But yeah, I'm not sure if anyone else agrees with that, but I'm happy to go either way, really.

Toni Wahrstätter: Yeah, I can definitely see the rational behind this. Essentially. we would never have a precompile included in the block live access list with empty changes, where nothing changes. Things like balance changes are still possible, and that would then essentially be the only way a precompile could ever be included in the Block Live Access List, if I… if I'm not wrong here. And we would then just remove all pre-compiled addresses from the block of access list if there are no changes, Related to it. So this would be, just a description to look from it, from a different angle.

Jared Wasinger: I feel like, And I need to look into this, but I feel like if the… If, the target account of this operation, of whatever one of these operations is. A precompile, and these fall under the… EIP2929, cold… account, like, load, cost model, if that makes sense. I feel like it might make sense to… to do what Mark is saying here. Yeah.

Toni Wahrstätter: Yeah, just… just to add what I just said, because I think, Rokita, correct? Dragon corrected me correctly there, because… Also, if we call, like, balance on a precompile, we still want the… we still want, the balance… we still want the precompile in the blocker access list, right? So, essentially, we are now talking about differentiating between certain opcodes when it comes to precompiles.

Jared Wasinger: Yeah, we definitely shouldn't do that.

Dragan Rakita: Yeah. On one hand, I understand that the compiler should be formed, and we should have those accounts available, but on the hand, I would like to be… for block level X, to be, like. covering everything. If we touch account, it should be inside block access list.

Marc Harvey-Hill: Yeah, I mean, the point that I'm making here is, like, in these cases, you're not actually, like. touching the state or any accounts. So let's say, like, in Nevermind, it goes down, like, a completely different, code path. And it's nothing that you would… Need when executing, either. But that wouldn't be the case for, like, balance or, you know, anything else except for those specific ones where it doesn't touch the state.

Dragan Rakita: Yeah, I think… External cord size, external cord is… those up codes are not that great, but they are needed. So yeah, I would stick to… Having, like. Let's include everything, just to not make… Different rules around it. But, yeah.

Toni Wahrstätter: I'm… just echoing what… Karim is also saying in the chat, agreeing with Jagan, for the sake of, yeah, lower complexity.

Marc Harvey-Hill: Yeah, I mean, I'm happy to go with that. It's just, like, as it depends on the codebase. For us, it's like… Slightly more complexity to actually add them, but, like, still negligible, so it's just… Whatever works best for everyone, I guess.

Toni Wahrstätter: Awesome, then just to… to summarize that, regarding precompiles, we will include the precompiles if they are called in any upcode. No matter what, which means that we will have precompiles in the block lab access list with completely empty. changes. For example, if you call the balance opcode on a precompile. Great. Perfect. Is there anything else that you wanted to bring up… to bring up regarding this, point, or regarding the changes you, proposed for the EOP?

Marc Harvey-Hill: Yeah, I can quickly mention, so there's this other change that I suggested, around an edge case with balance changes. So, specifically in the case that we have, a transaction, and an account's balance changes in that transaction, but goes back to what it was before the transaction. I think in this case, we shouldn't record in the, block-level access list. And to me, this just seems a bit more consistent with how we handle zero-value transfers and also self-destruct. Because if we don't do it this way, like, we have these other special cases where if we… if we kind of change it, then it all just falls under this rule, which seems kind of nice.

Toni Wahrstätter: Yeah, yeah, I totally agree with this, and this is actually how it should have been handled from the beginning. So, in the specs, it was always correct, but you are right that in the EAP, it was kind of poorly formulated, where it was not 100% clear. So… I would assume the clients already handled that correctly, and we also had tests for that. So what I would propose is that we just, merge your pull requester, and maybe we can… slightly changed the wording there. I, proposed some, some small changes there. But yeah, curious, what clients are actually doing in such cases for transactions where the initial balance is the same as the post balance in the specs, those were already excluded.

Jared Wasinger: You're in Geth, we exclude them.

Marc Harvey-Hill: It would also be good to cover this in the test, because I think… at the moment. Nethermine doesn't actually do it this way, but I can't see any test that it's failing, so I think… We should, add something for that.

Toni Wahrstätter: Yeah, let me ask Rahul and Felipe, and I see they're both on the call, maybe some one of you can give us an update, would also work async if you… Don't want to put you on the spot here.

raxhvl: I'll review that and update on… update in the channel.

Toni Wahrstätter: Okay, great. Yeah, would be great if we… if we get a test case for that, just to make sure that… We're handling that correctly.

Dragan Rakita: Sorry, I'm… I didn't follow at the beginning. This is about setting, for example, Balance the… Zero balance to some target. This is the kid.

Toni Wahrstätter: This is, for example, a zero-value transfer. But it's also the case if you have a transaction. and you send one EV somewhere else. Or you call a contract, the contract sends one ETH out, and then receives one ETH in the same transaction.

Dragan Rakita: Okay, in this case.

Toni Wahrstätter: There was a balance change, but they zero each other out, and that's why we don't include them.

Dragan Rakita: Okay, that makes sense. It's not included in the write set, but it's included as the read. Exactly, yeah. Yeah, okay, cool, that makes sense.

Toni Wahrstätter: Awesome. Yeah, I see Kareem also confirms that… For peace, it's also read perfect. Yeah, we have many of those, cases also around, reverted transactions, 7702, What else was there? System contract stuff, if I remember correctly, where we sometimes have to convert changes to reads? At least in the specs. But yeah, for most of those edge cases, we have tests already, and this is one that we will definitely add. Great. Is there any other open topic that we should discuss before we get to client updates?

Felipe Selmo: I wanted to just mention the 7702 changes in the spec. Tony, I think you have a PR up for my branch that's open in the spec side. And I made a couple small changes there for some new tests that I added, if you could take a look. And we can chat async.

Toni Wahrstätter: Perfect, yeah, I will take a look. Thank you very much.

Felipe Selmo: Awesome, yeah.

Toni Wahrstätter: Yeah, Katya?

Katya Riazantseva: Hi everyone, I'm Katya, I'm working on metric specs, so I also opened an issue regarding biometric specs, so… I would like to hear from you later in the… channel, so your ideas, maybe, so I put some metrics, which can be standardized. And if some of the clients are ready to build them, so we can have them, the dashboards and Cortosis, and for dev notes as well, so please let me know. I will share it also in the Discord channel. Thank you.

Toni Wahrstätter: Awesome, thank you very much. Sounds good. Great, is there any other topic? Someone wants to race. If not, we can also start, going through the clients and… Checking client updates. And then, yeah, we can already start discussing when we want to do a first definet, maybe. Maybe we start with you, Charit?

Jared Wasinger: Yeah, sure. Not too much to report on the get side, In the sense that it's relevant to people outside the Geth team. Basically, the last, week and a half or two have been consumed by refactoring our, Implementation to be more clean and to get it into a mergeable state. I've been working a lot on making sure that this new refactored implementation is going to work in a local DevNets setup. so yeah, that's it.

Toni Wahrstätter: Awesome. When would you say, would you be ready for, first FDAT?

Jared Wasinger: soon? It's at the point where, I mean, it… I think it's very close, but it's just a matter of ironing out, these issues that pop up when I try to run it, so… I mean… maybe a day or two. It's kind of hard to give a firm answer. I doubt it would… I doubt it would take A week or more, though.

Toni Wahrstätter: Great, thanks for the update. Let's continue on with Netherland.

Marc Harvey-Hill: I, so… I fixed some issue that was, causing, Nethermine to… or the BALS… NetherMind BALS implementation to not run in the Hive tests. So now it's passing most of the tests on the tracker. And there's a few that are still failing around a few edge cases, so I'm just working through those and fixing them.

Toni Wahrstätter: Thanks a lot. Let's continue on with… Ruh.

Ishika: So we ran the new sets of the tests, and had some issues with how, the balances were stored in case of a non-change test, and we fixed it, and we also ran some test concerning IP2930, and yeah, we now have the BAL DevNet 0 branch in red, and the new tests that are added, didn't get a chance to look into it. So… We'll look into it soon, and also have a bit of refactoring on the part of the code we have implemented so far.

Toni Wahrstätter: Awesome, thanks. This also sounds, like, very close to being able to participate in the first FNet, right? Let's continue on with Aragon.

Mark Holt: Yeah, so… we are… Just finalizing our implementation, I'm expecting to get a branch that we can merge probably on Monday next week. And then… I guess by the end of the week, we'd aim to get the hive tests all passing, now… I think the way that we've done the implementation, we have basically a parallel engine running that we've been kind of merging over the last week or so. We now need to put the bowel stuff on top of it. Having had a look at the, It's the… the Discord chat, although I haven't particularly participated in it. I think most of the issues that we're that people are raising, we've also had and kind of fixed in our implementation, so I would hope

will be in… A good position by the end of next week. So I think probably the week after, we would be ready to join a DevNet.

Toni Wahrstätter: Great, thank you very much. and peso.

Karim Taam: So, so we are passing all of the bul tests, block access tests. We… we did some tests with GET on a local devnet, so the block built by Bezo are accepted by GET. And to get… built by… there's a blog built by Ketta, accepted by Bizzou, so it seems that for the moment it's working. So we created a branch, for the new DevNet. Just, it seems that we have some issue with the Hive test, but I don't think it's related to block access list, we just have to understand what is the problem. But, I think Bezu is really, yes, for the… for the DevNet.

Toni Wahrstätter: Amazing. Yeah, we're getting really close to a first definite hit, it seems like. Yeah, great work, everyone. Is there anything else we should discuss today? Great. I will then double-check with PandaOps regarding First DevNet, and… Nothing needed for that, but looks like we might. Get to a first definite next week, sometime. Amazing. If there is nothing else, then I would say we can… And the call a little earlier today. Awesome. Then, thanks everyone, and see you at the next breakout call in two weeks.

Marc Harvey-Hill: By the way.

Felipe Selmo: Thanks, bye.

Ishika: Bye.

Dragan Rakita: What?

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