All Core Devs - Testing #90

Transcript

Justin Traglia: Good morning.

Pooja Ranjan: Morning, Destin.

Justin Traglia: Good morning. Barnabas, will you be able to give an update on the DevNotes? Are you the person to do that?

Barnabas Busa: Yep.

Justin Traglia: Alright, I'll ask you in a few minutes. Good morning. Just give a few more minutes for people to join, then we'll get started.

Alright, let's get started. Alright, welcome everyone to ACDT. Barnabas, are you here to give us some updates on Glamsterdam.net 7 and plans for Glamsterdam.net 8?

Barnabas Busa: Yeah, sure. So, Glamsterdam devnet 7 has been running now for approximately 3 weeks, 20 days. They have had a very stable weekend, Some of the nodes run out of disk space, but it's not something that's, Not something that's related to, the client performance? We currently have a couple of nodes still offline, could be Reth and Prysm. But I think Pori is working on, Getting that node, into a Manisha's Prysm node. And Lodestar and Besu should be, sinking back now, and, Grandine and Erigon is, also sinking now.

Justin Traglia: Oh, thanks. In the chat, Spencer has a question, like, what defines a stable DevNet?

Barnabas Busa: Well, over 90% participation, I would say. And we have, stable blocks coming in. No crazy forking. We still have a few, questionable notes, especially Teku, where they are not able to pick up the B2Builds? I'm just curious if maybe Teku would have an update on that.

Mehdi Aouadi: Yeah, I can give an update for Teku. Actually, we fixed those bugs, the one basically… Teku is always self-building, and not, accepting remote bids, and the other one was, was the, The tech wasn't, gossiping the, bits it was receiving from the builder. So, both have been fixed, and I just, published a new Docker image, this morning. So I'll be monitoring today and see if everything is fine now.

Barnabas Busa: And did you push the changes to your branch as well?

Mehdi Aouadi: Yeah, yeah. the… the DevNet 7 branch.

Justin Traglia: Alright, cool, thank you. Is there anything that you'd like to say about DevNet 8? Are we still planning on doing that this week, next week? Or, I guess maybe it depends on repricings?

Barnabas Busa: Yeah, so it would be dependent on repricing, as we now have the new CSpec release that was done on Friday, I think. So we should be targeting that for the next subnet. Ideally, this should be a named testnet that's short-lived. That we discussed, last week, Thursday. So based on today's, repressing discussion, I think, Could possibly schedule this, with the updated repricing values. Updated, and hopefully, find refreshing numbers.

Justin Traglia: Is there anything else you'd like to say about the DevNets before jumping into discussions?

Barnabas Busa: I think that's it.

Justin Traglia: Well, thanks for the update. I'm gonna go against what the order is on the agenda. Maria, would you like to discuss repricings, or give us an update on that?

Maria Silva: Sure, can you hear me?

Justin Traglia: Yep.

Maria Silva: So I'll just do slides, and then we can discuss afterwards. So I just wanted to give, before we start, like, a quick update on, where we stand with repricings. So first, what changed? So, 3 main things changed since the last round we were doing. So, first, we introduced some new account test cases, that impacted both account access opcodes, but also ET transfers. And, the minimum… the main difference is that now we have a wider variety of cases, and some of them are, worst cases. So we… before, we were just doing, for instance, accessing an account that had the same… different accounts that had the same code. And now we have this diff max, which is, accessing accounts with a maximum contract size, and we are…

Ensure that the bytecode is always different, so that the client needs to load the different bytecodes every time. And then we also introduced the, the delegated accounts. The second change was state actor, so we were using YohimNet before, which was a fork of mainnet that then we added some, states on top of it that we needed to run the benchmarks, and state actor is a synthetic snapshot that is created, specifically for the benchmarks. It has the state that we want, but also has the right size, so it's comparable to mainnet in size, but the layout of the… of the… of the snapshot is not the layout that we see in mainnet, so this is considered to be, like, a worse case than YohemNet.

And so this will also have an impact on numbers. And then, thirdly, we are now running these on Glamsterdam devnet 7. So there was some… optimizations that had to be migrated here, but my understanding is that, at this point, all clients have merged their optimizations. Erigon is still working on optimizations. But, the, the results, we'll see are, mostly… Already including the optimizations, So what changed? The big thing was the account cases got more expensive, and so these both for access, so for account access opcodes, but also for e-transfers. And we cannot make Et Francis more expensive, so the 21K is a hard ceiling, and so this means that we need to move our anchor from 100 million gas per second to 75 million gas per second, okay? This still allows us to get to the 200 million, and possibly 300 million as well.

The only thing is that, We kind of have, like, less… the way for further block limit increases. So, like, the opti- like, the… the ideal block limit that we get by using the entire execution window now gets, smaller, let's say. So, further increases for Kota will be, harder. And the other downward effect is that Because the relative cost between account access and storage access, changed. and we had to change the anchor, this means that now we can actually make storage operations slightly cheaper than they were in the current EIPs. So this means that if we want to do this, it makes sense to then change the final… the pricing to be slightly different from what we've been using in the previous,

DevNets. So, what does this mean in terms of specific parameters? So, everything on the ETransfers EIP remains the same. The only impact is to 8038, so the state access operations. And here, what we are doing is we are making account rights slightly more expensive, so from 8K to 9K, And we are actually reverting the increase on the storage access, so… Storage access, currently costs, $2,100, and with this new anchor, it means that we don't need to price it at, 300… 3,000, sorry. We can keep it at the price that it is today. So this means that that, like, SLOAs won't change their cost. And so this will also have an impact on our backward compatibility analysis. So, for instance, we had, a finding that Uniswap V2, was, was, had some…

issues with this, SLOAD cost, and by going back to the previous cost, that, issue will go away. So then, how does this look like in the current results we are seeing, with the current benchmarks? So, for 2780, and this is assuming an anchor of 75 million per second. you can still see that Erigon, is not, fully green on all, on all parameters. But as I discussed before, we know that they are still working on their optimizations, and they feel like they can get similar performance to the other clients when everything is merged. And then we have, like, a couple of cases here and there on Nethermind, Get and Besu, but I believe these can be,

Fixed, and if not, there's always the option of going to a lower, anchor, and this means that we'll maybe get a bit… like, we won't get to the 300 million, but we can still get to the 200 million blocks. And everything gets, green except Erigon, which they are still working on their optimizations. For state access, so EIP-8038, essentially this is what it looks like for the main, operations. As you can see, Erigon is still a red and yellow on a couple of cases. ethrex also has there a parameter that is much, needed to be much more performant. And then besides that, we have, again, Besu and Geth that are, like, right at the edge. I would like to add that for Besu, they are merging a PR for,

a component that we use for benchmarking that should improve their performance there, so I would expect, after we start collecting the results, or after tomorrow, I would expect this to become green rather than yellow. And for gas, they are right at the edge, so I think their SLOAD performance, shouldn't be, too far away from what we need. And again, there's always the option of lowering to 500 million gas per second, and then, most everyone would be green with except Erigon and ethrex. And this is an initial analysis, so we started to run the full suite, so… the results I was showing you is just a repricing analysis, but we have a wider benchmark suite that has, covers, both compute and stateful scenarios. And this is how it looks like with Glamsterdam DevNet 7 numbers, okay? So, as you can see, we still have

Majority, like, all clients have a couple of tests that are not passing the 75 million gas per second anchor. And they come all from the account, scenario. So as we increase, as I am proposing, as we increase the… The cost there, these, should go away. So I think now this is a time for discussion, so I think the key decision here is, do we freeze the repricing numbers that I proposed here? So, as they are, with the exception of those two parameters. And I think… so, to make clear what it means to freeze the numbers is that right now we freeze the numbers, and so nothing will change on the relative cost between op codes and the VM operations, and then we continue to run the full benchmarking suite, because we are still working on expanding it. And essentially, now the only lever we have is the

the block limits. Okay, so we will still tweak the block limit, like, if clients continue to do some more optimizations, we may… that may mean that we can get to the anchor of, again, 75 instead of 50. And that will maybe allow us to have a higher block limit, but the cost would be the relative cost between, for instance, storage operations and account operations would be fixed. So we'll… sort of… Make that, a fix, and also by Assuming a price of 75 million gas per second and making storage slightly cheaper, this means that, if we improve performance on the account side, then accounts will be more expen… so accessing accounts will be more expensive than it should, so it kind of lose a little bit of throughput there. So these are kind of, like,

The downward effects. It's like, if we freeze now, we can re-block the fork, which is great, but we need to continue to iterate on the benchmarking suite, and then use that to set the block limit. And yep, I finished my presentation. Oh, just to say that if you want to see the final, like, the most updated results, I have here the link. So these are two dashboards that show you the data I was showing you before, with more details on the modeling and things, so you can always find the latest, data there. So yeah, open for discussion now.

Justin Traglia: Great. Thank you so much for the presentation, Maria. I'd be curious to hear from clients and others of, like. this is generally what you guys agree with, and if so, we can, make that decision now, or if it's not, I think we should probably discuss this in detail in the EL breakout call. Toni?

Toni Wahrstätter: Yeah, thanks a lot for the presentation, Maria. The 2100 for the SLOAD, was that with the 50, or with the 75?

Maria Silva: 75.

Toni Wahrstätter: Okay, great. So we could, in theory, like, let's assume we keep the execution payload deadline at 6 seconds, we could, in theory, go to, like. If we push limits to 420, million gusts.

Maria Silva: Sorry, can… can you say that again? I… I…

Toni Wahrstätter: We could go to 420 million gas,

Potuz: 450, I think, is the theoretical maximum there.

Toni Wahrstätter: With… with 7… True at 75, yeah? Okay, so this would mean, like, 300 million in Glamsterdam would be something we could target?

Maria Silva: I mean, if we can get… so the… the… the breaking thing is, like, if we can get these results to come all green, then we should be able to do the 300. If not, then we need to do lower. So this will now be the thing, like, we are not changing any prices, right? So this means that the clients need to… Like, need to lower their performance to this level. Lower, now improve. If that makes sense.

Toni Wahrstätter: Yeah, yeah, okay. Yeah, cool, thank you very much.

Justin Traglia: potuz or Nico, would you like to suggest? Lowering the attestation deadline to 2 seconds.

Potuz: Could I ask… I want to keep on the same topic before we move. Can I ask something to Maria?

Justin Traglia: Of course, yeah, go for it.

Potuz: Yeah, so I was going to notice this number of 450 that Toni mentioned. So what I would like to know is a feeling of clients of how close to the actual limits we are now. Like. Suppose that clients work out optimizations, and they manage to get everything green at 75 million per second. Do we feel that this is just as much as we are going to get with current hardware? Are we reaching the limits of what we can actually scale or not? Because knowing these limits in a per-second manner might give us information on how to bench and And how to actually measure the part of the slot that is wasted on block propagation, the part that is fixed per slot.

Because we're going to envision discussions for Hegota on shorter slots, for example.

Ben Adams: I mean, we are measuring worst cases, and… Not average cases, so, you know, this is… What if… what if the… the worst case blocks are running? What's the performance? And also… It is harder to do performance optimizations based on the… testnets versus, say, what's running on mainnet. When it goes… when Glamsterdam is live, I think we'll be able to Analyze on real traffic more, and do more optimization.

Justin Traglia: Any other thoughts from clients? Or…

Łukasz Rozmej: So, my thought is that those numbers looks good, and… Bond… For 75 megah, right? For 100, probably not. And, you know, those are worst-case blocks, so… You probably need some kind of attack or already unfortunate things to get those similar results. And normal traffic is way better, so… Probably looks okay.

Maria Silva: And I, I would just give, like, a slight, clarification there. So, this is… these are worst cases in a sense that we are targeting many different accounts. that those accounts are, like, worst cases. Like, we have, for instance, we are assuming that we have like a 10GB contract, and we are targeting different slots, or a full block. So this is the type of scenarios that you'll see that generate these numbers. And with state that is the current mainnet state size.

Justin Traglia: Otis.

Potuz: Yeah, so, so… One problem… I agree and empathize with this thing of, like, these are the worst-case scenarios, and the average block is much smaller, or much faster, and whatever it is. But the problem with ePBS is that it becomes an automatic reorg. If, if we actually hit this limit. So this is not something that we have today, so if you just delay enough, if you send a block that takes a long time to execute, it doesn't get attested, and then the builder itself is hurt. But after ePBS, this becomes an actual attack that can't be carried out. If I send you a payload that takes more than 6 seconds to execute, then the next proposer is the one that gets reordered.

So, this is an attack that is very viable, and unfortunately, we need to, like, account for the worst case scenario, not the average one.

Maria Silva: Right, I agree, and I think a point there is, like, I don't think we should feel like, assuming ePBS gives us 6 seconds… 6 seconds of execution, I think we should still give always some buffer, because again, like, these numbers, they have error, like, they have… data collection errors, like, these things are not fully exact. So if we have 6 seconds of execution, we shouldn't assume that we'll have, like, 6 times 75 million gas blocks. Like, we should always have some buffer. So I agree with potuz, and I think, like, that's why this is conservative, right? Like, with 75 million gas per second, we could do more than 300. But I think it's important to, to, to leave that buffer.

Justin Traglia: Toni?

Toni Wahrstätter: Yeah, maybe just to add to that, because one thing that is also important here is… the choice of the payload execution deadline at 6 seconds, because now that SLOAD is not more expensive, like, priced at $3,000, but instead at $2,100, this also means you can get more SLOADs into a block, which means the ball will also be bigger. So, like, making SLOAD cheaper will increase the worst-case block size. And this means, Like, we have a very big gap between the average block size and the worst-case block size today. And the worst-case block size, after clamps are done at 300 million, will be something above, 7.3 megabyte. Yeah, this is, like. A very malicious block, like, it's nothing that the mempool would ever… the public mempool would ever allow you to, construct the block.

from. So yeah, I would still say we keep the payload execution deadline at 6 seconds, even though this increases the worst-case block size.

Justin Traglia: Notice.

Potuz: Yeah, I want to say three things. One is, I agree with everything Toni just said. Exactly like that. The other one is I wanted to reply partly to Barnabas. I think what Maria is pointing is numbers. Let's suppose that clients do reach 75 and everything is green. I think what Maria is pointing is that it will be safe to go with 300 million. I don't think she's suggesting that we do… I don't want to speak for her, but I don't think she's suggesting that we should do this at the fork. But we are pricing towards reaching, comfortably, $300 million. So I think it's fine if we have this discussion of what we are pricing for, and then later we decide what is the actual gas limit that we are going to target at the fork. It seems to me that it's safe to do what you're suggesting, just $200 million, and then immediately increase if we're handling it fine.

But I think the pricing that we are given now is… suggests that we can handle 300 millions comfortably.

Maria Silva: Right, and I… I think, yeah, this is true, and the… the… the reason why trying to put the anchor as high as possible is that repricings are painful for the community, and so we want to avoid having to do it again if we need to, and so having, like, a slightly higher anchor will give us more breathing room, also for… for… for Hegota.

Justin Traglia: Okay, so how should we proceed here? Like, do we have enough information to make a decision now? It's unclear to me.

Maria Silva: Yeah, so I guess the key decision is, like, is everyone comfortable with these change. Unlocking these as the final repricing numbers. And here, the only… worry thing that can happen is that, for some reason, if there's improvements in the storage access, Performance, then we would be… Sorry, not… sorry, so if there's improvements in the account access performance, then we would be making it too expensive, and so it would kind of be, like, a slight Lack of throughput on those operations. And this is the, kind of, the trade-off. It's like, we fix now with… The possibility that, there could see be some optimizations there that we're not considering. So this, to answer Johann, this doesn't include the new numbers with access lists.

So those will also change. So…

Justin Traglia: Okay. So instead of asking for, like, who disagrees with this, I would like to ask for explicit approval on who is fine with this, from each EL client. Did we, like, go in a circle really quick? I can call out names. Is there someone from death here who has an opinion on this? Or that can answer for the team.

Marius van der Wijden: I don't want to speak for the team, but I'm with the Geth team, and I have an opinion on this, and I think it's good.

Justin Traglia: Okay. Maybe someone from Nethermind?

Ben Adams: Yeah. We're good with it.

Justin Traglia: Great. Besu?

Ameziane Hamlat: Yes, we are good with the numbers. Just maybe one concern from our side. This is something I erased, with, especially with SLOAD currently. So the last time, the numbers, looked good, because we were using, YoCamNet, and when we, switched to state actor, we had different numbers. with the same anchor point. But the issue for me is that, state actor is synthetic, whereas, whereas, Your CamNet is a snapshot from mainnet plus some new, new accounts. So there is… there is an assumption that, like, as we have, like, these new accounts with this new storage, this is somehow, like, warm on the… on the… On the storage side. But for me, we don't have enough feedback and data on that assumption.

So, for me, this is… this is good for now. We can continue to work, toward, toward these numbers, but maybe keep and investigate, like, this assumption, just to be sure this is, like, like, state actor has something, like, is generating a state that is very close to what we have in mainnet in terms of performance.

Justin Traglia: You're welcome.

Jochem Brouwer: Yeah, just to react to this, Ameziane, thanks for that feedback, because you are exactly right. I just want to add, this is, like, I think a very important point. So, you are right that YohimNet is indeed, like, a mainnet snapshot. The problem is, and this is what we identified when we moved to state actor. is that… and this sounds, like, super trivial, but not for me, so sorry about that, but it's, like, super trivial if you know it, but that's, of course, with all trivial things. The thing is that on YohimNet, what we do there for the tests, what we are targeting for the repricing. We need a specific pre-state. This pre-state is injected on your net, well, I would say also synthetically, because we inject this state using transactions on top of the mainnet snapshot.

And this is, if we take the zaps for specific clients, this is mostly for the clients which use an LSM database, so that is, Besu, Nethermind, and GetF. The thing is that these accounts are then at the top of the LSM tree, so these accounts are much faster to read than if these would be old accounts. The response to this is, and Ameziane erased this, like, why don't you just create an attack which actually targets the old account? This is a very good point, we will do that, but we don't have that now. But the realization is that for the state actor, there's, like, no information in the database when this state was accessed. So this is why our claim is this is closer to the worst case, and this is why we have moved to state actor.

But I still completely agree, we should, have this feedback loop, and we should, or not we should. We will have this feedback on what are, like, the exact differences for Johannet and state actor, and how compliance optimized this. So yeah, I just want to give that, that commitment that, that we want to get. And thanks for the, thanks for the feedback.

Maria Silva: And I would just add, like, a quick point, like, on timing. So, the reason why we are not now running YohemNet and state actor at the same time is because of machine availability, and so right now, we need to run both repricing and the full benchmark. Once we fix the numbers for repricings, we can stop running the repricing suite and just focus on the full benchmark suite. And this means that then we can maybe run a full benchmark suite on state actor and YohimNet at the same time. And also, another point is that we need to do some changes to YohemNet for the new test account cases, and that's also something we need to do before we can run both in parallel.

Justin Traglia: Okay, resuming the loop real quick. ethrex in the chat said they support it, Reth said they support it, and there is a… And so does Erigon. Okay, great. It seems like there's consensus on this, so… Yeah, do whatever you need to do for the next steps on this. I suppose there will need to be an execution specs release? sometimes turns with these numbers? Okay.

Maria Silva: Yeah, so I will update the numbers in the EIP, and, maybe I'm not sure if Spencer or someone from SEAL can update the release, and yeah, and then it'll be final.

Justin Traglia: You're welcome.

Jochem Brouwer: Yes, I just want to explicitly ask here, because there was a discussion on this part about EIP 8038 and EIP 2930 access list costs. I want to ask, are we, making the costs for the access lists, for, like, sorry, for storage reads and account reads. not have this discount, such to, this, well, not give an incentive anymore to use the access list, so this will be, like, some kind of deprecation. of X and this, are we including this?

Toni Wahrstätter: We're already doing that with, 7981, right? Because with 7981, you already add, like, a constant to each access list item, and it's already, like, economically irrational to use them.

Jochem Brouwer: Okay, great, then my question's answered. Yeah, thanks.

Ben Adams: Except, for their original use, I think. Is that correct?

Toni Wahrstätter: No, I think for every use. Like, if you put a storage slot in there, it will be 32 times 64 more expensive, and for the HSS 20 times 64, And this is… you will never… this is, above 100, which would have been the savings you had, so it's… it's always more expensive.

Ben Adams: Yeah, yeah, but it's still… it's still viable for the original use, which was, there were some contracts that broke on the repricing. So you'd pay a little bit more on the access list. And then those contracts would still work.

Toni Wahrstätter: I see ya.

Justin Traglia: Alright, Caba, I moved your discussion item to the EL breakout, section. I think we should probably jump into the breakouts so that, the EL side can continue, or can have their discussions. Is there anything that we would like to just, sorry, say before this part ends, potuz?

Potuz: Yeah, so if we are going to discuss attestation deadline, that needs to be joint, because, I mean. especially the most involved people are on the EL side, and are on the benchmarking side.

Justin Traglia: Yeah, that's true. Okay, let's discuss that really quickly, then. Can you lead this, Paris?

Potuz: Oh, no, I can't. I trust Carlos' number. Carlos, I think, has proof that we cannot move to 2 seconds. If anything, I mean, Nico seems to suggest that we want to move to 2 seconds. I'd like to know if there is a path towards getting those optimizations, and what do we need to measure to move to 2 seconds, and hopefully we can just, like, do this after the fork, it doesn't need to be a hard fork. So, in principle, we can just ship to clients and start a testing at 2 seconds.

Justin Traglia: Toni?

Toni Wahrstätter: Yeah, how are we measuring, like, attestation propagation today? Because… With ePBS, the block will become much smaller, because the payload is not attached anymore, which is, like, 95% of the size. So, if we are just using attestation propagation today, then we might be overly conservative.

Potuz: Yeah, but it's not… it's not attestation propagation. It's… it's something that I believe it's easier to measure, which is because the problem here is block propagation and block validation. And it seems that the bottleneck is actually block proposing. So it's the time at which the block is even built is the bottleneck, it seems to me. We found a bug on Prysm that we were… because we started reorging. SLOT 31, we found a bug in Prysm that was preventing us from proposing fast SLOT 0 in Gloas, purely on Gloas, it is not live on mainnet. So, what I'd like is, like, do we have the machinery to start measuring accurately? Block propagation, especially accounting for a much smaller block, and a much faster to validate block.

So that we can actually lower… life becomes easier on many attacks if we lower the attestation deadline to 2 seconds.

Justin Traglia: Who here has feelings on this? Our thoughts?

Nico Flaig: I mean, could we just reduce it, and then see if it's too low, we can bump it again up? So we at least start this value? Or, I mean, test this value? Because right now, I don't see any reason why you cannot produce a blog in one second on the CL side. I think the case.

Maria Silva: Yes. Sorry, do you mean test on the testnet, or on mainnet?

Nico Flaig: No, no, I mean, on mainnet, we cannot test this, but yeah, just on the definet, and then maybe the… I guess you would need Hoodi, at least, to get some good numbers.

Potuz: On the death net, I'm sure we're gonna be fine. The question is, do we want to ship this… we can probably agree on shipping like this on the first major testnet, but it's a risk. The zestnets are good for this, because zkNets are not stable now. Like, if I ship this on Hoodi. It's a good test. If it works on Hoodi, I'll feel well about Mainnet.

Enrico Del Fante: Well, for us, the reason is the station parking. This is one reason that I can find Possible interaction with this, because we have… some heuristics, it runs in block… at block production, and we have some hard, stop this, optimizations. On fixed timings, and so we might need to lower down those numbers to make… to release the block faster than today. Yeah, so this really depends on how big the state… the testnet… the network is, and how messy it is.

Justin Traglia: My thoughts are that… I think I'd like to keep 3 seconds and get more data, maybe on mainnet. Let's see if we can then lower it to 2 seconds. What? potuz, do you know what Carlos… Carlos's, I'm like… Why was 2 seconds impossible?

Potuz: the problem was mostly on one operator, and I actually think it was, it was on Prysm, so Terrence has more numbers on this. It's… It's a… it's a problem, because the… the problem is that operators are running with min bid, with a high min bid. And then the… they're playing timing games. And this combination is crazy, because then they waste the most amount of the time waiting for a bid, and then this bid comes, and it's not good enough for their main bid. And then they just produce the block locally, and if they have blobs, then they don't have the infrastructure that the builder has to broadcast them, and then they're screwed. So… so this combination of min bits with, that's what we found on this main operator that was pointed by Carlos.

So I think it was just a local scenario, so I do think that two seconds are possible, but I agree with you. I think we should not aim to, like, release this at the fork. But what I would love is to see, perhaps, PandaOps owning, like, gathering numbers, right at the fork, getting numbers, hard numbers on this, on block propagation and on block validation per client, how long it takes the state transition function. Try to get rid of the part that is purely timing games, because we can just tweak that. And then if we manage to prove that 2 seconds are possible after the fork, we can just coordinate a release. This doesn't really need to be a hard fork.

Justin Traglia: Yep, that's.

Potuz: Especially because clients that are attesting early. Clients that are not upgraded and are tested later, are testing later, will still be able to, like, get… agree on head with the other clients, so it's fine.

Justin Traglia: Okay, I saw a few thumbs up when I mentioned that. I mean, it was actually your idea, but I think we should proceed with that. So, keep 3 seconds. Consider lowering later. Okay, anything else before… anything else before we start the breakouts? Okay. Thank you, everyone. CL clients, I just shared the link to the CL breakout. I'm gonna join that. So, bye everyone. Talk to you guys next week.

Spencer Taylor-Brown: Thanks. Cheers.

Marius van der Wijden: And now, only the cool people remain.

Maria Silva: Yeah, I'm not sure who's leaving these, but I'm seeing, like. two things to discuss, so one of them is the discv5 proposal, and, I don't know, Csaba, do you want to discuss this one?

Csaba Kiraly: For the disk 5, according to my testing, everyone is fine on one branch or another, so I don't see… issues having a DevNet 8 branch on… we just on disk 5, if no one is opposing. the… the issues we have seen were tooling-related, and then I still have pending a few, Hive tests, which… which might uncover a few minor things to tweak, but I think we can just go with this 45, the… For my point. Anyone has doubts. Basically, that's the question. I mean, that seems like a no. Yeah, so from my point, we can just go with discv5 on the next… test, and… I mean, DevNet.

There were two clients who had no flags to disable this before. One was Nimbus EL. And they promised to add it. Please tell us to do it that way, and I don't remember who was the other one. So please add the flags. Yeah, that was, for me, from discv5. I think we can just go with it. If there are no questions, I see in a hands up somewhere, but I don't know who it was.

Mario Vega: Yeah, it was me. Just to check with Stefan if there's any issues with this on the Demon8, I don't think so, right? Or…

Stefan Starflinger: I think most of the work has already been prepared by Barnabas. He's already changed the Ansible collection. to use Disk V5 across the clients, and he's been doing some local testing. And, I think so far, it's been looking good. I haven't heard any blockers. But yeah, it would be good that there is no fallback to discv5 in clients, otherwise that would be a little bit annoying.

Csaba Kiraly: So even if you would keep the 4-back later. on a main branch, he'll… I think we want to turn it off.

Stefan Starflinger: Yeah, exactly. It's better to quickly identify what's going on with discv5, and not have to deal with multiple variables and dimensions.

Csaba Kiraly: Yeah, plan timeline for mainnet for this V5, I sync, what we want to have… is that… everyone starts to have this V5 enabled, if there is someone still missing, the V5 enabled on mainnet releases, and for the… For all queries, we would turn off this freefall by default. Yeah. Alright, so that's it for this.

Stefan Starflinger: That was another point by Yochum? Or…

Jochem Brouwer: Yes. Right, okay, sorry. Yeah, so I wanted to discuss, Block Access in combination with SnapSync, or well, actually, more about, other Inlocks, what Block Access gives us for syncing nodes. Because we have to realize that block access lists They are basically the built-in, they look in the protocol that we now have verifiable lists of state what's being accessed. For the latest, Xbox. or actually since the fork, since we activate block access lists. And the idea here is that, if we do step sync, so this is specifically focused on step sync. Is that we can actually rock-start the client, in the sense that we can already put the block accesses items into the ROT state, or your cache, or, like, whatever. That depends on, like, how your client uses a cache, or, like, how it initializes state.

And the idea is that, currently, if you SnapSync, you are doing downloads on, on the Merkle tree. Using range requests, and this is… well, this is so much random, because there is, like, no data in the protocol if your state is, like, super old. Or, like, if it has been touched, like, recently, because currently we do not have this data in the protocol. But with SnapSync, sorry, with Block Access List, we actually have this. So what you can do, using SnapSync, and then Snapchat 2 sync. Is that we… Let's see, this is here. So, let me actually share my screen, because that's much more handy. Yes, can you see my screen?

Csaba Kiraly: Yes.

Marius van der Wijden: Yep.

Jochem Brouwer: Okay, so this is, the EIP. 8189, this is the EIP from Toni and Gary, and this adds the GetBlock access list into the protocol. So, the nice thing about this, yes, Marius, this is indeed just Snap2, but the thing is that in your clients, if you do, like, explicit asks, or explicit puts for the state that it is hot. Once you have snap synced. you should then put, like, the latest X-axis list into your hot state cache, because then when you are done and you start executing your blocks, then you immediately have this state into, like, a hot state, instead of, like, with Snap1, where you have this state, in, like, some colder, colder cache or colder state. And this, actually aligns with this EIP for Toni.

Let me also nick that. So, the thing is that about 79% of the first touch items were also touched in the previous 256 blocks. And the idea is, I just want to raise this, that using this, you can just hot start your client by putting this state into… well. a cache, or, like, a fast-readable state, or whatever. And… Yeah, I just wanted to raise this point. I actually hope that Gary from Gaff will be here, but I don't see him. But yeah, this is, like, a general idea for Snaps.

Karim Taam: I think it's not only related to SnapSync, we can just, when we start a node, or after SnapSync. Trying to have all of the last block access lists from other peers, and Read everything and add that in a cache, or… What the hell we want, but…

Marius van der Wijden: Yeah, I think that was the purpose of Snap 2, was, like, to also get rid of the healing phase in Snap by just using the block access list that we've accumulated. So… you need the healing phase in the snap protocol in order to get from… like, when you… when you do a snap sync, you choose a pivot point, and you're trying to snap to that, sync to that, but in the meantime, the chain moves, and you have to choose a different pivot point, and you have to do, like, update your pivot point. And, because of that, you will have, like, not… one… continuous tree when… when you have finished your snap sync. And so we have the healing phase to heal, basically, this… these… these half trees into one.

And what you can do with the Block Access List is, Whenever, like, you choose your first pivot point, and from that on, you also record all of the block access lists, and then instead of healing, you just execute the block access lists. Can't be much faster.

Jochem Brouwer: Yeah, okay, so maybe my point was then also implicit with Snap2, but yeah, it is indeed about… Now, of course, Snap2 also makes this healing phase a bit better. But also, if you just explicitly add these, and this is, I guess, implicit if you execute the block exit list on top, that's together with, with SnapSync. But that's how it looks… but maybe I'm already, like, raising a point what other clients have, but I just wanted to… at this idea. But what we maybe should then do this, because I think this is not clear in this EIP, that we explicitly note what this should do and what they should unlock. Alright, yeah, that was my point, so I guess,

we can then, I don't know, like, if there are no reactions, then I think the breakout is, is not.

Mario Vega: Do we need any decision, Johann, on this?

Jochem Brouwer: No, this is, like, no decision, I just wanted to raise that, if you're… if you're, I would say, like. maybe this is, like, a wrong assumption, but if you would naively implement SNAP2, then you might not unlock these benefits, and this is why I'm raising this. So, it's also… it's not critical, but it's just, like, a very nice property that we can now hot… hot SnapSync, I would say, and also hot load, also for the clients which do not support SnapSync. That what Block Access List unlock, you can check for the latest whatever box which you have… which you have the access list, sorry, the block access list of. You can use this to put these items into your cache, your memory cache, your state cache, your whatever cache.

And I wanted to raise that point, because it's like a very, very nice property, what this unlocks. So both for step sake, but also for what Block access. So yeah, no decision, but just wanted to raise that for clients to play around with, or to check if you already implicitly have this property.

Mario Vega: Any comments from clients?

Jochem Brouwer: Yeah, maybe Karim can enlighten at this point on the L0 thing for the LSM data.

Karim Taam: I said yes, maybe, I see also that as another step after Snapsync, maybe we can, Try to get all of the block access lists, of the maybe last 2 weeks, or maybe less. And, trying to move all of this data to L0, so as you said in your comment, I think it could be something we can try to test and see.

Łukasz Rozmej: So, one comment from me, like, I think the main, addition of Bos in terms of Snap sync is still the healing, which is, going really fast with balls on our testing. But, general, this is, well, this kind of optimization of having some hot reads with balls, etc. done. It's fine, but it's still, like, a happy path optimization, so it won't really affect the benchmarking numbers, for example, that we are talking here, so… It's nice to have, but it's… tell, I expect… we will handle the happy path regardless, most of the clients, really fast with balls, so, It's, like, if someone really wants to push the network to its maximum throughput, practical throughput, With, like, potential compromises to security, then it makes some difference, but if we are measuring the worst cases, it won't make a difference.

Jochem Brouwer: Yeah, completely, completely agree with this. It's just, as I said, this is, like, a very nice-to-have, to hot boot, like, however you want to call it for, for syncing notes. Yeah, but good point, very good point.

Łukasz Rozmej: I think, you know, this kind of things can also wait post-release, this kind of happy path optimizations. They might be worth it, but they're not, like, crucial at the moment. And we'll have more data. To, to know how, how well they performed, and…

Jochem Brouwer: Alright, yeah, I think, I think that's it. So I guess maybe it's my time to close the EL breakout. So let me cut down from 5, and then we can say bye. Bye. 4… 3… 8.

Marius van der Wijden: Yay!

Jochem Brouwer: Oh, that's…

Spencer Taylor-Brown: There was a last-minute comment left by potuz, about EIP-8070. I think, it was a continuation from last ACD, where… there was some discussion, I guess, on whether we make… EIP-8070 mandatory, specifically the engine API. endpoints on the ELs, maybe, potuz, if you're here? If not, I guess, are EL clients okay with adding that? I added a simulator to test this. I think Geth and NetherMind are passing these already. With the EIP-8070 implementations. Okay, yeah,

Milen Filatov: Yeah, it's… So, I… I was gonna say, I… isn't this something that should be discussed with, the CO clients as well? Because… There were concerns about… Putting that in FCU. to me, it kind of feels a bit weird to be putting that in FCU as well. Not sure how blobs relate to FCU.

Mario Vega: Maybe we can bring it up… bring it up in ACDC this week. I think maybe… SL Devs can chime in there. But I feel like there's… In my opinion, there was no modifications to the… to the spec, so maybe it's just the same way as it was presented last week, so nothing changed, so maybe the same issues are still there. So I think we maybe need to reach out to potuz. Just to check if those concerns were addressed, or if there's gonna be any changes to the spec. But it feels to me that we have to bring it up, fix the spec, and then bring it up in ACDC, in my opinion. I'm not sure.

Jochem Brouwer: Yeah, let's, let's check with potuz and, then, Agent at ACDC. Okay, I will count down again. 5. 4. Treat. 2. Welcome.

Justin Florentine: Yep.

Jochem Brouwer: Alright, bye-bye. Thanks, everyone.

Marius van der Wijden: Cheers.

Spencer Taylor-Brown: Bye. Cia chiao.

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