AllCoreDevs - Execution #218

|2025-08-14| Agenda: #1652| canonical JSON

Transcript

Tim Beiko:Thank you. Welcome, everyone, to ACDE number 218.

Tim Beiko: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.

Tim Beiko: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,

Tim Beiko: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.

Tim Beiko: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.

Tim Beiko:…

Tim Beiko: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: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.

Barnabas:their, …

Barnabas:basically calculation, for the blood fee, was, different than every other EL, and therefore they, decided to fork off.

Barnabas:Gaff?

Barnabas: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.

Barnabas: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.

Barnabas:… They're currently still investigating, …

Barnabas:They're just unable to sync up to head at this point.

Barnabas:…

Barnabas: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.

Barnabas:in finding valid peers. Since then, we have changed half of our book nodes into, Prism and GAF.

Barnabas:And, but we still have some issues, regarding, filling up the boot nodes with, peer list.

Barnabas: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.

Tim Beiko:A lot of the validators that get slashed, or what will be the process?

Barnabas:No, so ideally we want to have a fixed lighthouse image, because a pretty big portion of the network is lighthouse.

Barnabas: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.

Barnabas:A huge portion of the network is controlled by supernodes, just like main net would, basically.

Barnabas: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:Yeah, like, we have tested out a bunch of fixes, but we still haven't, …

pawan: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,

pawan:Like, syncs given, like, certain conditions or something like that.

pawan:Of having super nodes.

Tim Beiko:Thanks.

Tim Beiko:And was Lighthouse the only CL client that had issues after the bug, or…?

Tim Beiko:Were there other… were there other teams with issues?

Barnabas: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:Yeah, I have also reached out to them.

Barnabas:Also, there was quite some, very deep reorgs, and, never mind.

Barnabas:Got stuck in a weird loop for, some client pairs.

Barnabas:But they were also investigating, but they said that it's most likely caused by a debugging Lighthouse.

Tim Beiko:I see.

Tim Beiko:And then, on the EL side, so, Barnabas, you had a,

Tim Beiko:the proposal, at least a summary of the discussion in terms of what to do about the update fraction calculation.

Tim Beiko: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,

Andrew Ashikhmin: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.

Andrew Ashikhmin:Because if we… for, …

Andrew Ashikhmin:go to the current implementation in Nethermind and Wrath and Bezu. The problem is that it's just inconsistent. It uses…

Andrew Ashikhmin: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

Andrew Ashikhmin:Again, it's just, to me, it sounds… Like, well, we, we…

Andrew Ashikhmin:We haven't made any hard fork on a public testnet yet, so we still have time to do it properly.

Andrew Ashikhmin:And, to my mind, like, to do it properly is to make the…

Andrew Ashikhmin:Things, easy on the pro… and, like, consistent on the protocol side.

Andrew Ashikhmin:Rather than prioritize implementation over protocol consistency.

Tim Beiko:Okay, there's some comments by Francesco and LaScience in the chat.

Tim Beiko:Yeah, I don't know if… Anyone else has opinions on this?

Tim Beiko: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.

Tim Beiko:Yeah, dead?

Ben Adams:Yeah, so… The two ways of doing it are using the

Ben Adams:the blob parameters from the current block, or the blob parameters from the parent block. And…

Ben Adams: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

Ben Adams:All the changes to have occurred, so…

Ben Adams:Yeah, it seems better to…

Ben Adams:alter the parameters. Otherwise, we need to change the spec to be parameter-based rather than constant-based.

Tim Beiko:Thanks, Felix.

Felix (Geth):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.

Felix (Geth):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 (Geth):your brother.

Ben Adams:You're both holding the.

Felix (Geth):on the….

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

Felix (Geth):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.

Ben Adams:But, … But, you know, we have to decide one way of doing it.

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

lightclient:Yeah, I just want to say, I feel like, after looking into this a bit more, I also kind of agree with…

lightclient:with Ben, and …

lightclient: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.

lightclient: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…

lightclient:You know, everybody has access to the head block time.

lightclient:… To, to make that change.

lightclient:So, I think it's actually more consistent to…

lightclient:to do what Ben is saying here. The question… that I have is that… Yes, it's an unnatural…

lightclient:It's not a natural block base fee.

lightclient: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.

lightclient: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?

Tim Beiko: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: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.

Mario Vega: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

Mario Vega: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.

Mario Vega: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

Milos: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.

Milos: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

Milos:parent values.

Milos: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

Milos: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…

Milos: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

Milos:do the things, but we can do it one way or the other there as well, so…

Milos: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…

Tim Beiko:Also, yeah, can't use the current block.

Tim Beiko:… Excess blood gas, … So, yes.

Tim Beiko: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 (Geth):I think we should definitely decide it now.

Tim Beiko:Okay.

Felix (Geth):forget.

Felix (Geth):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.

Felix (Geth):very high level here, so… We could… we just take it to a vote, or like…

Felix (Geth):Whatever, but we just… we have to go.

Tim Beiko:So I guess.

Felix (Geth):Yes, it's….

Tim Beiko:what… …

Tim Beiko:Yeah.

Tim Beiko: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.

Tim Beiko:… The current block's parameters, on the fork block.

Tim Beiko: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 (Geth):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.

Tim Beiko:It would be good to have someone who can put a PR up,

Tim Beiko:on the EIP, and ideally the specs or tests today.

Tim Beiko:Or tomorrow? Yeah, Roman, and then Ben?

Roman:Yeah, I think that the fork happened exactly because, like, people treat the…

Roman:the spec differently? Because in my mind, it's already clear that the, …

Roman: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.

Roman:So….

lightclient:The header is the parent header.

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

Roman:And the function uses the constant.

lightclient:I think it's not that clear.

lightclient: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…

Mario Vega: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…

Mario Vega:It's unclear on the specs, maybe it is unclear in the EAB.

Mario Vega: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

Tim Beiko: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,

Mario Vega:Static tests out, by today or tomorrow, yeah.

Tim Beiko:Some links.

Tim Beiko:Ben?

Ben Adams:Should this be, like, an assumed precedent? And if we…

Ben Adams:If it needs to, like, reach into the parent.

Ben Adams:There, then that's, like, the exception.

Ben Adams:We got prior fork parameters.

Ben Adams: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 (Geth):Sorry.

lightclient: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:Probably?

Felix (Geth):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 (Geth):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?

Tim Beiko:That sounds reasonable.

Felix (Geth):I just want to quickly say that, and then I'm gonna… I'll be done. So, the… the…

Felix (Geth):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

Felix (Geth):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.

Felix (Geth):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.

Felix (Geth):I think this is why we're seeing this And…

Felix (Geth):we do have to figure out a way, I think.

Felix (Geth):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.

Felix (Geth):But, … Also, within the EAP, it's maybe pretty important to figure out some way

Felix (Geth):Just making it very clear for all of us.

Felix (Geth):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

Felix (Geth):parameters, which are defined by the fork which is active at block X, but this is…

Felix (Geth):I don't think this was so clear before.

Felix (Geth):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…

Tim Beiko:It feels like these are the types of things where we should have, like, a static reference that we're, you know, high

Tim Beiko:High confidence that the clients,

Tim Beiko:All have the same behavior, so….

Felix (Geth):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.

Felix (Geth):Soon, like, this is not, like, we wouldn't…

Felix (Geth):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.

Andrew Ashikhmin:And, like, in Roman's interpretation, it uses global variables.

Andrew Ashikhmin: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.

Andrew Ashikhmin:It turns out this, getBaseFIPAA blobGas function, it actually doesn't take one parameter, it takes two parameters.

Andrew Ashikhmin: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.

Andrew Ashikhmin: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…

Tim Beiko:try and define these things more explicitly. And yeah, perhaps, like, have a standard with how we,

Tim Beiko:we, treat, like, the different functions of the spec, but, I know we have other things to cover, so…

Tim Beiko:Anything else on this specific issue?

Tim Beiko: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

Mario Vega: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.

Mario Vega: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, …

Mario Vega:Encourage EIP writers to reach out to us.

Mario Vega: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.

Mario Vega: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.

Mario Vega:So, my point is that we have to encourage EIP writers to come to us.

Mario Vega: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, …

Tim Beiko:yeah, it's probably worth it to have, actually, these 11 EIPs chat with the testing team, …

Tim Beiko:Yeah, as we're going into Amsterdam planning.

Tim Beiko: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,

Tim Beiko:Yeah, we can make sure that we're looking at them from the testing perspective.

Tim Beiko:Okay.

Tim Beiko:I'm… Anything else on the DevNet4 issue?

Tim Beiko:Barnabas, you had this other point about the BPO fraction update.

Tim Beiko:Right.

Barnabas:So… we had this proposal, from Anders, saying that we should probably use,

Barnabas:Max and target 3 to 2, properties, and use,

Barnabas:Static, function to calculate the fraction values.

Barnabas: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.

Barnabas: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, …

Ansgar Dietrichs:Physically, …

Ansgar Dietrichs: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.

Ansgar Dietrichs: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

Ansgar Dietrichs: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

Ansgar Dietrichs:Ship something where we are above the…

Ansgar Dietrichs:that ratio. But if there's ever, like, a…

Ansgar Dietrichs: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?

Tim Beiko:Thoughts on this?

stokes:So it sounds like we want to generally have this as, like, a, you know.

stokes:Design… well, not design goal, but something we aim for, but still retain the flexibility, in case we need to change it later.

stokes:I believe that's what Barnas was asking for, is just if we could agree to this, like, you know, this structure.

stokes:These relative ratios and everything.

Barnabas: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?

Marius van der Wijden:Was that formula?

Barnabas: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.

Barnabas:On the fly. So, like, we're not gonna be using, like, random, BPO values anymore.

Barnabas: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…

Ansgar Dietrichs: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.

Ansgar Dietrichs: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

Ansgar Dietrichs: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

Potuz: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.

Potuz: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.

stokes:Yeah, I think we agree on that point. So…

stokes: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…

stokes: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.

stokes: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…

Tim Beiko: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.

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

Tim Beiko:Yeah.

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.

stokes: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:I mean, I wouldn't pick values that have never been tested, so, like.

Barnabas:Ideally, we want to be testing the values that we're gonna be using in mainnet.

Barnabas: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

Barnabas:a few BPOs, at least, for sure.

Barnabas:then I would say that we're going to be using this base 3 update fraction as well.

Barnabas: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.

Tim Beiko:how to best support this in testing, either async or on ACDT, …

Tim Beiko:But yeah, want to be mindful of time here.

Tim Beiko:I guess, anything else on the DevNet4 BPO activations?

Tim Beiko:If not, next step…

Tim Beiko: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,

Tim Beiko:Mostly the ones that raise his concerns. …

Tim Beiko:Proposing that, we have the client releases for the first, testnet,

Tim Beiko:for the first, testnet on… the first two testnets, sorry, on September 8th, so we would have Sepolia and Holeshki releases then.

Tim Beiko:And then, for Koleshki on September 15, then for Acepolia on September 29th, and then on…

Tim Beiko: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,

Tim Beiko:A clean, … yeah, like, a clean fork.

Tim Beiko:I'm…

Tim Beiko:And so in the chat, Pauline said Lighthouse has concerns with this, given, yeah, we haven't figured out the sync issues yet.

Tim Beiko:Yeah. Any other… Thoughts or comments? Yeah, Alex?

stokes:Yeah, maybe I'll just rock… walk through these dates for a little more context. So…

stokes: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.

stokes: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, …

stokes:You know, it's not having formal releases.

stokes: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.

stokes:We'd start the bug bounty, so yeah, ideally, there's just a pulley release on the 8th.

stokes: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.

stokes:Or at least the proposal.

stokes: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.

stokes:Again, as we see, things are kind of day by day on the status, …

stokes:But yeah, so… yeah, I hear porn here on the Lighthouse thing, makes sense.

stokes:And otherwise, yeah, I'd be curious what other… Clients feel about this. …

stokes: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.

Tim Beiko:Matt?

lightclient: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…

lightclient:All of the clients are doing the right computation for one of the EIPs at the fork boundary.

lightclient:And… You know, we're getting close to having that stuff, but…

lightclient: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…

lightclient: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,

Tim Beiko: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…

Tim Beiko:should we wait to have, like, kind of a clean DevNet and then set a date? ….

lightclient:Yeah, I mean, in the past, it's kind of how we've done it, right? Like, once we see a good DevNet.

lightclient: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…

lightclient: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…

lightclient: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.

Ben Adams:… And, potential delay from that? Was that…

Ben Adams: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.

Tim Beiko:I believe.

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

stokes:Yeah, my understanding is that, people have kind of put in quite a bit of a lift, to resolve that.

stokes:So… Yeah.

stokes:…

stokes: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?

Tim Beiko:and obviously the fix is on the CL side in terms of syncing, but there would be…

Tim Beiko:No other changes.

Barnabas:Yep, so basically we want to make sure, I think we're gonna be running another big…

Barnabas:Devnot. And we're gonna need to make sure that,

Barnabas:all the BPO changes are working as expected, and without any extra noise.

Barnabas: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.

Tim Beiko:Adrian?

Tim Beiko:We can't hear you, Adrian.

Tim Beiko:Oh.

Tim Beiko:Okay, so… In terms of, …

Tim Beiko:moving forward with a dead net 5, I assume we'd want it, you know, at the earliest next week. …

Tim Beiko:The blockers would be… Effectively, the Lighthouse issue, the Nimbus issue, and then

Tim Beiko:making sure that all the clients pass some static tests, on the EL side, in terms of calculating these, these blob parameter values.

Tim Beiko:Anything else?

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

Saulius Grigaitis | Grandine:Yeah, so for them at 5, I would suggest to increase a share of minority clients, so…

Saulius Grigaitis | Grandine: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.

Saulius Grigaitis | Grandine:So that's for DevNet File.

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

Saulius Grigaitis | Grandine: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…

Saulius Grigaitis | Grandine:To get, fast, a good response of what is wrong with our clients.

Saulius Grigaitis | Grandine: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.

Tim Beiko: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? …

Tim Beiko:I don't know, Barnabas, if you have opinions now, otherwise we can discuss this on the second call.

Barnabas:We use the clientdiversity.org numbers in order to determine how many

Barnabas:validators each TL and EL should have. These are approximations, but these are the best we have.

Barnabas: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.

Tim Beiko:5% of breath, or something like that, so we get more data, or… Yeah.

Barnabas: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.

Barnabas:And the same way as, for RAS and Aragon, we can increase those as well, and remove, some gas and other minor nodes.

Barnabas: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.

Tim Beiko:We should make sure that the DevNets mimic that, but then within these, like, bounds of, you know, how much we need to finalize.

Tim Beiko:like, we… I think we can have some… some flexibility. …

Tim Beiko:Okay, …

Tim Beiko: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.

Tim Beiko: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.

Tim Beiko:And yeah, test all the fixes, see how we're feeling about,

Tim Beiko:Yeah, about the fork, and discuss state stem, if appropriate.

Tim Beiko:Okay, anything else on Fusaka?

Tim Beiko:Okay, …

Tim Beiko: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.

Tim Beiko: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,

Tim Beiko:I think there's been, like, some…

Tim Beiko:I don't know, potentially, like, lack of clarity between,

Tim Beiko: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

Tim Beiko: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? …

Tim Beiko:Yeah, not to say that we shouldn't do either of those, but wanted to at least raise it.

Tim Beiko:Any concerns, thoughts? Otherwise, I think we just move forward with block access lists and EPVS.

Tim Beiko: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.

Tim Beiko:I think, one thing that would be helpful to discuss Now is,

Tim Beiko: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

Tim Beiko: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…

Tim Beiko:Target we'd want to aim for, and how do we… How do we, like, Yeah, roughly…

Tim Beiko:go towards that. … My proposal would be that we should be fairly strict in terms of just,

Tim Beiko:getting EPBS and block access lists implemented and fairly far along before we consider other things.

Tim Beiko:But yes, curious how other people feel about that, and how they think we should approach the process.

Tim Beiko:And yeah, to Totas' point, setting your timeline target, would make scoping easier, and yeah, OnScar.

Tim Beiko:has this, rough timeline around, like, okay, should we try to aim for June for releases? …

Tim Beiko: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.

Tim Beiko:You know, how does that affect our scope?

Tim Beiko:I guess, yeah, maybe it's a good point to start. Does anyone think we should not try to at least

Tim Beiko:roughly target June for a hard fork.

Tim Beiko:…

Tim Beiko: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.

Tim Beiko:Yeah, Ben?

Ben Adams:I think, …

Ben Adams: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.

Ben Adams:Because you only have to wait

Ben Adams:you know, 6 months. It's not, like, a year plus.

Ben Adams:So, hopefully the small forks can be smaller.

Ben Adams:Although, that didn't really happen before.

Tim Beiko:I'm… There's a question about, like, can we get some…

Tim Beiko:commitment to fossil if it doesn't delay the fork by more than n months.

Tim Beiko: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.

Tim Beiko:…

Tim Beiko:I think it's very hard… if we commit to doing, like, fossil or anything else significant now, the code kind of gets intertwined, …

Tim Beiko:So, like, yeah, I would strongly prefer, like, we…

Tim Beiko:We make a call once we're…

Tim Beiko: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

Tim Beiko: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

Tim Beiko:adding something.

Tim Beiko:Yeah.

Tim Beiko:Draw?

soispoke:Yeah, no, I… I mean, I think I agree, but just…

soispoke:Still, it's a bit of a hard thing to wrap my head around, because having this sort of, like, conditional inclusion

soispoke: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.

soispoke:And I do want to…

soispoke:insist that it was, like, basically the most supported EIP, by the community. It was, like, 14 out of, like, 21.

soispoke:I guess, like, suggestions, … And… yeah, so I'm just saying, like.

soispoke: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

soispoke: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…

Tim Beiko: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.

Tim Beiko: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.

Tim Beiko: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,

Tim Beiko:And then making the call to implement fossil NEX, if we think we have the capacity for it.

Tim Beiko:Mark?

ethDreamer (Mark):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…

ethDreamer (Mark):basically, … finished developing the EIPs slated for the fork, and that…

ethDreamer (Mark):you know, that it might be possible that the EL is ready sooner, and if that were the case, then possibly decoupling these forks, …

ethDreamer (Mark):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

ethDreamer (Mark):take longer anyway, then it would make sense to leave fossil out of that fork, but then do it in the next…

ethDreamer (Mark):fork, which will come at the same time as EPBS, …

ethDreamer (Mark):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…

Tim Beiko:Less true as we move farther with the testing, but, …

Tim Beiko:It's definitely easier to split things if there's no cross-layer, feature, yeah.

Tim Beiko: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

Potuz:to try to arrange, not here, but probably ACDT, or even, like, informally with PandaOps.

Potuz: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.

Potuz: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.

Potuz: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…

Tim Beiko:Also, including block access lists, …

Tim Beiko:And then, yes, once we have this clamster down .NET1, we can determine what we want to add on top of it.

Tim Beiko:Yeah. Karen's?

terence: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.

terence: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.

terence:to get EPBS in some fundamental stage, and then add Fossil on top.

Tim Beiko:Okay, so I think…

Tim Beiko:That all makes sense, so we move forward with EPBS and block access lists being SFI'd, get DevNets with those, and…

Tim Beiko:and then make decisions about, SFI and the other things. We do fossil, CFI'd for now. …

Tim Beiko:We also had this 6-second slot

Tim Beiko: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.

Tim Beiko:And then, …

Tim Beiko: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.

Tim Beiko:My, yeah, my suggestion would be

Tim Beiko: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.

Tim Beiko:Does that seem reasonable?

stokes:I think so.

Tim Beiko:Yep.

Tim Beiko:Okay.

Tim Beiko:… Okay, so… Yeah, we confirmed the headliners, we're gonna remove, the 6-second slots proposal.

Tim Beiko: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,

Tim Beiko:Yeah, not have to, review them by then.

Tim Beiko:…

Tim Beiko:Okay, on… …

Tim Beiko: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.

Toni Wahrstätter:…

Toni Wahrstätter:Right.

Toni Wahrstätter: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.

Toni Wahrstätter:Essentially, the three points are…

Toni Wahrstätter: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.

Toni Wahrstätter:The second point is RLP versus SSC, and the last thing is how to handle system contracts, because Jared brought it up in the…

Toni Wahrstätter: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.

Toni Wahrstätter: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.

Toni Wahrstätter:And the question is, would clients actually use it?

Toni Wahrstätter:Or would going, parallelizing transactions, and in this way also doing somehow parallel discrete, would that be already enough?

Toni Wahrstätter: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,

Toni Wahrstätter:People working in auditing, and they said it might be useful to know, exactly in which transactions, which contracts were touched.

Toni Wahrstätter: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.

Toni Wahrstätter:So, of course, this is, like, the problem. It adds quite significant size, and I would be curious what EL clients think about

Toni Wahrstätter:Yeah.

Toni Wahrstätter: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…

Jared Wasinger: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…

Jared Wasinger:… Yeah, so like, like I've said before.

Jared Wasinger:The more we parallelize the transaction throughput, the less this, including these, gives us.

Jared Wasinger:So… There we go.

Karim T.:I, I think also, having this state location.

Karim T.:will not only help to have parallel batch I.O, but it will also help to do real parallelization, so…

Karim T.: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…

Karim T.: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

Potuz: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

Potuz: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.

Potuz: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.

Toni Wahrstätter: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…

Toni Wahrstätter: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.

Jared Wasinger:… I think, I think it's, I think it's trivial to keep them in.

Jared Wasinger:As far as the complexity goes.

Toni Wahrstätter:Okay, yeah.

Toni Wahrstätter: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.

Toni Wahrstätter:There were some use cases brought up where SSS might be useful. The thing is.

Toni Wahrstätter:Oh, someone is drawing, or it wasn't me? The thing is, RLP is smaller. I mean, this is, like.

Toni Wahrstätter: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.

Toni Wahrstätter:Or if we kind of want to further postpone that.

Toni Wahrstätter: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 (Besu):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…

Justin Florentine (Besu):you know, always avoid it. We always kick the can down the road. I think there's good reason for that.

Justin Florentine (Besu):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.

Justin Florentine (Besu):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.

Justin Florentine (Besu):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, …

Justin Florentine (Besu):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: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.

Guillaume: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

Guillaume: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.

Guillaume: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.

Toni Wahrstätter: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: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.

Toni Wahrstätter:I guess introducing stable containers here would be, not worth it.

Toni Wahrstätter:But… yeah, so it's not super trivial to just add a new field.

Toni Wahrstätter:Yeah, it feels like right now, ….

Dustin:I… I….

Toni Wahrstätter:molded.

Dustin:I have a….

Toni Wahrstätter:Not gone. No gone.

Dustin:I have a question about the Go SSC. SA has a structural point about this. So, …

Dustin:specifically the GoSSC library, thing. Putting aside some of the…

Dustin:snarkier comments or whatever, and, you know, the discussion, or including them, either way in the chat, but the idea of

Dustin:this… …

Dustin:concern, objection, I don't know, has been raised from the beginning, and there's a sort of a…

Dustin:a circularity to it. It's that…

Dustin: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

Dustin: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…

Dustin: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…

Dustin:essentially a way of just deciding not to do it by refusing to implement a quote-unquote good GoSSE library, or,

Dustin: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:foot.

Tim Beiko:I'm not a Go expert, but my perspective on SSD from someone who has

Tim Beiko:zero skin in the game, I don't maintain the client, is, …

Tim Beiko:It sounds like the type of thing we always say we want to do, but then the revealed preference is we…

Tim Beiko:don't actually prioritize it, because there's higher impact things that we agree to do in the protocol. My…

Tim Beiko:Personal preference at this point is, like, we should…

Tim Beiko: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.

Tim Beiko:like, you know, there's not much incremental damage in a way, and I… Yeah, my sense is, like.

Tim Beiko: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

Tim Beiko: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.

Tim Beiko: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,

Tim Beiko: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…

Tim Beiko:consensus-critical part of the clients. …

Tim Beiko: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…

Tim Beiko:Yeah, I… I feel like it's probably better if we just assume that EL is in RLP, but, …

Tim Beiko:Yeah, go to that, or Sig, Guillaume, and Tony?

Guillaume: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.

Guillaume:They come up with a lot of, …

Guillaume: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…

Guillaume: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.

Guillaume:So…

Guillaume: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.

Guillaume:We… yeah, we don't know how to handle that efficiently.

Toni Wahrstätter:Yup.

Toni Wahrstätter:Yeah, thanks for the input, …

Toni Wahrstätter: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…

Toni Wahrstätter: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.

Toni Wahrstätter:But let… R2SSC, but let's keep it, for RLP.

Toni Wahrstätter:For now.

Toni Wahrstätter:And the last thing that will be a very quick thing, it's basically, there was a discussion around how to handle system calls.

Toni Wahrstätter: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.

Toni Wahrstätter: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.

Toni Wahrstätter: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.

Toni Wahrstätter:And then the proposal would be to encode those state changes into the block club access lists by doing…

Toni Wahrstätter: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.

Toni Wahrstätter: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.

Toni Wahrstätter:Yeah, I think… I'm not sure, Jared, if you, …

Toni Wahrstätter: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…

Jared Wasinger:I think that's really what is…

Jared Wasinger:Important for simplifying the client implementation.

Jared Wasinger:So my preference, which I've stated before on the Discord, is that the index in the… in the… in the access list should

Jared Wasinger: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.

Jared Wasinger:So essentially, like, what I would…

Jared Wasinger:prefer is that the index 0 be the… the pre-execution

Jared Wasinger:And then proceeding, … and then after that, the transactions, and then the last index would be any post…

Jared Wasinger:state changes. And so I think that your pushback against this has been that this does not…

Jared Wasinger:So this would mean that the index of the BAL state changes does not… for transactions, doesn't reflect

Jared Wasinger:Their zero… their index within the block.

Jared Wasinger:… And I would say that…

Jared Wasinger:From the implementation perspective, this is, …

Jared Wasinger: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.

Toni Wahrstätter: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.

Toni Wahrstätter:Transaction Index 1 in the block level access list is actually…

Toni Wahrstätter: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…

Jared Wasinger: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…

Jared Wasinger:some of the bigger ones aren't really… I mean, it's hard to manually parse through these, right? Like…

Jared Wasinger:I don't think that users…

Jared Wasinger: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.

Andrew Ashikhmin:Orderly, so 0 corresponds to the pre, like.

Andrew Ashikhmin:Beginning of the block, and …

Andrew Ashikhmin:Yeah, the last one corresponds to the end of the block. Otherwise, I think if they are not ordered, it will be very confusing.

Andrew Ashikhmin:for developers, I think… Like, having them ordered will be less confusing to the user, because if… even, like.

Andrew Ashikhmin:Like, otherwise they say… they see, oh, okay, there are two extra transactions, like, transactions at the end, what does it mean?

Andrew Ashikhmin: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…

Roman:call this index the State Transition Index in the AP itself, and then go with the…

Roman:with what Jared said were… Like, all of the items are in their chronological order.

Roman:And the block level access.

Som - Erigon:I would suggest, keeping it different from the transactions list, and… Perhaps, arranging it in

Som - Erigon:A separate section, because they are not actual transactions.

Som - Erigon:I think that's the most confusing thing, to mingle it with.

Som - Erigon:The transactions, because… they're not going to go through EVM in some cases, and are applied

Som - Erigon:Sort of in a different fashion.

Som - Erigon:So, there is… if there were to be benefits of parallelization, on those, …

Som - Erigon:I firstly doubt there would be, but if there were, I think they're going to be processed.

Som - Erigon:Differently, so it doesn't harm to…

Som - Erigon:Just have a system contract section in the list, and, like.

Som - Erigon:Put your, transactions order, over there.

Som - Erigon:And, it would be up to client teams to figure out what to do with this.

Som - Erigon:If they want to warm it up, before, they're free to do it.

Som - Erigon:Or if they want to go in how it is right now, which is just, let the transactions happen, and then

Som - Erigon:Apply, the system contracts.

Som - Erigon: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.

Som - Erigon: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

Toni Wahrstätter: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

Toni Wahrstätter:one additional transaction for the post state, and instead shift every transaction index by one, and

Toni Wahrstätter:I have, the pre… the pre-execution changes, as transaction index 0.

Toni Wahrstätter: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, …

Toni Wahrstätter:block level access list index, or something.

Jared Wasinger:Yeah, sure.

Tim Beiko:We can, by check the name, I think, … But yeah.

Tim Beiko:Oh, Marius is saying, yeah, there should be a block access list breakout,

Tim Beiko: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.

Tim Beiko: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

Tim Beiko:Get to them. …

Tim Beiko: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.

Tim Beiko: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.

Mikhail Kalinin:Yeah, and then we can move to a singing discussion. So, yeah, we have, … …

Mikhail Kalinin: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

Mikhail Kalinin: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

Mikhail Kalinin: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.

Mikhail Kalinin: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

Mikhail Kalinin:basically rely on that safe block means justified. And yeah, that might impact them.

Mikhail Kalinin: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

Mikhail Kalinin: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.

Mikhail Kalinin:Because the basically safe block, semantics will depend on, on the node operator and on the, node's configuration, which might be a…

Mikhail Kalinin:prone to misconfiguration and other things, so, yeah. But if you're a

Mikhail Kalinin: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.

Tim Beiko:But yeah. Thanks, everyone.

stokes:Thank you.

Toni Wahrstätter:Me too.

Potuz:Hi, thank you.

Fredrik:Thanks, Mike.

Marius van der Wijden:Okay, thanks, bud.

ethDreamer (Mark):Hey, guys.

Chat Logs

Marius van der Wijden:How far away are we from a fixed LH image?

FLCL:yep Nethermind can't handle such reorgs, need resync ig

Tim Beiko:BASE_FEE_UPDATE_FRACTION = round((MAX_BLOBS * GAS_PER_BLOB) / (2 * math.log(1.125))) use max/target fractions that are exactly 3/2

Barnabas:Replying to "BASE_FEE_UPDATE_FRAC..." thats a different discussion

Francesco:Just speaking strictly from the perspective of the 7918 check, this inconsistency doesn’t matter (it’s not important whether the reserve price used is the base fee of an actual block)

lightclient:can 7918 use the current block’s excess blob gas field?

Anders Elowsson:Yes. The effect is very minimal. And most of the time there will be no difference.

Felix (Geth):Replying to "can 7918 use the c..." no because this is a part of the excess computation itself?

lightclient:i feel like we should use the current block instead of parent block then? is anyone against that?

Ansgar Dietrichs:Sorry is the question whether the floor calculation should use the fee schedule of current or parent block?

Anders Elowsson:No sorry. I meant the effect of doing it the two different ways that led to a fork

stokes:Replying to "Sorry is the questio..." yes

Anders Elowsson:Replying to "Sorry is the questio..." It can use the update fraction of either. There will be no issues

Francesco:Like Felix said, we can’t do that because the 7918 computation is how you compute the excess blob gas

Tim Beiko:Replying to "Like Felix said, we ..." Can’t do what sorry? Using the current block?

Anders Elowsson:Replying to "Like Felix said, we ..." Yes

Francesco:Replying to "Like Felix said, we ..." Using current block’s excess blob gas

Ansgar Dietrichs:I really think we should use the latest parameters, but there is no reason to care about whether that’s a "natural basefee", that’s a meaningless concept

Anders Elowsson:Replying to "Like Felix said, we ..." The calculation of the excess_gas is determined by the if statement

Francesco:Replying to "Like Felix said, we ..." It’s fine to use the current block’s update fraction

lightclient:Replying to "Like Felix said, we ..." i see

lightclient:Replying to "Like Felix said, we ..." okay well i suppose we will have 1 weird block where the base fee computed by 7918 doesnt match any known blob base fee

Barnabas:we need to align today

Ansgar Dietrichs:Yes it seems super silly

lightclient:let’s just use the current block’s fork parameters?

stokes:Use current?

Francesco:In this case it’s fine either way, but fwiw the consensus-specs have a get_blob_parameters function that takes epoch as an input and can access the whole schedule. Regardless of what we decide now, I could see it being useful in the future for the execution-specs to have this ability as well

spencer-tb:Replying to "let’s just use the c..." Parent.max, parent.target & current.update? Or current all?

lightclient:Replying to "let’s just use the c..." current for all

lightclient:Replying to "let’s just use the c..." it’s already current for max / target yeah?

lightclient:Replying to "let’s just use the c..." we’re only debating the update fraction?

Ansgar Dietrichs:It should not be specified in 7918 though, but in the BPO EIP

draganrakita:It will not hurt to add clarification to EIP

Francesco:Replying to "It should not be spe..." I am not sure about this, you could imagine wanting to do something different in a different case (e.g. you actually want the parent’s basefee for something else)

Francesco:+1 on it not being clear

Ansgar Dietrichs:I don’t think it’s clear right now, I think geth’s interpretation was valid

Anders Elowsson:We can fix it today

Anders Elowsson:One of the authors, we will add a clarification, if this is the decision

Ansgar Dietrichs:Replying to "It should not be spe…" Yes the BPO EIP should explicitly specify how this affects each part of the protocol that uses any of the values being changed

Francesco:Replying to "It should not be spe..." And be modified every time something new comes up?

Roman:Replying to "I don’t think it’s c..." i agree that interpretation is valid

Roman:Replying to "I don’t think it’s c..." i think it comes from how original calculation was implemented

Ansgar Dietrichs:No the precedent is that it needs to always be explicitly specified. Precedent shouldn’t be to start assuming spec behavior implicitly

Mario Vega:If you need to do parentHeader.value that’s ok, if you need to do parentHeader.fork.value that seems unnatural to me IMO

Csaba Kiraly:I also think it was not clear … and we even have empirical proof now. So it is better specified explicitly.

FLCL:Replying to "If you need to do p..." or ` fork(parentHeader).value`

Marius van der Wijden:How will blobbasefee work now?

lightclient:Replying to "How will blobbasefee..." should be unchanged?

lightclient:Replying to "How will blobbasefee..." use the current header’s fork config and excess when computing

Ben Adams:Replying to "No the precedent is ..." gas repricing, do we use prior blocks prices as that's where estimate_gas would have been done on? ;)

ethDreamer (Mark):We are so spoiled on the consensus side with the spec lol

Anders Elowsson:It essentially comes down to `get_base_fee_per_blob_gas ` referring the `BLOB_BASE_FEE_UPDATE_FRACTION ` without referring to the parent.. In Roman’s interpretation

draganrakita:modexp when base/mod is zero was a similar issue, reth/base assumed min gas is spend as no calculation is done, and geth/nethermind would add additional gas depending on exp.

Csaba Kiraly:+1 on pure functions as the longer term solution.

Roman:Replying to "It essentially comes..." this interpretation stems from EIP-7691 which says The value BLOB_BASE_FEE_UPDATE_FRACTION_PRAGUE replaces its previous equivalent when processing the activation block. These changes imply that get_base_fee_per_blob_gas and calc_excess_blob_gas functions defined in EIP-4844 use the new values for the first block of the fork (and for all subsequent blocks).

Anders Elowsson:Replying to "It essentially comes..." Yep. So it is very consistent with the spec in this regard.

Ansgar Dietrichs:I think that was not the case here though, right?

lightclient:I think we should also encourage client teams to contributing to testing

FLCL:TFIed

draganrakita:EIP versioning and changelog of changes would help 🙂

lightclient:Replying to "I think we should al..." i definitely am at fault for this too where i will just implement the spec as i understand it, do some basic testing, then expect the testing team will do a lot of the heavy lifting

Ansgar Dietrichs:I think such process questions should be discussed async though. But agree on value of having testing earlier in the loop

lightclient:Replying to "I think we should al..." i think this is becoming a pretty common mode of operation

stokes:Im assuming we don’t need to chat about the CL side of things at all

stokes:(Just to pipeline a bit)

Tim Beiko:Replying to "Im assuming we don’t..." The

Tim Beiko:Replying to "Im assuming we don’t..." CL sync issues?

stokes:Replying to "Im assuming we don’t..." Yea w/ LH

stokes:Replying to "Im assuming we don’t..." Also may have missed in the very first minutes of call

Tim Beiko:Replying to "Im assuming we don’t..." Pawan said they were working on a fix, but IDK if there are more updates?

stokes:Replying to "Im assuming we don’t..." Yeah, just asking

raxhvl:We're experimenting a format for BAL test cases before we implement them here: https://github.com/ethereum/execution-spec-tests/blob/feat/eip-7928/checklist/tests/unscheduled/eip7928_block_level_access_lists/checklist.md

danceratopz:Replying to "EIP versioning and c..." Appreciate the input.

Adrian (Lighthouse):Replying to "Im assuming we don’t..." its not spec related, just internal issues, not sure its useful to discuss

Potuz:I would rather have more flexibility and the sticking to 3/2 can be offchain without making it to consensus nor clients

Toni Wahrstätter:this depends a bit if we want to stay with that ratio

Anders Elowsson:https://discord.com/channels/595666850260713488/1402683134406955008/1403433219185053716

Barnabas:formula: BASE_FEE_UPDATE_FRACTION = round((MAX_BLOBS * GAS_PER_BLOB) / (2 * math.log(1.125)))

Marius van der Wijden:Replying to "I would rather hav..." yes

stokes:Replying to "I would rather have ..." It can be informal but could be nice to have an agreement here

stokes:Replying to "I would rather have ..." “Social layer"

pawan:Replying to "Im assuming we don’t..." Yeah basically that, We need time to figure out the sync issues and sync reliably

Marius van der Wijden:Replying to "I would rather hav..." yes social agreement, not enforced in code

stokes:Replying to "I would rather have ..." yep

Potuz:Replying to "I would rather have ..." exactly my point yues

Csaba Kiraly:Replying to "I would rather have ..." +1

Ansgar Dietrichs:Like pragmatically 2:3 is reasonable, but not sure what we gain from precommitting to that

Anders Elowsson:The point of this formula is BASE_FEE_UPDATE_FRACTION = round((MAX_BLOBS * GAS_PER_BLOB) / (2 * math.log(1.125))) Is that it is general. It works for any ratio

Csaba Kiraly:Replying to "I would rather have ..." I don’t think we have a good justification for the ratio at the moment, hence fixing it would be premature.

Francesco:What is the benefit?

Anders Elowsson:Replying to "The point of this fo..." It generalizes both 4844 and 7691

stokes:Replying to "What is the benefit?" Simpler to orchestrate devnets etc

stokes:I think we can say we generally follow this pattern, but reserve the right to deviate

Anders Elowsson:The formula is a generalization!

stokes:Yeah +1 to ansgar

Anders Elowsson:What is the formula you are discussing right now?

Csaba Kiraly:I would say it is a dimension we had no time to explore yet fully, or to understand how it changes system properties.

Barnabas:enshrined in testing

pk910:the question comes from the genesis generator. we need the value there and have been statically setting it there. we've switched to the formula by default now, but it can be overridden via custom params

Ansgar Dietrichs:We can consider enshrining it, but then we should do that as a function of the target and max, and choose what behavior it should have for different ratios

Ansgar Dietrichs:Replying to "We can consider ensh…" And that’s not trivial to do

Anders Elowsson:Hi can someone answer. What formula are we discussing?

Potuz:Anders I think there has been a confusion between your proposal and Barnabas since your proposal would accept any ratio

Csaba Kiraly:As usual, we could do test where we just explore this dimension. However, we don’t need to this, because we are in control of this parameter.

stokes:Replying to "Hi can someone answe..." Can we rely on this invariant that max : target is 3:2

stokes:Replying to "Hi can someone answe..." And if so that gives us a formula to compute the base fee update fraction as well

Ansgar Dietrichs:I think it’s fine to exclusively use that for testing. No need to test things we won’t actually do

Anders Elowsson:Replying to "Hi can someone answe..." The formula that was specified in the discussion was for any ratio, it will not matter. But yeah, the exact ratio might be changed after Fusaka

Csaba Kiraly:BTW, I think we will change this later on. It is just not at the level of optimizations we need now.

stokes:Let me try to paste here

stokes:8th Sep: client releases for sepolia (and holesky if needed); bug bounty begins 15th Sep: Holesky fork (can provide branch, no releases needed) 29th Sep: Sepolia fork 1st Oct: Hoodi and mainnet releases 8th Oct: Hoodi fork 5th Nov: Mainnet

Ansgar Dietrichs:Replying to "Hi can someone answe…" Oh I see, I wasn’t aware

Anders Elowsson:Replying to "Hi can someone answe..." It’s a generalisation of 4844 and 7691

pawan:Replying to "8th Sep: client rele..." We are not comfortable with this timeline at least until we figure out and fix our sync issues

stokes:Replying to "8th Sep: client rele..." roger

Dustin:the Holesky fork is explicitly specified in Alex's comment about not necessarily being a regular release

Anders Elowsson:Replying to "Hi can someone answe..." It will give satisfactory output for the update_fraction whatever ratio we input

Dustin:contra Tim's summary

Tim Beiko:Replying to "contra Tim's summary" Sorry yes, good catch

Tim Beiko:Is there a big overhead to making proper releases?

Anders Elowsson:I think Barnabas just reposted mine? Or does “formula” specifically refer to 3:2 ratio. That’s not a formulae that’s a ratio

Ansgar Dietrichs:Replying to "Hi can someone answe…" Interesting. I do think that can be a good idea. I don’t think there is a rush to enshrine this though

stokes:Replying to "Is there a big overh..." I think not so much, but the process of getting there can be bigger

Potuz:Replying to "Anders I think there..." I think Barnabas posted your formula but stated specificallty the 2/3 ratio which is what prompted our rage

Justin Florentine (Besu):do we need a Devnet 5 or no?

Dustin:testing/confidence in stability/etc. it's not just how hard it is to press the button

kingy_sigp:Replying to "8th Sep: client rele..." We were tracking fine until the sync issues. As soon as we iron those out we would be better able to set a firm date.

Phil Ngo:Likewise still dealing with handling forky conditions discovered with devnet-4 non-finality which is really good

Ansgar Dietrichs:Replying to "Anders I think there…" Ah yes it confused me at least, then I think my comments were not fully applicable actually

Marius van der Wijden:I think that depends on if devnet-4 is resurrected cleanly

Anders Elowsson:Replying to "Anders I think there..." We do not need to enshrine 3:2, but it is rather likely that we will wish to use this formula. For sure we might change it but it is a very general way to approach the whole system. And having this as a agreed-upon formula can therefore be very useful

Barnabas:I have a feeling that we gonna need devnet-5

Francesco:What is going to happen to devnet-4? Is it going to continue past Friday if it is resurrected?

ethDreamer (Mark):Need to keep the focus and urgency on Fusaka but at the same time we’re not gonna ship something broken

Francesco:And if there is a devnet-5, will it be as big as devnet-4?

ethDreamer (Mark):Treat every devnet like it’s your last 😂

Anders Elowsson:Replying to "Hi can someone answe..." Perhaps I would say, it can can be useful to have it as a default going forward, but we can still be open to changing it.

Ansgar Dietrichs:Dumb question, if we have to delay for an extra week, would a mainnet fork during devconnect be a dumb idea? Given that devconnect this year will be so light on protocol/ infrastructure events, and many core devs won’t even be there.

pawan:Replying to "What is going to hap..." We want to keep it around, its super valuable for testing the sync scenarios

Barnabas:Replying to "Dumb question, if we..." yes

James He:We still have a good amount of stuff to get done I think, we might be able to make it but it’s going to be very close I think

Adrian (Lighthouse):sprry

Csaba Kiraly:Replying to "Anders I think there..." Ah, that’s confusing. Can you paste a link to the formula?

Adrian (Lighthouse):let me fix mic

stokes:Replying to "Dumb question, if we..." Its possible but we have learned w/ pectra to not schedule forks during events

Anders Elowsson:Replying to "Anders I think there..." https://discord.com/channels/595666850260713488/1402683134406955008/1403433219185053716

Anders Elowsson:Replying to "Anders I think there..." `BASE_FEE_UPDATE_FRACTION = round((MAX_BLOBS * GAS_PER_BLOB) / (2 * math.log(1.125)))`

Ansgar Dietrichs:Replying to "Dumb question, if we…" Right. I meant more it looks like devconnect really isn’t much of a core dev event this year anyway

stokes:Replying to "Dumb question, if we..." Yeah, that’s where the idea is more reasonable

Ansgar Dietrichs:Replying to "Dumb question, if we…" But still, fair point. Just wanted to check

J Sunnyside Labs:Replying to "And if there is a de..." Sunnyside Labs will be also launching as big as devnet-4

stokes:Replying to "Dumb question, if we..." But still, I at least have PTSD from pectra 😅

Anders Elowsson:Replying to "Anders I think there..." @Csaba Kiraly it’s just a generalisation of what we have done every fork from the beginning, without expressing it mathematically

Ansgar Dietrichs:Replying to "Hi can someone answe…" Right, but that doesn’t motivate enshrining it into protocol logic, with all the overhead that comes with

Ansgar Dietrichs:Replying to "Hi can someone answe…" It was presented as a proposal for enshrining, not just as a standard for defaults going forward

Barnabas:we used https://clientdiversity.org

Anders Elowsson:Replying to "Hi can someone answe..." Sure, it seems reasonable to wait a bit

Marius van der Wijden:Replying to "Dumb question, if ..." We would like to have people update their nodes if anything goes really wrong, so having everyone in person, away from their nodes is a bit yank imo

Marius van der Wijden:Can you just allocate keys to them and let the teams run their own nodes?

Potuz:I think for staking those sites have bad data, for full nodes it may be fine

Potuz:I think relays will have better data on staking nodes

Barnabas:Replying to "Can you just allocat..." too much coordination overhead

Minhyuk Kim:Sunnyside has been also running more non-validating nodes for minor clients as well - like 5-6 nodes per client combination

Barnabas:Replying to "I think for staking ..." again, they are not perfect, but its the best we have available today

Barnabas:Replying to "I think relays will ..." if you have better sources of this, then feel free to share, happy to take a look

stokes:Sounds good to me

DA | Flashbots:Replying to "I think relays will ..." We see 38% of registered validators using lighthouse, 27% prysm. But 12% as vouch that don’t get CL user agents from.

DA | Flashbots:Replying to "I think relays will ..." That should cover 90%+ of validators

Ben Adams:Block Level Access Lists has a good website for an EIP https://blockaccesslist.xyz/

Ansgar Dietrichs:BALs 🎉 BALs 🎉BALs

Justin Florentine (Besu):BALs + FOCIL lfg

Ansgar Dietrichs:But I do think the most important will be repricings. But that will be more a basket of EIPs, doesn’t make for a good headliner

stokes:Just FYI: https://github.com/ethereum/EIPs/pull/10117

Mario Vega:Replying to "But I do think the m..." Could someone that is championing gas repricing EIPs reach out to the testing team so we can coordinate pls?

Ben Adams:Replying to "But I do think the m..." Do they take effect based on parent block or current block 😉

Potuz:setting a timeline target will really help in making it easier to agree on the scope. However I suspect that agreeing on the timeline may be equal to agreeing on focil inclusion

Ansgar Dietrichs:In terms of fork delivery, I think we should aim for Mar - Interop Apr - releases Jun - mainnet

soispoke:I’d love to have a discussion around committing to including FOCIL if it doesn’t delay the fork by N months So people don’t have to deal with two branch logistics and having a feature that is "not fully committed" to the fork.

lightclient:what is the status of the hardening effort?

DA | Flashbots:Replying to "I think relays will ..." So it’s very likely 70%+

terence:Replying to "I think relays will ..." interesting, 12% as vouch feels a lot

Potuz:Replying to "I think relays will ..." I'm very surprised of the difference between flashbots numbers and Bloxroutes

Ansgar Dietrichs:For process, would we discuss FOCIL here or on acdc or both?

stokes:Replying to "For process, would w..." It is cross layer

terence:Replying to "For process, would w..." FOCIL is both

Potuz:it touches deeply both I think

DA | Flashbots:Replying to "I think relays will ..." What are bloxroutes numbers?

Potuz:but it's more invasive on the CL as far as I can guess

terence:Replying to "For process, would w..." I'd say it's 65% on CL and 35% on EL

Ansgar Dietrichs:Replying to "For process, would w…" Right, but we primarily discuss it in context of ePBS

Potuz:Replying to "I think relays will ..." I'll DM you later after all these calls

Roman:Replying to "but it's more invasi..." i think so too, EL implementation is much smaller than introducing new validator role

draganrakita:Maybe we can delay not headliner EIPs inclusion for few months so we can check headliners first and have better grasp how much time we will have for other EIPs.

stokes:FOCIL already CFI

soispoke:I thought it was already CFIed

Jihoon:Replying to "but it's more invasi..." FYI, an EPF fellow already shared a Reth prototype that looks like near interop today

stokes:But, to tim’s point — we should only work on SFI for now

stokes:FOCIL champions can look at complexity to layer on top of epbs

stokes:But should not IMO be the bulk of anyone’s attention

soispoke:Replying to "FOCIL champions can ..." Yeah doing this now

Barnabas:Replying to "I think relays will ..." could we have them as a public convo and not a dm?

Roman:Replying to "but it's more invasi..." got a link?

terence:Replying to "but it's more invasi..." https://github.com/PelleKrab/reth/tree/focil_impl

Roman:Replying to "but it's more invasi..." ty ty

Jihoon:Replying to "FOCIL champions can ..." On top of this, FOCIL is already in contact with testing team. A document that lay outs test cases thoroughly will be published later, which will facilitate testing a lot.

Tim Beiko:Glamderstam-devnet-1: EPBS & BALs

DA | Flashbots:Replying to "I think relays will ..." We can post something publicly for stats / discussion. But I’m on vacation for three weeks after tomorrow, so timeline is probably slow.

Barnabas:I’d have separate devnets first, so we can reduce the breaking surface. I would propose to have epbs-devnet-0 and bal-devnet-0 on last week of sep latest.

Barnabas:and then maybe in november we can have glamsterdam-devnet-0

stokes:Fusaka mainnet

stokes:Lets defer the rest of the glam convo for now

Francesco:Later than August 21 definitely

Potuz:Replying to "I’d have separate de..." BALS and ePBS are completely orhogonal so I'd just target one devnet 0 with a minimal spec

terence:Replying to "and then maybe in no..." i think we can do it in oct but just speaking on behave of prysm

Potuz:Replying to "I’d have separate de..." that has both

Barnabas:Replying to "I’d have separate de..." having them separate allows us to launch them independently

Ansgar Dietrichs:Hard stop or soft stop? Usually we still have a time where you can propose eips with special justification why they should still be considered

Barnabas:Replying to "I’d have separate de..." without having one wait for the other

Ansgar Dietrichs:Replying to "Hard stop or soft st…" Just flips the default

Milos:Does ePBS changes and how much based on whether FOCIL is included as well?

Potuz:Replying to "and then maybe in no..." I think late Oct or November for devnet 0 is a good target

Potuz:Replying to "and then maybe in no..." if we have two clients is already good enough

Potuz:yes, ePBS changes a bit

Tim Beiko:Replying to "Hard stop or soft st..." We can always make exceptions, but I think we should be clear that the Fusaka mainnet releases are the deadline to everyone.

Tim Beiko:Replying to "Hard stop or soft st..." Should be a very high bar to add things after that

Potuz:Focil makes it change even how we communicate with the engine

Jared Wasinger:State locations means accounts and storage that aren’t modified here

Jihoon:Replying to "Does ePBS changes an..." You might want to take a look into this one to get the sense: https://github.com/ethereum/consensus-specs/pull/4493

Potuz:Replying to "I’d have separate de..." if the extra money and coordination of having to check 2 devnets in parallel is not a problem then that's fine by me, I would have assumed that having only one would be simpler for you

Ansgar Dietrichs:It’s not just about batch loads (as in more efficient i/o), it’s also about not having to block when reaching a state load during execution

Potuz:Replying to "Does ePBS changes an..." I think this will change a bit once we fully rebase ePBS on top of Fulu

FLCL:locations !=changes?

Marius van der Wijden:This is just for reads, right?

Csaba Kiraly:These are the addresses read only, but not written, right?

Jared Wasinger:Replying to "It’s not just about ..." It doesn’t have to block necessarily. It can yield the CPU to another transaction while being IO blocked

Jared Wasinger:Replying to "These are the addres..." yes

Ansgar Dietrichs:I don’t think we should make a decision today, but we should agree that the state diff part of BALs is the only part already fully guaranteed to be included. The state locations part is tbd

Jihoon:Replying to "Does ePBS changes an..." Yes I'm not using this one as a source-of-truth but it could give the sense how the changes would look like

Ansgar Dietrichs:Replying to "I don’t think we sho…" Question is just, should we pull that part out into a separate EIP then and only CFI it?

Gary Schulte:adding reads allows for i/o improvements without parallelizing transactions. It would be beneficial in worst case block execution when no txs are parallelizable

Francesco:Replying to "adding reads allows ..." With BAL there is no such worst case, txs are always parallelizable

Ansgar Dietrichs:Replying to "It’s not just about …" Right but a worst case block would align transactions to minimize useful parallel execution

Gary Schulte:Replying to "adding reads allows ..." they can’t parallelize if they mutate the same state

Potuz:SSZ will be much better for the CL, it enables a lot of things like committing to different parts of the payload independently on the ePBS bid.

Jared Wasinger:I vote postpone. It’s so much simpler if we go with RLP

Ansgar Dietrichs:Replying to "It’s not just about …" It makes it hard to reason about worst case throughput

Karim T.:Replying to "adding reads allows ..." If you have the write you can do parallelization

Francesco:Replying to "adding reads allows ..." You are given the writes, so you can execute them independently

Tim Beiko:Replying to "SSZ will be much bet..." Why does the CL care about BALs?

Potuz:Replying to "SSZ will be much bet..." not BALs, but having SSZ on the EL eventuallyu

Toni Wahrstätter:Replying to "This is just for rea..." right yeah

Cayman Nava:Pureth H-Star Headliner 🕊️

Csaba Kiraly:Replying to "adding reads allows ..." Only if you have the write at the transaction level

Roman:heavy +1 to Justin

Sophia Gold:We will never have the dev capacity to convert everything to SSZ. Better to commit to not adding new RLP encodings

Dustin:There are lots of Go SSZ libraries

Francesco:Replying to "adding reads allows ..." You do

Dustin:At some what, what makes one happy?

Som - Erigon:Golang is history, we embrace Zig

Csaba Kiraly:Replying to "adding reads allows ..." And the read here is just location, but the write is data, right? If so, we should clear our terminology :-)

Potuz:Peter's influence :)

Marius van der Wijden:Replying to "There are lots of ..." His comment is about "good" ssz libraries

Ansgar Dietrichs:On state locations - probably not in time for Glamsterdam, but we could consider prioritizing propagating them ahead of main payload, so clients can start prefetching all state and have it loaded by the time they start main execution

Potuz:I'm pretty sure Claude can write a good SSZ library in Go in less than a day

James He:Stable containers

Dustin:"stablecontainer", etc

Toni Wahrstätter:Replying to "I don’t think we sho..." yeah I'd do that if we take it out. I think removing it will be easier than adding it

Karim T.:Replying to "adding reads allows ..." Yes we have write in the transaction level

Roman:Replying to "I'm pretty sure Clau..." can claude be a core dev?

Karim T.:Write is data read only location

Csaba Kiraly:Replying to "adding reads allows ..." OK, so if it is written multiple times, we have all data changes in, right?

Tim Beiko:Replying to "I'm pretty sure Clau..." Already is

Karim T.:Replying to "adding reads allows ..." Yes for each transaction

Karim T.:Replying to "adding reads allows ..." It’s the only way to have 100% //

ignacio:Replying to "I'm pretty sure Clau..." You’re absolutely right!

Josh Davis:Replying to "I'm pretty sure Clau..." Claude for PG

pk910:stablecontainers are deprecated anyway. progressive containers are the hot stuff now :D

Guillaume:Replying to "I'm pretty sure Clau..." show us

Csaba Kiraly:Replying to "adding reads allows ..." Clear, I just wasn’t sure we’ve made that selection (simply not aware of the datails)

frangio:is this the new EOF?

Jihoon:Replying to "I'm pretty sure Clau..." https://x.com/josephdelong/status/1235979765879844864

Potuz:It's been more than 3 years, surely someone could have written that library by now...

pk910:we have several go ssz libraries for different use cases. if looking at performance, you can use the very fast code generatosrs, if performance is not the highest prio I have a dynamic-ssz lib too. both are feature complete and work fine.. Not even talking about the other go ssz libs.. Btw, all json parsing is WAAAY slower in go.. so what are we comparing against to find a good ssz lib?

Jared Wasinger:Replying to "It’s not just about ..." The state reads are not currently specced to specify which transactions they occur in.

Roman:the nasty thing is that w/o history expiry we cannot remove RLP even in full nodes, let alone never removing in archive nodes

Tim Beiko:In this specific case, do we want to delay BALs/Glamsterdam because of SSZ?

Justin Florentine (Besu):hard no

Marius van der Wijden:Also we have not prioritized building a good library

Guillaume:Replying to "Also we have not pri..." yes we have

Csaba Kiraly:Replying to "I don’t think we sho..." I’m wondering whether that’s an actual throughput improvement on the long run. It uses up bandwidth at a critical time, while it does not save CPU time (just improves parallelisation).

Dustin:Replying to "We will never have..." this is the key point for me

Dustin:Replying to "We will never have..." IMO the wait-for-big-SSZ-headliner is likely to run into the not-scaling/etc objections

Potuz:I do not think there will ever be a "good library". SSZ is not something that can be plugged easily on any client, a good library for geth may not be good for Prysm and viceversa. I think that geth needs is to write their own library. There used to be a joint effort among Marius and Kasey, don

Potuz:don't know where that ended up

Cayman Nava:Pureth meta-EIP dealing with provability of the chain in general (Includes ssz-ing all the things) https://eips.ethereum.org/EIPS/eip-7919

Tim Beiko:Replying to "We will never have t..." But maybe that just means we actually don’t value moving to SSZ above those things?

Karim T.:Replying to "adding reads allows ..." More thinking more for me read location is not really important

Dustin:Replying to "We will never have..." I mean, on the EL side, that's demonstrably true, in terms of revealed preferences

Tim Beiko:Replying to "Pureth meta-EIP deal..." I think ACD agreeing on Puerth inclusion would be right signal for us to move to SSZ on the EL, rather than adding it bit by bit.

Dustin:Replying to "We will never have..." There's ust this kabuki thing about it, the objections are perpetually insubstantial, procedural, and yet it keeps not happening

Dustin:Replying to "We will never have..." And yes, I count the Go SSZ library objection as at this point borderline farcical

Karim T.:I think index of the transaction in the block and in BAL should be the same

Justin Florentine (Besu):Replying to "We will never have t..." it's purely capacity, not technical.

Justin Florentine (Besu):Replying to "We will never have t..." we aren't good at making hard decisions/sacrifices

Potuz:Replying to "We will never have t..." I tend agree with Tim, this will only happen if we make it a headliner, but the problem is that I hardly see ACD ever making it a headliner

Mario Vega:But then the tooling would have to be updated each time we add a systemcontract at the start of block execution

Tim Beiko:Replying to "We will never have t..." the problem is that I hardly see ACD ever making it a headliner But maybe that’s not actually a problem?

Guillaume:Replying to "We will never have t..." somehow we have the capacity to write a good ssz lib but not the capacity to convert from one format to the next? gimme a break

Felix (Geth):Replying to "But then the tooli..." no it's just one index for all the calls

Karim T.:List(pre, list(trx), post) Not possible something like that ?

Guillaume:Replying to "We will never have t..." @Dustin ok we're watching you write one then

Toni Wahrstätter:Replying to "But then the tooling..." right now it's one index but 2 might make sense

Potuz:Replying to "We will never have t..." Guillaume: as I wrote above, you guys need to do this, because no one will ever write a "generic" SSZ library that will adapt to whatever geth type system uses

Dustin:Replying to "We will never have..." Guillaume: in general, yeah, dealig with legacy data is a different kind of problem than dealing with a serde in a standalone way

Cayman Nava:Replying to "We will never have t..." imo poor chain provability is a big problem... for privacy and for UX of integrating ethereum into the real world

Dustin:Replying to "We will never have..." @Cayman the basic argument I put forward in Nimbus's pushing for Pureth as an EL headliner was that the alternative has been pointing people to untrustworthy RPCs yeah

Dustin:Replying to "We will never have..." And, right now it's easy-ish to follow full consensus/execution chain. But with the scaling people want it will become less easy

Roman:let’s not call it transaction index!

Roman:state transition index

Marius van der Wijden:I think there should be a BAL breakout

Dustin:Replying to "We will never have..." So this enables scaling by decoupling trustless/minimized chain access from scaling

Csaba Kiraly:One things read locations give is to tell whether a block is dependent on a previous block. I listed that property in my block level acesss filter proposal. Not sure it is useful here :-)

Potuz:it can be done on ACDC as well right

terence:i think the question is more on engine API and how EL uses safe head field other than RPC

Potuz:we do not use justified FWIW

Potuz:haven't for years

terence:Ya, I already talked about this in ACDT

Marius van der Wijden:I don't know anyone that relies on safe block being justified

Ansgar Dietrichs:Without much context, reusing safe block seems fine

Potuz:It can be dangerous

Potuz:Arbitrum uses safe now, not sure if they'll be happy going to fast confirmed