Block-Level Access Lists Breakout #5

Transcript

Toni Wahrstätter: Hello, everyone. Let's wait. One or two more minutes for people to join.

Perfect, I think we're ready to go.

Pooja Ranjan: We are live.

Toni Wahrstätter: Great, thank you. Welcome, everyone! Today we have the fifth EIP7928 breakout call. It's the 22nd October 2025. And we have 3 agenda items today. First of all, we wanted to talk about Coinbase handling. This came up in Discord, and also, there were some suggestions that we change how we view the Coinbase address at the moment. Then second, as usual, we did some, testing and specs updates. There were some updates that we can discuss today. And finally, client updates. So let's directly start into the… start with the first agenda item. which is the Coinbase handling in the BlockClam Exorcist. To give you a quick recap how it works right now, so the Coinbase address is only included in the Block Live access list.

If it actually changes. This means, if there is any transaction, that… has a positive tip, then the Coinbase will see a balance change. The same applies, if the Coinbase address receives a withdrawal. So in this case, even blocks without any transactions can still have a block lab access list with the Coinbase address included. In case the companies receive the withdrawal. And… For any other, so if there is a block with where the Coinbase address receives no withdrawal, and there is no transaction, then the Coinbase address is not included at all. So this is what is spec'd right now, and also the state of the EIP. And I'm happy to discuss if we should change that.

Or, if we keep it as is.

Dragan Rakita: Did you maybe mention the use case when there is transaction, but the fee reward is zero? what happened for codebase in that case?

Toni Wahrstätter: In this case, it would also not be included. But this is a good example, yeah. So, if the fee reward is zero, then we would not see a call to the Coinbase address, and the Coinbase address would not be included. So, a zero… Value reward is, in this case, different than a zero value call. Because in a zero-value call. The address you're calling would still be included, at least as a read, so with all empty changes. But for the reward, it would not be included at all.

Dragan Rakita: This kinda clashes with the state clear IP. Where even we have some tests in East that test this use case. When the Coinbase is basically empty but existing, and you reward it at the end. Expectation there is that, the Coinbase is going to be touched, at the end, removed from the… from the state.

Toni Wahrstätter: I see the conveys is going to be touched, and is it always empty in this case, the conveys? Is it only touched if it's empty? Or is it always touched in that scenario?

Dragan Rakita: It's always touched, but only action that needs to be… needs to happen is if it is empty. That means it needs to be removed. From the state.

Jared Wasinger: Yeah, so previously, I think I was pro… I was pro, to not include the… Coinbase as a read if the balance doesn't change, like, in the case of the empty block or the zero fee payment, but I… think… now that the point about… I think it's… I forget what the state straight clearing EIP… so the point about it being touched as part of the… I think it might be EIP161, I can't quite… remember right now, but I think that… perhaps that's actually, like, I mean, a fairly decent argument to actually just include the Coinbase, and as… and furthermore, just include anything that would be touched as part of EIP161 as a read.

Dragan Rakita: I would do something in the middle. If the empty fee is transferred to Coinbase, hey, let's include Coinbase, it is the same behavior as you're transferring the zero value to any other account. But… I've… if… If there is no trace section. then I would not include Coinbase. But that second part is not… I'm not going to die on that, to be honest. We can, yeah… we can always add some edge case where we always add the Coinbase.

Toni Wahrstätter: Yeah, to me… to me, this… this feels like the cleanest solution to this, because now I can definitely see the argument for including the Coinbase in this exact edge case that you described with this, three-digit ERP that we're talking about. It also, just to echo what Rahu is saying there in the chat, it will also, allow us to treat a zero-value call exactly the same as a zero-value balance. So, essentially, we would just have a rule in the ERP that the Coinbase address is always included, at least as a read, if there is no other changes happening to the Coinbase account. And then we don't have to think about any of those edge cases. I'm curious what other clients think about this. This is definitely a small change to the specs, and also some changes to the AOP required.

I guess we will also have to, change the tests we have on that topic. All small changes, I'm happy to do so, but let's see what other clients think about it.

Marc Harvey-Hill: I think it makes sense to include it. It just seems a bit more consistent, and we don't have this, specific edge case.

Toni Wahrstätter: just, just for Lucas, Lucas to quickly, summarize the discussions about the Coinbase address, how it is included in the block lab access list. We are now landing… at including the Coinbase address, no matter what. So the Coinbase address will always be in the block lab access list, and the least it would be in there with empty changes. So there can be balance changes, a Coinbase address can also have nonce changes or code changes, but it will always be in there at least as a read, as a state access. Because previously, there was the situation that A block with no transactions? The question popped up, should the Coinbase address be included or not, and what happens if the block reward is zero versus non-zero? So the easiest solution seems like we

have a new edge case for the Coinbase, which says the Coinbase address is always included in the block lab access list, no matter what.

raxhvl: I'm always including Coinbase as One problem, because… It introduces redundancy. We could always get the Coinbase from the block anyways.

Toni Wahrstätter: Right, yeah, it's a bit of, duplicated information there. But I think it's fine, because it's only, like, a very rare edge case. This edge case only occurs if we have a block where the Coinbase address wouldn't be included anyway. And usually, blocks have transactions with positive tips. So, I think we can live with it. Great, then just to summarize the to-dos, I will update the specs and the EAP. Rahul, will you update the test cases?

raxhvl: Yep.

Toni Wahrstätter: Perfect Is there… maybe asking Felipe, is there anything else, That you might be thinking of that we have to change here? I guess not, right?

Felipe Selmo: No, I think the… Yeah, the yield side, the spec side needs to change, But yeah, I'm good with this change. Makes sense to me.

Toni Wahrstätter: Okay, perfect. Great, then let's move forward with that. Yeah, please go ahead.

Dragan Rakita: Just… just to confirm, so always include it, even if there is no transactions.

Toni Wahrstätter: Right, yeah.

Dragan Rakita: Can have a very, probably in the specs, we will…

Toni Wahrstätter: it will even simplify the specs a bit, because we will just have one line at the very beginning of the block, where we put the Coinbase address in there.

Marc Harvey-Hill: I mean, an alternative would be… to just have it only if there was, I guess, just one… Transaction with… with a… with a zero balance change. I don't know, because always including it seems like almost adding another Edge case, whereas if we just have it so that whenever there's a zero transfer, then that's just, you know, always handled the same. That seems the simplest to me, but I mean, it's a small difference.

Dragan Rakita: Same hero. Aware of what Mark said. It simpler… if included always, then we have some additional condition that we need to add. If included, only if there is transaction, even if… even if the fee… Value is 0, then we just use what's salted there. It's small change, it doesn't matter, we can always have, like, additional condition, but just wanted to point that up.

Toni Wahrstätter: I'm fine with this one, too. So then the edge case would be we include the Coinbase address. Even if the reward is zero.

Dragan Rakita: Yep.

Toni Wahrstätter: Okay, yeah, curious to hear what others think about this. I'm fine with that one, too.

raxhvl: I think it's cleaner. This way, this is like any other balance change for an account.

Jared Wasinger: Yeah, so as far as implementing it in Geth, I think regardless of whether it's always include or, include as long as there's a, a transaction in the block that, even if it pays zero fees, it's still a bit of a special case, and I think what's important from my perspective is that we just settle, so, I don't have a strong opinion either way.

Toni Wahrstätter: Just to confirm, the… if there is no transaction in a block, the Coinbase will be included, and if there is a transaction in a block with a zero tip, the Coinbase will also be included, right?

Jared Wasinger: I think that was the always include option, but my understanding of what maybe I misheard, but I think what Mark and Dragon just said was to… If that there is an empty block to not include the Coinbase. And if there is a block containing one or more transactions, even if they pay zero fees. to include the Coinbase, that's the other option.

Dragan Rakita: Yeah, that's one.

Toni Wahrstätter: Okay, interesting, because I was thinking, like, okay, isn't it, like, from the Coinbase perspective, the same if I receive zero reward through a block with no transactions versus zero reward through a block with one transaction paying zero tips?

Jared Wasinger: Is there, is there some…

Toni Wahrstätter: Good, dude.

Jared Wasinger: The distinction that Dragon pointed out earlier is that from the EIP for the state clearing, the… in the case where there is the zero fee transaction, the Coinbase is actually touched. And in the… because we no longer pay the block rewards at… the… the… in the other case, the Coinbase would not be touched in an empty block without Any transactions?

Toni Wahrstätter: Okay, gotcha.

Jared Wasinger: I don't know, just maybe…

Toni Wahrstätter: I think you got it, yeah.

Jared Wasinger: Someone else can expand on it for me.

Toni Wahrstätter: No, this is interesting, because it's then actually the tip paying that touches the Coinbase and not the reward, right? Yeah, makes sense, because there is no, block reward. So, okay, because I'm just thinking in the specs, we might have already We might do that already correctly, but I would have to double-check, because Yeah. But… Are we then fine with, Agreeing on that solution that we… So, just to summarize, the Coinbase would then be included in case there is a transaction. Even though the transaction has a zero tip. So if the transaction has a positive tip, the transaction… the Coinbase is included anyway, because it has a balance change. But if the transaction has a zero tip.

then the Coinbase would at least be included as a state access, as a read. Great. And the only situation where the Coinbase address would not be included Would then be a block with no transactions, is that correct, too? Okay, yeah. Rahul is also confirming me in the chat, so the Coinbase address would not be included in the block access list in case if there is no transactions, and… No system operations touching the Coinbase, which could happen with a withdrawal. Perfect. Yeah, then let's update the EAP, the specs and the tests, and… Make sure we have it ready for the next, release.

Awesome. Then we can… is there… before we move on to the second point, is there anything else people want to discuss regarding the Coinbase address tracking?

Karim Taam: Monique, could you just summarize again, just to be sure I follow everything?

Toni Wahrstätter: Yeah, so the Coinbase, will be included if it sees a balance change, for example. So if there is any change in the block. But regarding the Coinbase, then it's included no matter what, so there's no edge case around that. For example, if the Coinbase receives a tip from a transaction, then it's included with the balance change. The interesting case is what happens if the block is empty, so there is no transaction in the block. In this case, the Coinbase is… Not touched. The Coinbase would also not be included. So, zero transactions. could mean the Coinbase is not included in the bulk. It could also mean the Coinbase is still included in the block of access list, but only if it receives a withdrawal.

And then… Another second interesting case was, what if there is a transaction in the block, but it pays zero tip to the Coinbase? In this case, we agreed that we include the… Coinbase address into the block access list. So… In both examples, when there is no transaction, and when there is one transaction that pays nothing as a tip, in both transactions, the Coinbase address receives nothing. But in the first case, where there is no transaction. the Coinbase is not actually touched, and that's why we don't include it. In the second case, when there is a transaction, then the Coinbase is touched, and we include it.

Karim Taam: Just explain.

Toni Wahrstätter: Perfect. Is there anything else, regarding the Coinbase tracking before we move on? Great. Then the next point on the agenda would be testing and specs update. I would ask Rahul or Felipe, is there… are there any updates from your side, regarding testing and… Test releases.

raxhvl: Yeah, so clients are passing almost all test cases, the positive ones, so we're about 90… 89% of test cases that we're currently passing. The remaining 10 test cases has mostly to do with incorrect pal payloads, and I believe the clients are also passing those. But we're missing some exceptions within each framework. So, yeah, so we'll get that in probably… Late this week. And I think we should be good to go in terms of the current release. We're also working on a new release. For the tests that we discussed this past week. That includes, the Coinbase, updates, and… Some system operations, so we still don't have a new install, so…

Toni Wahrstätter: Awesome, thank you very much. Is there any updates, worth sharing from the first step that we had? Maybe from clients, or… From people involved?

Stefan Starflinger: I mean, the definite is still being set up, if that's what you mean. It's not running yet.

Toni Wahrstätter: Okay, all good. I saw, SSU right then, Nicole Steffen. I think you and PK, you were also working on, improving DORA, right? Because I had, like, a very naive DORA implementation at the beginning. And… Are there any updates? Any… anything you can already share?

Stefan Starflinger: Maybe Pike wants to update on the Bora?

pk910: Yep, Well, basically, we have, accessless visualization in DORA. I've reworked at you a bit to be more performant, so it's client-side rendered, and it's also able to render really big lists if needed. Another thing that's also added is a comparison feature, so you can post another BL and compare it to the one that is inside the block. So you can see diffs directly and, yeah, act on these. If there's anything that's needed, or any improvement suggestions, please reach out to me. I'm happy to add them as well.

Toni Wahrstätter: Amazing, thank you very much. This is great, especially the DivView. I can… I can see that this will be very handy in the future. Thanks a lot for that. Great, then, let's move on to the last agenda item of today. As usual, the client updates. Maybe we can start with Jared.

Jared Wasinger: Yeah, so basically the update on the GIF side is that we have been incrementally merging various parts of the access list changes into the codebase, there's still… Quite a ways to go on that front, but, we're working on it, I think now the focus is… While that is happening, also the focus from my end is on the development side is shifting back to, trying to Optimize the performance on our side, specifically focused on the performance of the state route calculation. So… Yeah, I hope to have more to share on that soon, but it's in progress at the moment.

Yeah, that's it.

Toni Wahrstätter: Awesome, thanks a lot, and yeah, would be great, if you can share some results in the call as soon as you got them. Sounds… sounds exciting. Perfect, then let's continue with Bisu.

Karim Taam: On the basel side, we are now passing all the… all of the RLP tests, and also enzyme tests. So we just need to merge the PR that Margie made to update the execution spec test. repo mapping. So we also started to implement the state root in background. At the beginning of the block processing, thanks to Block Access List. So, it's already working, but for the moment, just, we are logging the result of the statehood computation to compare. But in another PR, we will verify the state root and fail the block if it's not matching. But for the moment, just want to compare if it's working or not. What we want to do also in the next step is to do a shadow fork of mainnet.

And like that, we'll be able to measure the impact of the state routine background regarding performance on Bezoo. So, it would be nice if we can do that. And we are also working and trying to fix the parallelization of execution of transaction with block access list.

Toni Wahrstätter: Awesome, thank you very much. Let's continue with Nethermind.

Marc Harvey-Hill: It, so made quite a bit of progress with the, bowel construction. I've been testing out Interop with, Bessieu and Geth, and, now it's able to get quite a bit past the, Glow Asph walk. But there are still some, like, consensus issues after, a few epochs. So I'm having a look into that. But I've also just found quite a few, kind of consensus issues that were there, even though 100% of the tests were, were passing, so I'm gonna speak a bit to make some regression tests for everything I found. Awesome.

Toni Wahrstätter: Yeah, thanks a lot, and great, great inputs there. This… this seems like we… we haven't covered anything. Yet, everything yet in the tests, and definitely some… some more things to do here. Thanks a lot for that let's continue with ref.

Ishika: Hello, so for it, the tests were passing. As of now, we were moving from integrations of our branch to that of Dragon's branch, which I believe will be more architecture-friendly, concerning it will be less dependent on the Alloy VM. The majority of the parts are integrated, but there are certain things I would like to take care of. So that's something we are doing, but overall, it's alright, and possibly I will be… the error we are having as of now, I will possibly fix it by the end of the day.

Toni Wahrstätter: Great, thanks a lot for this update. Sounds… sounds very good. And finally, Aragon.

Mark Holt: Yeah, hi. So, where we are, we've just, I think, yesterday, merged our first PR, which is the basic support for bowels into Maine. There's a couple more PRs to go, which hopefully will happen over the next couple of days, so… I think we should have a DevNet Zero branch that we create, probably tomorrow or Friday. And then after that, we're kind of… We'll do some testing and see where we are. I would say we're about a week behind where I thought we were. on the last call, just because, we've got sidetracked with Fusaka issues, which kind of took priority. But we're basically back on block-level access lists as a, you know, as our primary focus now.

Toni Wahrstätter: Sounds good, thanks a lot. And let me know, or reach out to me, Rahul, Felipe, if you… if you need any help with getting integrated into the tests and everything.

Mark Holt: Yeah, yeah, so we'll do that, but I think we'll probably either be working on that Friday or early next week, just to set your expectations of… But I'm sure we'll start breaking stuff. As soon as we try.

Toni Wahrstätter: Sounds good. Thank you very much. Great, then this was the last agenda item we had on today's call. Is there anything else people want to bring up?

Stefan Starflinger: I just wanted to summarize regarding the definites a little bit more, that I've been finding a lot of issues working together with different client teams that I've been holding off, kind of, progressing and getting that live, but I think By the end of the week, I think we might be ready. I'm still… need to fix something with the consensus Layer clients that loads are in Prism, interop. There was something that I'm still looking into, and I hope that with Nevermind, it will also be working better, and then we can start the definite, I think, definite zero.

Karim Taam: Do we want to have the Coinbase modifications for the next DevNets? Because I think we'll have to do some modification in Bezoop.

Stefan Starflinger: That's a good question. I think maybe, Tony, that's something we could find out before we start, if we want to do a wait and have that modification in or not.

Toni Wahrstätter: Okay, Jared and Dragon are saying they want to, have it already? I'm happy to… to go for it, but it's more of a question for clients, I guess.

Karim Taam: I think it would be okay if we have some tests, just to be sure. We are working correctly. Okay, thanks.

Toni Wahrstätter: Perfect, yeah, just to echo what Rahul is saying in the chat. That, he's working on tests, this week, so that we have, those individual tests. I think we need a test for an empty block, then a block with one transaction, paying no tips. And the regular block, and then we should have everything covered there. But then let's agree that in the first FNAT, End of week, next week, that we, already include those most recent changes regarding the Coinbase tracking.

Stefan Starflinger: Sounds good, then I'll wait for that.

Toni Wahrstätter: Perfect. Is there anything else we should discuss today? If not… We can end the call at this point, we can end a little bit earlier, and… Yeah, see everyone in the next, 7, 9, 28 breakout call in 2 weeks. Thanks a lot.

Dragan Rakita: Bye.

Jared Wasinger: Oh.

Mark Holt: Bye.

Karim Taam: Alright.

Ishika: Bye.

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