All Core Devs - Execution #218

Transcript

Tim Beiko: Welcome, everyone. We'll get started in a minute or so. Okay, Josh, do you want to put us on the livestream?

Josh Davis: your life.

Tim Beiko: Thank you. Welcome, everyone, to ACDE number 218. Couple things on the agenda today. So, on the Fusaka side, I will discuss, what, is the latest with DevNet4, and, yeah, how the issue has been diagnosed, and where to go from here. Can also discuss the timelines, going forward. And then on Glamsterdam, we wanted to finalize the discussion around the headliners, that, we, been having over the past couple weeks. And I think, after that, it's probably worth discussing what we expect as the, the scope for the fork, or potential timelines, and how we want to think about that. And then, Tony had some updates on block access lists, and I think Jared had some, questions to discuss as well.

If we have time beyond that, Mikael had an update on Safe Head, and then there were two, EIPs that people wanted to bring up. … But to kick us off, I don't know if Barnabas is on the call, do you want to give an update on DevNet 4 and what happened there?

Barnabas Busa: Sure. So, demo for, launched last week, Friday, and, we went through a successful full transition. We went through successful BP01, BPO2, and then once we hit, BPO3, we started seeing some, issues, regarding gas and aragon. their, … basically calculation, for the blood fee, was, different than every other EL, and therefore they, decided to fork off. Gaff? issue has been resolved since. Aragon, as far as I know, they are still looking into it, and we still need to discuss exactly how we want to process this. And in the meantime, we also saw some issues on the CS side, especially Lighthouse. Lighthouse had a hard time finding peers and finding valid peers, and they, had issues, blocking invalid peers.

… They're currently still investigating, … They're just unable to sync up to head at this point. … That is the two main factors. Unfortunately, all of our boot nodes were Lighthouse and GAT pairs, and this also caused some issues in initial peering. in finding valid peers. Since then, we have changed half of our book nodes into, Prism and GAF. And, but we still have some issues, regarding, filling up the boot nodes with, peer list. Hopefully, we can get into a finalized train by maybe end of today, and … do BPO5, tomorrow.

Tim Beiko: Thanks, and I guess to get back to a finalized chain, do we expect, like. A lot of the validators that get slashed, or what will be the process?

Barnabas Busa: No, so ideally we want to have a fixed lighthouse image, because a pretty big portion of the network is lighthouse. We also have some issues with Nimbus SuperNodes, unable to fetch any valid peers. Once either Nimbus or Lighthouse manage to get the SuperNodes back up and running, then we should be able to finalize. A huge portion of the network is controlled by supernodes, just like main net would, basically. So, even if none of the full nodes are working, only disappearance should be able to finalize it.

Tim Beiko: Got it. There's a question by Marius asking me how far away we are from a lighthouse image. I don't know if anyone from Lighthouse is on the call.

Pawan Dhananjay: Yeah, like, we have tested out a bunch of fixes, but we still haven't, … like, we haven't been able to reliably sync yet, so, yeah, we have a few more ideas now that we are going to test, and yeah, hopefully we have something out by… in a couple of hours that at least, Like, syncs given, like, certain conditions or something like that. Of having super nodes.

Tim Beiko: Thanks. And was Lighthouse the only CL client that had issues after the bug, or…? Were there other… were there other teams with issues?

Barnabas Busa: So Nimbus also is having issues right now, still. They, as I mentioned, they don't have many peers, and also, quite some super nodes are offline.

Tim Beiko: Okay, and are we waiting or expecting a fix from Nimbus as well for this?

Barnabas Busa: Yeah, I have also reached out to them. Also, there was quite some, very deep reorgs, and, never mind. Got stuck in a weird loop for, some client pairs. But they were also investigating, but they said that it's most likely caused by a debugging Lighthouse.

Tim Beiko: I see. And then, on the EL side, so, Barnabas, you had a, the proposal, at least a summary of the discussion in terms of what to do about the update fraction calculation. Does everyone agree with what you proposed? Then I'll post it in the chat, but… … Yeah, Andrew?

Andrew Ashikhmin: Well, as I mentioned in the chat, I think, that, we should, actually, make a different choice. We should, Like, at the moment, it seems to me that we want to prioritize implementation, simplicity of our protocol consistency, but I think that's the wrong decision. Because if we… for, … go to the current implementation in Nethermind and Wrath and Bezu. The problem is that it's just inconsistent. It uses… a blob-based fee that is not an actual blob-based fee of any block, and I understand that it is slightly more difficult to implement the consistent version, but I think Again, it's just, to me, it sounds… Like, well, we, we…

We haven't made any hard fork on a public testnet yet, so we still have time to do it properly. And, to my mind, like, to do it properly is to make the… Things, easy on the pro… and, like, consistent on the protocol side. Rather than prioritize implementation over protocol consistency.

Tim Beiko: Okay, there's some comments by Francesco and LaScience in the chat. Yeah, I don't know if… Anyone else has opinions on this? And sorry, like, yeah, okay, I got confused with Barnabas' message, so, the message I posted is not the same thing, but on the fix for the current DevNet4 bug. Yeah, dead?

Ben Adams: Yeah, so… The two ways of doing it are using the the blob parameters from the current block, or the blob parameters from the parent block. And… If you use the one from the current block, then when a fork happens, the parameters change, whereas if you use it from the parent block, you have to wait 2 blocks after a fork for the All the changes to have occurred, so… Yeah, it seems better to… alter the parameters. Otherwise, we need to change the spec to be parameter-based rather than constant-based.

Tim Beiko: Thanks, Felix.

Felix Lange: Yeah, I'm just wondering, I mean, you… this is directed at Ben, so you have brought this up, this argument, like, multiple times, that, like, you know, it takes an additional block for the fork to, like, take effect. But I don't really see that as… like, I don't fully understand this argument, like, what's the… what's the issue with it, or what's the….

Ben Adams: Right, because you're, you're buying.

Felix Lange: your brother.

Ben Adams: You're both holding the.

Felix Lange: on the….

Ben Adams: current fork, and also the prior fork for some of the parameters on.

Felix Lange: So it's basically that what the argument is that the client has to be aware of both fork's parameters, or….

Ben Adams: Yeah, I mean, I don't know if it's a huge… Issue, either way. But, … But, you know, we have to decide one way of doing it.

Tim Beiko: Right. Let's see, yeah, bye.

Lightclient (Matt Garnett): Yeah, I just want to say, I feel like, after looking into this a bit more, I also kind of agree with… with Ben, and … the choice to have the parameters come into effect on the fork block. I think I recall we actually discussed something extremely similar to this during Pectra with the block throughput increase. Because the update fraction did… did also change there, and I think what we ended up doing is we changed it on the fork block, which is why… You know, everybody has access to the head block time. … To, to make that change. So, I think it's actually more consistent to… to do what Ben is saying here. The question… that I have is that… Yes, it's an unnatural…

It's not a natural block base fee. But we could resolve that by changing 7918 to calculate its value based on the current header's excess blob gas instead of the parent. Because this is how blob base fee is computed for the EVM. And I feel like if we do that, then we're consistent and correct with everything across the… every different, potential place where a blob-based fee exists.

Tim Beiko: Is there any downside of doing that? Aside from some teams will have to change their code, and, like, we might have to write… well, we'll have to write some tests with.

Lightclient (Matt Garnett): Yeah, I'm not sure. I would like to know from Anders, or anyone else who's more familiar with 7918.

Tim Beiko: I mean, Mario, I don't know.

Mario Vega: Yeah, I'm not sure what the… I really cannot read the sentiment of one option against the other, but from the testing and execution spec side, I think it's much easier if we don't need to have to access the parent block, the parent fork. block parameters, because we don't have a mechanism to do that in execution specs. It's not impossible, but I think that highlights the complexity, right? So, I would heavily lean towards only using the current block… the current block forks parameters. So BP01, it's enabled at fork N, and we use that, those parameters only, not… nothing… nothing to do with Osaka. Parameters, if that makes sense, yeah.

Tim Beiko: Thanks, Minos.

Milos: Yeah, I wrote on a Discord, I just want to mention it here, if people didn't see it. The similar problem will arise with the 6-second slot. I started prototyping that, and You also have, like, several parameters are going to change there, and the gas limit will have to be basically halved at the fork boundary. And the way that it makes sense… now, I'm not saying maybe implementation-wise is the easiest way to do it, but the way that it makes sense to do it is to do all the calculation of the base fee and the gas limit and everything based on the parent values. And then, if you have to do some post-modification, like, for example, in the case of 6 plus finality, to divide the gas limit by 2, you would do that after all the calculation is done for the parent. Otherwise, you can get into some… a bit tricky and ecosystem behaviors, but

I can understand that, for example, implementing one way or the other might make… might make things easier, either on the spec or on the clients, and it's probably not going to… like, disrupt anything if one block is not calculated based on the, let's say, logical form or anything like that, but I just want to highlight that for the 6 seconds block, we will have the same issue, and there, the parameters matter maybe a bit more of how you do the things, but we can do it one way or the other there as well, so… I just wanted to highlight that that's another thing.

Tim Beiko: Got it, thank you. There's the side conversation in the chat that basically says we… Also, yeah, can't use the current block. … Excess blood gas, … So, yes. Is this something we should align on right now, or do we want to discuss this further async and make a final decision on Monday's testing call?

Felix Lange: I think we should definitely decide it now.

Tim Beiko: Okay.

Felix Lange: forget. just because, like, this issue is pretty silly. I mean, we all agree the impact is, like, it doesn't matter, so this is just splitting hairs at a, like. very high level here, so… We could… we just take it to a vote, or like… Whatever, but we just… we have to go.

Tim Beiko: So I guess.

Felix Lange: Yes, it's….

Tim Beiko: what… … Yeah. Can we use the current parameters? I guess my understanding is….

Roman: Yeah, sorry, this is the reason why the fork happened, because half of the clients are using, like, current update.

Tim Beiko: Okay, so… Anyone opposed to using the current parameters. … The current block's parameters, on the fork block. Rather than the parent.

Andrew Ashikhmin: Well, I'm opposed, but, I mean, if… if I'm overrude, that's fine.

Tim Beiko: Okay, then yes, I think we should move forward for that, just to… oh, sorry, Felix, you were gonna say something?

Felix Lange: Sorry, yeah, I just really wanted to say that, like, this decision is great, but we should also figure out a way to specify this, like, how are we gonna explain this in the EAP, or in the specs, or whatever, and I think this is something we can do async.

Tim Beiko: Yeah, I was gonna ask who wants to own that. It would be good to have someone who can put a PR up, on the EIP, and ideally the specs or tests today. Or tomorrow? Yeah, Roman, and then Ben?

Roman: Yeah, I think that the fork happened exactly because, like, people treat the… the spec differently? Because in my mind, it's already clear that the, … the calculation function is defined within the fork, it uses the fork constant, and it does not resolve the parameters based on the header timestamp. It just takes header as an input. So….

Lightclient (Matt Garnett): The header is the parent header.

Roman: Yeah, the print header, but the function is defined by the hard fork. And the function uses the constant.

Lightclient (Matt Garnett): I think it's not that clear. I think we need to make it clear in the youth.

Tim Beiko: So I guess, who wants to own updating the EIP and ideally the test cases?

Mario Vega: I want to speak on behalf of execution specs. I think… I mean, as far as I can see now, there's nothing to update in the execution specs, because basically what Roman exactly said. So, the fork is… you already decided which logic to use. If you look at the header timestamp, you then decide, okay, I'm gonna go into this fork in the execution specs, and that's what I'm gonna use. And inside of that, you will find every constant that you need, you will find everything that you need. So I don't think… It's unclear on the specs, maybe it is unclear in the EAB. For the specs, of course, we can take care of that.

Tim Beiko: And then….

Mario Vega: The EIP, I'm not sure how to make it better, to be honest.

Tim Beiko: Okay, And they're saying he can fix the EIPs today. One thing that I guess we should probably also have is, can we have, like, a static test somewhere For this, so that, … Yeah, we test the spec behavior explicitly.

Mario Vega: We'll make, we'll make a release. If not a full release, we'll try to make, make sure that we have the side effects, Static tests out, by today or tomorrow, yeah.

Tim Beiko: Some links. Ben?

Ben Adams: Should this be, like, an assumed precedent? And if we… If it needs to, like, reach into the parent. There, then that's, like, the exception. We got prior fork parameters. Because I've heard that this has been a question on a number of VIPs before, whether to use, like, the prior fork or the current fork.

Tim Beiko: … Yeah, it might be worth asking that in the chat and seeing It's… Anyone disagrees?

Felix Lange: Sorry.

Lightclient (Matt Garnett): What was the proposal?

Tim Beiko: Should this behavior of using the current block to calculate things at port boundaries be our… basically our default for all the IPs?

Lightclient (Matt Garnett): Probably?

Felix Lange: It's not possible to answer this, yeah? Like, we cannot answer this in a general way. Okay, okay.

Tim Beiko: So, yeah, yeah.

Felix Lange: Ansgar has a comment saying that we should….

Tim Beiko: Oh, sorry, I've got the comment saying that we should just have the pressing do we explicitly specify it in the EAP every time? That sounds reasonable.

Felix Lange: I just want to quickly say that, and then I'm gonna… I'll be done. So, the… the… the problem with this whole thing is just that I think this is more an issue of, like, people just having a different model of these EIP constants and parameters, and it is always going to be the question, like, now that we have all these eaps, which are, you know, which basically try to update the values of certain parameters, we're going to be running into this more often, because within the clients, it's not always… we don't all handle it the same way. basically how the values of these concepts are resolved, or how this whole system even works, and it totally doesn't match the spec. And in the past, these things kind of just didn't happen, because we always just introduce new features with new parameters, but we never really modified the parameters, so now that we're kind of doing that.

I think this is why we're seeing this And… we do have to figure out a way, I think. in general… I mean, in the specs, it's pretty clear, because the executable spec is just code, so obviously you can run it, and that defines the behavior. So either this will be the point now where we just say, you know what, guys? Instead of always looking at the EAP and trying to guess it from the text, we can just look at the spec. I mean, to be honest, we should have done it in this case. Like, the spec is clear now. But, … Also, within the EAP, it's maybe pretty important to figure out some way Just making it very clear for all of us.

how these parameters work, and, like, what is the value… like, which value of the parameter is assumed in every context? Like, at the moment, it's just basically, like, when you're processing block X, then you're using the parameters, which are defined by the fork which is active at block X, but this is… I don't think this was so clear before. Honestly.

Tim Beiko: Yeah, and I guess this was also my point, that I raised in the Discord around, like, you know, where and how we should test this. Like, we found this on the DevNet, and… but yes, it… It feels like these are the types of things where we should have, like, a static reference that we're, you know, high High confidence that the clients, All have the same behavior, so….

Felix Lange: I mean, we would have gotten to the stat test sooner or later. I think it's just more the question of, like, it just wasn't really done yet, but it would have been done. Soon, like, this is not, like, we wouldn't… It was just a matter of, like, basically the testing team not getting to this area, like….

Tim Beiko: Andrew?

Andrew Ashikhmin: Yeah, I wanted to comment on Roman's point. So, to me, it was clear, like, when I was reading this spec, it was clear… the other interpretation was clear in my head, because my assumption was that this spec used pure mathematical functions. And, like, in Roman's interpretation, it uses global variables. And, we all know that global variables is actually… they are error-prone, so my suggestion would be to actually to strive to have pure mathematical functions in… in the specs. So, like, in now. It turns out this, getBaseFIPAA blobGas function, it actually doesn't take one parameter, it takes two parameters. And we should make it clear so that it's, like, mathematically, it now becomes a function of two variables, rather than a single variable.

And, yeah, if we, I think if we use pure mathematical functions, then there will be less room for confusion.

Tim Beiko: Okay, I think… Yeah, we can probably continue this conversation, I think, but at the very least, we should… try and define these things more explicitly. And yeah, perhaps, like, have a standard with how we, we, treat, like, the different functions of the spec, but, I know we have other things to cover, so… Anything else on this specific issue? Oh, yeah, Mario?

Mario Vega: Yeah, I mean, I don't want to, like, take too much time here to discuss, like, our current approaches, but I just want to highlight that Most of the time, the reason why we struggle to keep up with testing something is because it's normal that a change or an EAP comes out of nowhere. And it's just, like, suggested for CFI in all code devs with a prior notice to us. I think we should change that. I think we should, like, … Encourage EIP writers to reach out to us. And we should, together, come up with a document or something that explicitly details all of the testing complexities that we are going to find when we are testing DCIP. It's already happening in Amsterdam, which is good. The block-level access guys already reached out to us, and we're working together on that.

But I think it should happen for every single EIP, even the ones that look, like, super simple, because that's always the case. It's, like, a super simple EIP comes to ACD, and it gets CFI'd, without us even taking a look yet on testing side. So, my point is that we have to encourage EIP writers to come to us. And we have to have… to sit down and have a discussion about the complexity of the EIP, and we cannot come to ACD without having that discussion prior, even if the EIP is super simple.

Tim Beiko: I think that sounds reasonable, and, maybe, yeah, this is something we can, apply for Glamsterdam, so we have already, like, these, I think there's been 11 proposed VIPs beyond the headliners, so, … yeah, it's probably worth it to have, actually, these 11 EIPs chat with the testing team, … Yeah, as we're going into Amsterdam planning. And then, ideally, you know, EIP champions and client teams can also eventually just write their own tests, but yeah, I think if we have this set of EIPs already, we can, Yeah, we can make sure that we're looking at them from the testing perspective.

Okay. I'm… Anything else on the DevNet4 issue? Barnabas, you had this other point about the BPO fraction update. Right.

Barnabas Busa: So… we had this proposal, from Anders, saying that we should probably use, Max and target 3 to 2, properties, and use, Static, function to calculate the fraction values. We have posted it somewhere, but it would be just good, whether we want to enforce this, like in future deadnets, and also on public testnets. Or whether we want to basically set target and max at random values.

Tim Beiko: Antigar?

Ansgar Dietrichs: Yeah, so the… the kind of sticking… sticking to the… the formula for the… for the, for the update fraction, I think, I mean, that makes sense, at least, for ratio of, … Physically, … 3 to 2. If we ever were to want to go to a different ratio, then we would have to kind of make a more new pragmatic assessment. I don't think there's any specific reason to always stick to 3 to 2. I think, in general, it should be pretty much the upper limit, though, so we've already heard that sometimes there are issues where builders temporarily kind of have some issues with blob inclusion, and temporarily stop including blobs, and then we just can't hit the target. Like, then we're just staying under the average of 6 right now, and then the base feed drops down and everything, so it causes issues. So I think we should be very hesitant to do a

Ship something where we are above the… that ratio. But if there's ever, like, a… civic reason in the future to basically go to, like, a ratio that's closer to 50-50, to, like, basically 2 to 1 again, I don't see why we should pre-commit to not doing that.

Tim Beiko: Anyone else? Thoughts on this?

Alex Stokes: So it sounds like we want to generally have this as, like, a, you know. Design… well, not design goal, but something we aim for, but still retain the flexibility, in case we need to change it later. I believe that's what Barnas was asking for, is just if we could agree to this, like, you know, this structure. These relative ratios and everything.

Barnabas Busa: So the ratio… so this, update fraction formula would expect that, we have 3 to 2, fractions.

Marius van der Wijden: Yeah, but… What do you want to do with that? Was that formula?

Barnabas Busa: So we're gonna be using this, for, like, all… we're gonna be enforcing this on all future dead nodes, basically, and we're gonna be… calculate them. On the fly. So, like, we're not gonna be using, like, random, BPO values anymore. Question is if we want to enforce it going forward or not.

Tim Beiko: I'm… To Anskar and Polish?

Ansgar Dietrichs: Yes, I think we can't enforce it in protocol, unless… we, like, that then would have to come with a pre-commitment to also always sticking with the 2 to 3 ratio, because that update ratio only makes sense in that context of the 2 to 3 ratio, so if we ever were to ship something that has a meaningful different ratio, so I don't know, we have a ship. 2040 or something, for some reason, because we get feedback from the L2s that they prefer that or whatever, then we would specifically want to no longer use that formula. So, so I don't, like, I don't think we can enshrine that derivation. I do think we should always just use it whenever setting the BPO parameters, but it should not be in protocol logic.

Tim Beiko: Photos?

Potuz: Yeah, I was gonna say the same thing as Sanskar, but perhaps I can actually guess why Barnabas is trying to ask for this, and I assume that some tooling in testing I don't know, perhaps spamware or, like, blob spam uses a particular formula so that to update how many blocks they're sending, or something like this. And I would encourage not to use this formula enshrined, and just keep the flexibility. And we agree that we're generally going to use this ratio, but we're not going to enforce it in protocol, and we're not going to make it part of consensus.

Alex Stokes: Yeah, I think we agree on that point. So… I don't know, I'll just say what I say in the chat. Like, I think it's fine to have this pattern, like, if we want to, you know… if Barnabas is working on DevNet and, you know, wants to use this pattern to project out for, like, a PPO schedule, I think that's fine, but we should also all understand that it could change in the future. Like, it's not enough of a rule that it, you know, for example, could be enshrined in consensus.

Tim Beiko: Okay, so I think no agreement to, like, enshrine this in consensus now, and we can discuss, async… Yeah, to what extent we want to enshrine it in testing, at least for this work, and how hard it would be to change in the future.

Alex Stokes: It shouldn't really be something where we're locked in.

Tim Beiko: Yeah.

Alex Stokes: In terms of, like, yeah, feature compatibility. The only thing here is if we, quote, enshrine it in testing, it means we're not looking at other values, and there could be bugs there, just given present issues. Yeah. But that's not a reason not to do this, I'm just calling that out. Yeah, yeah.

Tim Beiko: Yeah, we can, yeah, I think we can discuss this more, ….

Barnabas Busa: I mean, I wouldn't pick values that have never been tested, so, like. Ideally, we want to be testing the values that we're gonna be using in mainnet. So, picking values that we realistically want to use in mainnet, and if we say we're going to be using this 2-3 fraction for, like, the next a few BPOs, at least, for sure. then I would say that we're going to be using this base 3 update fraction as well. Just if we want to use some other function.

Tim Beiko: Okay, well, I guess, yeah, we agreed we're not gonna try this in protocol. I think we can discuss, like. how to best support this in testing, either async or on ACDT, … But yeah, want to be mindful of time here. I guess, anything else on the DevNet4 BPO activations? If not, next step… Alex, had proposals, for dates, following from last week's ACDC, so I know there were some concerns raised about the dates, on AquaDevs then, and, since then, Alex has followed up with, the CL teams, which were, Mostly the ones that raise his concerns. …

Proposing that, we have the client releases for the first, testnet, for the first, testnet on… the first two testnets, sorry, on September 8th, so we would have Sepolia and Holeshki releases then. And then, for Koleshki on September 15, then for Acepolia on September 29th, and then on… after we see the Sepolia fork being successful, put out releases for HUDI, which hopefully would be the same as for Mainnet, so assuming that Houdi is just a, A clean, … yeah, like, a clean fork. I'm… And so in the chat, Pauline said Lighthouse has concerns with this, given, yeah, we haven't figured out the sync issues yet. Yeah. Any other… Thoughts or comments? Yeah, Alex?

Alex Stokes: Yeah, maybe I'll just rock… walk through these dates for a little more context. So… Yeah, I've talked to a number of people since last week just to follow up on this and try to, you know, dial something in so we can still target, pre-defConnect for Fushaka. One thing that came up, and it would probably be, like, the first event, so it's worth calling out, is with Haleschi, there doesn't seem to be an issue with having, sort of, non-mononical or, like, non, … You know, it's not having formal releases. We did this before with Heleshky, where, you know, operators are in, like, various branches, and they have some way to do this. So, that gives people a little more time to make formal releases, which I think will be nice.

We'd start the bug bounty, so yeah, ideally, there's just a pulley release on the 8th. So that we can fork to pull you on the 29th. That's, that pushed the fork there back one week from what we had last week in the schedule. Or at least the proposal. And the bug bounty would also begin then. And otherwise, yeah, it kind of proceeds like we had it. So, yeah, I generally was just curious how people feel about this. Again, as we see, things are kind of day by day on the status, … But yeah, so… yeah, I hear porn here on the Lighthouse thing, makes sense. And otherwise, yeah, I'd be curious what other… Clients feel about this. …

Especially on the EL side, because we're here, and if any CL teams can chime in as well, that'd be great, just so we can get a view of what's going on.

Tim Beiko: Thanks. Matt?

Lightclient (Matt Garnett): I just wanted to say, I feel a little worried that we're discussing timelines when we… we are running into issues that we don't even have static tests for, and these are, like, pretty basic stuff, like verifying… All of the clients are doing the right computation for one of the EIPs at the fork boundary. And… You know, we're getting close to having that stuff, but… it just feels like we're rushing this a little bit. And that's just, you know, on the EL side, like, obviously the CLs are having their own issues that it's causing the DevNet to… To not really work. So, it feels… it doesn't really feel appropriate to talk about the timelines right now.

Tim Beiko: And so you'd rather, basically, we spend the next week or two focused on, yeah, getting these tests up, ensuring that DevNets are, like, running smoothly, and then set a date. I know this came up also in the context of the CL side, like, you know, should we… should we wait to have, like, kind of a clean DevNet and then set a date? ….

Lightclient (Matt Garnett): Yeah, I mean, in the past, it's kind of how we've done it, right? Like, once we see a good DevNet. and we're happy with it, then we start setting the dates. And, like, you know, we can talk about ideal worlds and try to think about when these things are gonna be happening, and, like, make targets. That's fine, but… we keep making targets, and we keep… you know, we're on DevNet 4, and we said DevNet 2 might be the last DevNet, right? Like, at some point, we just have to be realistic, and like, let's just do it right, rather than continually try to… Push this fork out as fast as we can.

Tim Beiko: Thanks. Ben?

Ben Adams: On the last call, the… I'm not sure if it was testing or consensus, there was a concern that not everything had been merged. … And, potential delay from that? Was that… Would that mean we need another DevNet?

Tim Beiko: Right, so the, yeah, the concern was that a lot of the CL, the CL code was running off, like, a non-master branch. I believe.

Ben Adams: Yeah, so they were in, like, a feature fork, rather than the mainline code.

Alex Stokes: Yeah, my understanding is that, people have kind of put in quite a bit of a lift, to resolve that. So… Yeah. … DevNet5, I think, would be useful, and the question is, like, how much can we interleave that with the schedule that we have?

Tim Beiko: Yeah, and I guess to DevNet5, are we saying we would just want to apply the fixes, to the BPO schedule that we discussed? and obviously the fix is on the CL side in terms of syncing, but there would be… No other changes.

Barnabas Busa: Yep, so basically we want to make sure, I think we're gonna be running another big… Devnot. And we're gonna need to make sure that, all the BPO changes are working as expected, and without any extra noise. we made this… we wanted to make the measurements for BPO numbers in this DevNet, but it's just so noisy that I think we're not going to have enough useful information, unfortunately.

Tim Beiko: Got it. Adrian? We can't hear you, Adrian. Oh. Okay, so… In terms of, … moving forward with a dead net 5, I assume we'd want it, you know, at the earliest next week. … The blockers would be… Effectively, the Lighthouse issue, the Nimbus issue, and then making sure that all the clients pass some static tests, on the EL side, in terms of calculating these, these blob parameter values. Anything else?

That we would want to, see before launching DevNet 5.

Saulius Grigaitis: Yeah, so for them at 5, I would suggest to increase a share of minority clients, so… So, like, Grandinian Lighthouse is maybe 1% or 2%, and if we could increase to, let's say, 4 or 5% of share, I think it would not make any harm, and the same… at the same time would help a bit for us to test more things. So that's for DevNet File.

Tim Beiko: What specifically would you test more? … In that scenario?

Saulius Grigaitis: I mean, it's, at least from… from my experience, so… so we… we get, like, way less block proposals, and we have way less combinations with other ELs and so on, so it's, it's a bit tricky to… To get, fast, a good response of what is wrong with our clients. It's a bit hard to explain that.

Tim Beiko: Yeah, no, yeah, I think that makes sense. I think, yeah, you get less. I think there's a trend… tension here between we do want the DevNets to somewhat, mimic mainnet. I would defer to PandaOps in terms of, like, what's the right ratio here? Like, if, you know, if Grandine is 1% on mainnet, like, what's the max we should put on a DevNet? … I don't know, Barnabas, if you have opinions now, otherwise we can discuss this on the second call.

Barnabas Busa: We use the clientdiversity.org numbers in order to determine how many validators each TL and EL should have. These are approximations, but these are the best we have. We can… And would there be, yeah….

Tim Beiko: Yeah, would there be downsides to, like, for the smaller clients, you know, like, Lodestar, Grandine, even Aragon and REST, that have, like, you know, somewhere between 1% to 3%, like, doubling or tripling that so that there's, like, you know, 3% of Grandine nodes, or, like, you know. 5% of breath, or something like that, so we get more data, or… Yeah.

Barnabas Busa: Yeah, I mean, we can… we can increase it, for sure. We're gonna need to then reduce, you know, the share of Lighthouse and Prism, for example. And the same way as, for RAS and Aragon, we can increase those as well, and remove, some gas and other minor nodes. Yeah, and for example, for DevNet4, it would have been actually beneficial to have a bit less share of Lighthouse, because right now we see a non-finity, mainly because, Lighthouse.

Tim Beiko: I do think we should probably keep those thresholds, though, because, if on mainnet it's true, you know, that, like, Lighthouse and Prism represent more than, than two-thirds. We should make sure that the DevNets mimic that, but then within these, like, bounds of, you know, how much we need to finalize. like, we… I think we can have some… some flexibility. … Okay, … So yeah, so I guess we could move forward with DevNet 5. Again, have these CL syncing fixes, have the ELs changes, based on the new specs. And, yeah, we can discuss on Monday how the bug fixing is going on the CL side to see when's a realistic time to launch this. If things go well, then potentially we can launch DevNev5 before ACDC next week.

And yeah, test all the fixes, see how we're feeling about, Yeah, about the fork, and discuss state stem, if appropriate. Okay, anything else on Fusaka? Okay, … Moving to Glamsterdam now, so we've been discussing the headliner selection for the past few weeks, and on the CL side, we've landed on EPBS, and then we had previously said we would, like, conditionally do block access lists. If we did the PBS on the CL side. So I wanted to do one last check there, and I think also highlight, like, one other thing that's come up in the past couple weeks of discussing headliners is, you know, with the discussion around fossil or around repricings, I think there's been, like, some…

I don't know, potentially, like, lack of clarity between, you know, should the headliner be, like, the biggest thing in the fork, or should it be the most important one? I think on the CL side, those two things are quite, aligned. Like, everyone seems to agree that, EPVS, or there's a strong consensus that EPVS should be the most important thing in the fork, and it's obviously the biggest one. But on the EL side, I know we've had, like, these discussions around, like, okay, you know, is Fossil the most important, this block access list, or is, is potentially something like repricing? … Yeah, not to say that we shouldn't do either of those, but wanted to at least raise it.

Any concerns, thoughts? Otherwise, I think we just move forward with block access lists and EPVS. Okay, we have some block access list support in the chat. So we'll merge, we'll merge the PR that Alex had opened, so this means we've set both, EPBS and Block Access List as the, two headliners for Amsterdam. I think, one thing that would be helpful to discuss Now is, how do we actually, want to think about the scope for Amsterdam and timelines? I think, obviously, we can't set dates from the very beginning, but it is helpful when we're thinking about, yeah, what else to consider, how many other EIPs, whether to do, you know, another, like, big thing like Fossil, or, to add a bunch of repricing EIPs, like, what's the rough…

Target we'd want to aim for, and how do we… How do we, like, Yeah, roughly… go towards that. … My proposal would be that we should be fairly strict in terms of just, getting EPBS and block access lists implemented and fairly far along before we consider other things. But yes, curious how other people feel about that, and how they think we should approach the process. And yeah, to Totas' point, setting your timeline target, would make scoping easier, and yeah, OnScar. has this, rough timeline around, like, okay, should we try to aim for June for releases? … So imagine we did want to aim for June, which is kind of in line with what people have been saying around 6 months forks.

You know, how does that affect our scope? I guess, yeah, maybe it's a good point to start. Does anyone think we should not try to at least roughly target June for a hard fork. … And if we're forking mainnet in June, it means that we should have releases ready for, like, testnets and whatnot in April to give us the time to fork these testnets and move forward, yeah. Yeah, Ben?

Ben Adams: I think, … Yeah, trying to maintain a 6-month cadence is good, because then it does relieve that pressure of people trying to get everything crammed into a fork. Because you only have to wait you know, 6 months. It's not, like, a year plus. So, hopefully the small forks can be smaller. Although, that didn't really happen before.

Tim Beiko: I'm… There's a question about, like, can we get some… commitment to fossil if it doesn't delay the fork by more than n months. I think, realistically, the only way to do this would be that we say block access list and EPBS are the two first things, and we don't include anything else until those are pretty ready, and then we include fossil, and we don't include anything else. … I think it's very hard… if we commit to doing, like, fossil or anything else significant now, the code kind of gets intertwined, … So, like, yeah, I would strongly prefer, like, we… We make a call once we're… farther along on the, on the implementation of the two headliners. This means, you know, if we want a CFI fossil, we can CFI fossil, but we

we then need to decide, like, okay, is there anything else that we're doing before Fossil in this work? And, you know, ideally have, like, both block access lists and EPBS running on DevNets before we make the call of adding something. Yeah. Draw?

soispoke: Yeah, no, I… I mean, I think I agree, but just… Still, it's a bit of a hard thing to wrap my head around, because having this sort of, like, conditional inclusion up until, maybe after we have, like, some more certainty on, like, EPBS and BALS, makes it quite hard to deal with how we proceed in the meantime with Fossil. And I do want to… insist that it was, like, basically the most supported EIP, by the community. It was, like, 14 out of, like, 21. I guess, like, suggestions, … And… yeah, so I'm just saying, like. And it was also proposed as a headliner, and the community actually voted on it being proposed as a headliner, so now, basically saying, yes, we sort of, like, CFI it, and put it

as a vanilla EIP and conditional inclusion need before we… it's just, like, a bit of a weird in-between that is….

Tim Beiko: So, I guess….

soispoke: to deal with.

Tim Beiko: Yeah, so I guess, like, yeah, clearly we want to do block access lists and EPBS, that's a priority, so we should schedule those for inclusion and start working on a DevNet with them. I think it would be reasonable to move Fossil to CFI, if people agree, and then… like, any other CFI, the EIP, like, when they… when it gets… oh, fossil is already CFI'd. So, like, yeah, when… in that case. Yeah, in that case, when we're ready to actually start implementing it, we'll have to make a call between whether or not we want to move that one from CFI to SFI, or anything else. I don't think we can actually make this call today, like, there is some uncertainty.

Yeah, so I… but I think, like, yes, if it's actually true that people want to keep fossil as the highest priority and put it in the fork, then I think the way we reflect that preference is by, implementing the two headliners, and then, And then making the call to implement fossil NEX, if we think we have the capacity for it. Mark?

Mark Mackey: Yeah, I mean, this was brought up in the last call, that there was a concern that the CL side and the EL side might not take the same amount of time to… basically, … finished developing the EIPs slated for the fork, and that… you know, that it might be possible that the EL is ready sooner, and if that were the case, then possibly decoupling these forks, … And I would say that leaving Fossil in CFI status basically enables us to continue with that strategy. Like, if it looks to be that the CL will take longer anyway, then it would make sense to leave fossil out of that fork, but then do it in the next…

fork, which will come at the same time as EPBS, … And vice versa. Like, if they're gonna be the same time, then you can put it in, but yeah.

Tim Beiko: Yeah, it's true that, like, yeah, we can still split the forks. I think that quickly becomes… Less true as we move farther with the testing, but, … It's definitely easier to split things if there's no cross-layer, feature, yeah. Polis?

Potuz: Yeah, so once we specified something and we more or less have some clarity on the fork, I think this enables clients to allocate resources better. We are now in a better shape to start working. My proposal would be to try to arrange, not here, but probably ACDT, or even, like, informally with PandaOps. on a zero-dev net that… on the CL side, that would have a PPS. Minimal… I mean, the minimal implementation without builders, self-building, but the separation, which is the hard part. I believe we can do this in one to two months, all clients. Once we have this, it's very easy to try to add fossil on top of this and get an idea of how long it would take.

But without… without having a full implementation of neural appliance, it's gonna be very hard to even gauge, how long it would take to add fossil on top.

Tim Beiko: Yeah, I agree with that, and I think we… the DevNet should be… Also, including block access lists, … And then, yes, once we have this clamster down .NET1, we can determine what we want to add on top of it. Yeah. Karen's?

Terence Tsao: Yeah, I can just pause on this comment. I would say, like, EPB… sorry, Fossil on top of EPBS will look much different than Fossil on top of, like, Fulu, for example, so, like. Currently, our estimate on how much fossil work really is may, like, basically, basically may be completely off, because we're not looking at fossil on top of EPBS. So, so definitely makes sense. to get EPBS in some fundamental stage, and then add Fossil on top.

Tim Beiko: Okay, so I think… That all makes sense, so we move forward with EPBS and block access lists being SFI'd, get DevNets with those, and… and then make decisions about, SFI and the other things. We do fossil, CFI'd for now. … We also had this 6-second slot headliner as CFI'd, but I think if we're accepting APBS, then it means we, like, by default, are not accepting, this EIP7782, so I would remove that one. And then, … The other thing I want to discuss is when should our deadline be for proposals for just regular non-headliner EIPs? We've had a few already, I think there's 10 or 11. My, yeah, my suggestion would be the Fusaka Mainnet releases, not necessarily the fork, but I think whenever we have the Fusaka mainnet releases should be when we stop accepting new proposals, and we can start actually reviewing what's there.

Does that seem reasonable?

Alex Stokes: I think so.

Tim Beiko: Yep. Okay. … Okay, so… Yeah, we confirmed the headliners, we're gonna remove, the 6-second slots proposal. keep Fossil as the only CFI proposal for now, and then if anyone wants to propose other EIPs for the fork, you can open a PR to the Meta EIP, and, we'll have the deadline for that be, the mainnet, releases for Fusaka, and not have to, Yeah, not have to, review them by then. … Okay, on… … on, Amsterdam Headliners, I know Tony had a couple things about block accesses that he wanted to discuss, so that probably makes sense to go, yeah, moving forward with that.

Toni Wahrstätter: Thank you very much. Let me share my screen very quickly. … Right. Yeah, I basically wanted to quickly discuss, three open points that we still have with block lab access lists, and now that we SFI'd the EIP, it makes sense, to discuss those, because more people had an opportunity to look into it. Essentially, the three points are… First, should we include the state locations into the block lab access lists or not? So, state location is basically everything that comes with an S load, or a balance opcode, calls, static calls, and so on. It's basically everything that isn't modified, so everything that is not in the state div. The second point is RLP versus SSC, and the last thing is how to handle system contracts, because Jared brought it up in the…

in the, Discord, and yeah, makes sense to discuss it. So first, yeah, would love to hear people's input, especially clients' input, about state locations. The thing is, originally it was planned that it can be used for parallel batch I.O, so before even starting executing, you would do all the disk reads up front in parallel. And the question is, would clients actually use it? Or would going, parallelizing transactions, and in this way also doing somehow parallel discrete, would that be already enough? Another point is more info. Of course, if we keep all the state locations, this means we include more info, and then that's the question, is that info actually useful? And it might be useful. So I've talked with,

People working in auditing, and they said it might be useful to know, exactly in which transactions, which contracts were touched. The con on the right-hand side is, of course, the size. It adds, like, 50 kilobytes, this is, like, 22 kilobytes, on average today, at 40 million gas limit. This is, like, at the target, so it would double if we are really at the limit. So, of course, this is, like, the problem. It adds quite significant size, and I would be curious what EL clients think about Yeah. Should we include them, or should we drop them?

Jared Wasinger: I feel like without having a performant implementation that shows that there's tangible benefits from including them, it's… hard to argue for them. I don't quite understand the auditing perspective, but I mean, I'm not an auditor, I'm a core dev, so maybe that has merit, but… … Yeah, so like, like I've said before. The more we parallelize the transaction throughput, the less this, including these, gives us. So… There we go.

Karim Taam: I, I think also, having this state location. will not only help to have parallel batch I.O, but it will also help to do real parallelization, so… Execute all of the transactions in the same time, and after merge the modification, so it will help to have more improvements in the future, so… I think it would be nice to have it, yeah.

Tim Beiko: apples.

Potuz: Something that I haven't seen discussed, and I think Anders is the only one that is pushing this forward, is to have a more formal approach. If we are going with the PBS, then the worth the cost of broadcasting and of executing the blog changes. We have resources in a different way than what we have now, so I think all of these considerations of bandwidth versus execution should be taken into account On what is the time that we're gonna have to both of them, and what's gonna be useful, and how we want to optimize those. So it's not a discussion that should be had with, like, today's parameters, but with tomorrow's parameters, when we're going to include this.

Toni Wahrstätter: Yeah, I think it's fair to say that, we don't really know how much clients get without actually having client implementations on that. at least from the specs, it's not much work to add them or to remove them, but I guess in client implementations, this might be different. Maybe, Jared, could you elaborate more on… How much work is it if we don't decide on… we don't take a decision today, and for now we keep them inside, and then we figure out along the path to remove them?

Jared Wasinger: … Adding them to the BAL is trivial. … I think, I think it's, I think it's trivial to keep them in. As far as the complexity goes.

Toni Wahrstätter: Okay, yeah. then I would say, let's just keep them in and move on with the second item, which is SSAT versus RLP. So there were, people pushed for SSD because it allows for more compact proofs, and the blocks have access list, including the post balance of every account that, was included in the block. There were some use cases brought up where SSS might be useful. The thing is. Oh, someone is drawing, or it wasn't me? The thing is, RLP is smaller. I mean, this is, like. almost negligible, but it's smaller, and of course it's known and tested, so I would be curious if there is appetite on the EL side to start into getting SSS.

Or if we kind of want to further postpone that. I personally don't have a strong opinion, and right now it's an SSD. I think it's quite nice because of the compact proofs.

Tim Beiko: I think Justin, Yelm, and Roman have opinions on this.

Justin Florentine: Yeah, real quick, I appreciate our interest in getting SSZ onto the EL, I'm very much for it as well. This pops up a lot, and we… you know, always avoid it. We always kick the can down the road. I think there's good reason for that. I think… technically, I think there's a good reason, as stated on the slide, to adopt SSZ. I want to make sure that everybody is aware and mindful that we will be adopting a sort of hybrid serialization mechanic on the L1. And it will likely stick around for a while, short of us having a headliner release that focuses entirely on a full conversion from RLP to SSZ. I think continuing the process of migrating from RLP to SSC will be a, you know, gradual one, and so that means that maybe a ride-along EIP every hard fork. So, you know, I think it's realistic to say that if we do this in an incremental fashion, you're looking about, you know, 2-3 years before it's, like, fully adopted. So, …

I want to raise that as a concern from a project management perspective, more so than a technical one. So, thanks.

Tim Beiko: Yeah, Guillaume?

Guillaume Ballet: Yeah, two questions. Okay, actually, one remark, one question. The problem with SSD is that in Go, there's not really a good library. There are some that do the work, do the job, sorry, but, but there's none that really makes us happy. So that's the first thing to consider. The second issue, or at least the second question I have, is if we pick RLP, one of the advantages of SSE over RLP is the extensibility. I think it's easier to extend an SSE container than an RLP container, especially if we get Ethan's favorite topic, the I can't remember the name now, but the extensible object… sorry, I forgot the name. If we go for RLP, and, you know, there's, like, 5 flavors of BALs.

do we have the flexibility to add more fields later? Like, if we decide, okay, we start with BALs with only the locations, and then we want to add the post values later, is it going to be a headache to add those… to change the format, basically?

Toni Wahrstätter: No, shouldn't be, shouldn't be a problem. I mean, we always have, like, the versioning through the fork, so basically, by having the slot number or the timestamp, you have a versioning.

Guillaume Ballet: Yeah, I'm really talking about just in terms of fields in the, you know, in the structure. If you add a new field, this is going to be a nightmare to handle, so it's not a spec-level question, it's more like a coding question. So I guess that would be more like for Jared.

Toni Wahrstätter: there could be… there could be a problem if you kinda, if your Merkle tree for Merklization expands by one, tree level, by one depth, then, the proof would also change. We had that problem on the CL with the stable containers tried to solve. I guess introducing stable containers here would be, not worth it. But… yeah, so it's not super trivial to just add a new field. Yeah, it feels like right now, ….

Dustin Brody: I… I….

Toni Wahrstätter: molded.

Dustin Brody: I have a….

Toni Wahrstätter: Not gone. No gone.

Dustin Brody: I have a question about the Go SSC. SA has a structural point about this. So, … specifically the GoSSC library, thing. Putting aside some of the… snarkier comments or whatever, and, you know, the discussion, or including them, either way in the chat, but the idea of this… … concern, objection, I don't know, has been raised from the beginning, and there's a sort of a… a circularity to it. It's that… there's a… there's a reticence, that has been expressed by at least 2 or 3 different people on… on EL's side to say, oh, to add any SSC feature, whether it's the you know, the first of an anticipated, sort of, two to three year transition, or one kind of Big Bang EIP, or the whole, yes, as, people were referring to, alluding to Ethan's, so the stable containers, more broadly, the pure ETH is kind of the current push there, which includes stable, containers, essentially. But…

But the idea of the Go SSE Y Bridge, this was to a year ago, this was to 2 years ago, is there, an ambition? Is this a… essentially a way of just deciding not to do it by refusing to implement a quote-unquote good GoSSE library, or, refusing to define a library as good. I mean, I'm a little bit snarky here, but I'm also semi-serious, because it's… it seems like, at some level, sort of insubstantial objection.

Tim Beiko: I guess.

Guillaume Ballet: foot.

Tim Beiko: I'm not a Go expert, but my perspective on SSD from someone who has zero skin in the game, I don't maintain the client, is, … It sounds like the type of thing we always say we want to do, but then the revealed preference is we… don't actually prioritize it, because there's higher impact things that we agree to do in the protocol. My… Personal preference at this point is, like, we should… consider it only as a standalone thing. Like, you know, if we… if we add one more RLP object today, then it's one more RLP object to migrate in the future, you know, in addition to all the ones we already have. like, you know, there's not much incremental damage in a way, and I… Yeah, my sense is, like.

unless there's, like, an explicit stated preference from the EL to say, now we're moving to SOZ, we should just assume the EL is using RLP. Maybe the best like, proposal I've seen on the SSD, on the EL side, was, I think, from Peter from Guest a few years ago, where his view was, like. we should probably start by moving the peer-to-peer layer of the EL to SSD, because this is something clients can do at their own rhythm. We don't need to coordinate on it, and then it would force all the clients to use the library. And then, you know, once all these clients have integrated the library, maybe a year or two after, you know, we can drop the RLP on the peer-to-peer layer and assume that we're transitioning to consensus, part of the clients, or…

consensus-critical part of the clients. … But it does feel like, yeah, it keeps coming up as, like, this side, like, topic every time, and it somewhat gets shut down, or, like, has, like, I don't know, lukewarm enthusiasm, so I… Yeah, I… I feel like it's probably better if we just assume that EL is in RLP, but, … Yeah, go to that, or Sig, Guillaume, and Tony?

Guillaume Ballet: Yeah, I just wanted to address what Justin has been saying. It's not like we haven't tried to make SSD work. Peter spent a good chunk of last year trying to get it to work. It's… I mean, we do have libraries, they're just not good. They come up with a lot of, … of issues that we have to go around. They all have their trouble, and it's not like we're not trying to… to block it on grounds that we feel it's going to be difficult. We have tried, we know that, and so, yeah, when we say we… Okay, it's me, but when I say I don't want SSD because I think it's, it's going to be a lot of trouble for what it brings, it's, it's what it is. It's, like, we know it's a fact.

So… I think RLP works, and sure, when it comes to… if we ever move to SSE later, we'll have to do a conversion, but then that assumes we will have a good, a good library by then, and we'll… the transition will be a breeze. It's just one more object to transition. The thing is. We… yeah, we don't know how to handle that efficiently.

Toni Wahrstätter: Yup. Yeah, thanks for the input, … Feels like I got the feeling that, ELDFs are most… more leaning towards RLP, so I will update the EAP to have RLP as the default for now, and… It should be as soon as the library exists, it should be an easy change in the end, so we can theoretically still switch to ROP. But let… R2SSC, but let's keep it, for RLP. For now. And the last thing that will be a very quick thing, it's basically, there was a discussion around how to handle system calls. Basically, we have two system contracts that cause state changes pre-execution, so pre-transaction execution, and three system contracts that cause state changes post-execution. Basically, we have those ring buffers where we write the parent hash and the beacon block root into, and then withdrawals cause a balance diff, and the EL-triggered withdrawals plus maxiB, they both have a queue that is then dequeued at the end, and you need to update those four.

First slots, please correct me if I'm wrong, and look at the EAP if you were involved in those EAPs, but I think I got the edge cases, right there. And then the proposal would be to encode those state changes into the block club access lists by doing… All… everything that occurs pre-execution is mapped to transaction index length of transactions, which is, like, pretending it's the last transaction, and everything that is state system contract related that occurs post-execution will just be, yeah, incremented by once. The cool thing is, like, this maintains that the block level access list, transaction indices are the same as the block transaction indices, and this was kind of important to me. Yeah, I think… I'm not sure, Jared, if you, …

If we find consensus on that point already, and if others have an opinion.

Jared Wasinger: Yeah, so I guess my original point of contention here… I know we've now agreed to separate the pre- and post-execution system contract changes, and that's… I think that's really what is… Important for simplifying the client implementation. So my preference, which I've stated before on the Discord, is that the index in the… in the… in the access list should Like, if you take the index of all state changes in the access list, it should reflect the order in which they would be sequentially applied to execute the block. So essentially, like, what I would… prefer is that the index 0 be the… the pre-execution And then proceeding, … and then after that, the transactions, and then the last index would be any post…

state changes. And so I think that your pushback against this has been that this does not… So this would mean that the index of the BAL state changes does not… for transactions, doesn't reflect Their zero… their index within the block. … And I would say that… From the implementation perspective, this is, … pretty… a pretty trivial issue, it's not… I mean, if you're implementing it for the first time, it is bug-prone, but there… it… like, basic test coverage can catch this.

Toni Wahrstätter: Yeah. I don't think it's a problem for client devs. It's more like, imagine you're a user that uses an RPC, you query a block, and then you look at the block level access list, and suddenly. Transaction Index 1 in the block level access list is actually… transaction zero in the block, right? This is like….

Jared Wasinger: But you can imagine that people will build tooling that accounts for this, right? I think… I mean… having just, like, looked at the JSON encoding of some of these blocks access lists, they're not exactly, like, amenable to being able to… some of the bigger ones aren't really… I mean, it's hard to manually parse through these, right? Like… I don't think that users… Yeah, I think there will be tooling developed around this, and that it won't be an issue.

Andrew Ashikhmin: I wanted to say that I agree with Jared. We implemented something similar in Aragon for… we also have virtual pre-execution and post-execution transactions, and it's logical, like, to arrange them. Orderly, so 0 corresponds to the pre, like. Beginning of the block, and … Yeah, the last one corresponds to the end of the block. Otherwise, I think if they are not ordered, it will be very confusing. for developers, I think… Like, having them ordered will be less confusing to the user, because if… even, like. Like, otherwise they say… they see, oh, okay, there are two extra transactions, like, transactions at the end, what does it mean? So it's better to just do it… in the sorted order.

Roman: I think it's a little bit of a semantical question as well. So, my suggestion, since both transactions and pre- and post-block executions, there are just state transitions, let's just… call this index the State Transition Index in the AP itself, and then go with the… with what Jared said were… Like, all of the items are in their chronological order. And the block level access.

Somnath Banerjee: I would suggest, keeping it different from the transactions list, and… Perhaps, arranging it in A separate section, because they are not actual transactions. I think that's the most confusing thing, to mingle it with. The transactions, because… they're not going to go through EVM in some cases, and are applied Sort of in a different fashion. So, there is… if there were to be benefits of parallelization, on those, … I firstly doubt there would be, but if there were, I think they're going to be processed. Differently, so it doesn't harm to… Just have a system contract section in the list, and, like. Put your, transactions order, over there. And, it would be up to client teams to figure out what to do with this.

If they want to warm it up, before, they're free to do it. Or if they want to go in how it is right now, which is just, let the transactions happen, and then Apply, the system contracts. Afterwards and check if everything is okay. If they want to do that parallelly, which is kind of risky, they can do it. If they want to do it sequentially, they can do it. Maybe just keep it separate.

Toni Wahrstätter: Okay, thanks. Yeah, this is super helpful. So just to summarize it, it feels like we definitely want to keep pre- and post, different, so that we in the future allow for system contracts to have, for example, balance changes pre- and post-execution, and then we don't like, the way I proposed it, with having two additional transactions, but instead we only have one additional transaction for the post state, and instead shift every transaction index by one, and I have, the pre… the pre-execution changes, as transaction index 0. I will update the EAP on that, and we can… we can still further discuss it in the Discord.

Jared Wasinger: I think if we do that, we should probably move away from calling them transaction indices.

Toni Wahrstätter: Right, yeah, I can call it, … block level access list index, or something.

Jared Wasinger: Yeah, sure.

Tim Beiko: We can, by check the name, I think, … But yeah. Oh, Marius is saying, yeah, there should be a block access list breakout, Do we maybe want to do a first pass of modifications on the EIP, and then discuss those in a breakout once Tony has them?

Toni Wahrstätter: I'm happy with you.

Tim Beiko: Yeah, so yeah, people have a bit of time to review async, so yeah, just let us know when you have the changes to the EAP, and then, yeah, we'll schedule a breakout. Yeah, okay, so we only have 2 minutes left, and we had a couple more things on the agenda, but I don't think we'll quite have the time to Get to them. … there's two EIPs, so people can review those async, and then Mikael, you had, the Safe Head, proposal. I don't know if… yeah. Two minutes is enough, or if you'd want to point people as well towards an async place to discuss.

Mikhail Kalinin: I can do a very short, overview. Yeah, and then we can move to a singing discussion. So, yeah, we have, … … the, work in progress on the prototype of the fast confirmation rule in a couple of CL clients, so now is the time to decide how we will expose the fast confirmed block to the blockchain data consumers, and there are basically several options to do that. First one is to repurpose the save block for the fast confirmed block This is the easiest one, because we will not need to change the engine API, we will need to change the GSNRPIS API, and just to recall, to remind everyone that the save block was introduced for the purpose of fast confirmations.

But it's been a long time ago, and yeah, it's been a justified block for almost 3 years, so some data consumers can basically rely on that safe block means justified. And yeah, that might impact them. And yeah, this is basically the default option. The other one will be to introduce the fast confirm block hash to the engine API and fast-confirmed block tag to JSON RPC API, which is more intrusive from the API standpoint. And the third… the third option would be to To make the save block, the semantics of the save block, depending on the runtime configuration of the CO client. So this has some implications. Because the basically safe block, semantics will depend on, on the node operator and on the, node's configuration, which might be a…

prone to misconfiguration and other things, so, yeah. But if you're a Say block consumer, and you're listening to us, please reach out to us in the EtherMD Discord in the 3 Star PC API channel, because this change might affect you. Thank you.

Tim Beiko: Okay, thank you. Let's wrap up here, and yeah, we can discuss the DevNet 5 progress on Monday's testing call. But yeah. Thanks, everyone.

Alex Stokes: Thank you.

Toni Wahrstätter: Me too.

Potuz: Hi, thank you.

Fredrik Svantes: Thanks, Mike.

Marius van der Wijden: Okay, thanks, bud.

Mark Mackey: Hey, guys.

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