All Core Devs - Testing #44

Transcript

Parithosh Jayanthi: Okay, let's start off. Then could we start the stream? Please.

Pooja Ranjan: We are, live.

Parithosh Jayanthi: Thank you. Okay. So the 1st topic on the agenda today is, an update on Fusaka. Do we have Barnabas on the call to give the update.

Barnabas Busa: Yes, we have a pretty nice participation now, at about 95%. We have seen a few extra deposits made from the team. They are testing their coupling validator or their coupling. Cl, we had a few issues, and I have reached out to every single client team about those specific issues. If you are noticing that your editor is not up to head, or are having some issues in staying up to head or missing some doc proposals. Then please take a look. But other than that, I think we should be pretty good.

Parithosh Jayanthi: Awesome. Were there any notable bugs that were fixed in the last week that we should talk about? Bring up.

Barnabas Busa: Nothing really like right now we are investigating some metadata box, that tech with the that. So we have a new tool called if does guardian. And this tool is helping us, the metadata field and status messages of a specific client. And this is going to really help us Debug smaller problems and figuring out if specific notice costing the columns that they say they would still a bit work in progress. But hopefully, hopefully, it will be more ironed out by the ministry.

Parithosh Jayanthi: Yeah. And I think the tools also aim to give us a 3rd point of data set whenever there's a dependency between 2 clients, and it'll be integrated into Dora so that it's easier for client devs to also figure out what's going on on network. Yeah. And Justin says there was a small nimbus issue that was fixed and new consensus specs. yeah. And the result of verifies that Kcg proof patch wasn't being checked properly. Thank you for the update and on the topic of consensus specs. I also see this as one Pr from Leo that adds, adds a few new test types Justin. Maybe you could have a look and the Cl teams as well if this testing approach makes sense and we can merge it in. Perhaps.

Justin Traglia: Yep, we'll review. I'm not sure how I feel about test for a test, though. The test template test we'll discuss that internally.

Parithosh Jayanthi: Okay, that sounds perfect. And Barnabas. There was also a round of sync test. Right? Were there any findings from that? Are we mostly good. What's going on.

Barnabas Busa: Sync test generally looked pretty. Okay. We cannot make bigger conclusions right now, because we are limited in a different aspect, but hopefully. By the end of this week we're gonna be able to do very stable sync test.

Parithosh Jayanthi: Okay, perfect and we can just post the sync test repository in case anyone wants to also play around with what's going on you should be able to check the Github actions here they are triggered once a day, and you should be able to see if your client is passing or failing the sync test for the latest, for Safa Devnet.

Barnabas Busa: Yeah. But for now, please ignore this, because, we are currently I Ops limited on our Github runners. So those invalid test they basically just time out after 2 h, and those are most likely caused by the same bug that the machine doesn't have enough.

Parithosh Jayanthi: Yeah, right now, we can't draw any assumptions on the actual speed. Once we change the infrastructure, then we should be able to also compare speeds of the sectors. Is Bharat. On the call I saw he had posted a message with an update on med testing.

Bharath Vedartham: Yeah. So I'm on the call. Yeah. So in terms of the update to the workflows the 1st the code is there, I think, Justin, thanks for the review. Justin was able to review, and seems good. The code there. So I think Map boost, and Melay generally seem, can get it on a devnet. Our builder, I was able to hack it around and get it to work locally. So this is like local, and kurtos is local, but it's not like broad ready, like. There are a lot of breaking changes across, like the red and alloy stuff. So I ended up. There are some hacks, but it's working. I was able to see like blobs being produced locally and stuff.

So yeah. So that's that's the update would love to get out on Devnet, too. But one of the problems you know, in having in the Tg chat with Roman is like. I think the definite Fusaka devnet. 2 branch of rep is this is breaking with Eip 7, 9 0 7 that. I'm I'm trying to like work on that to. I'm like Roman gave some suggestions. I've tried to like work across that, and I'll put any up an update on the Tg chat. But yeah, that's the current state of like email workflows some dependency issue with like that. I'm trying to like, I'll try to resolve that.

Parithosh Jayanthi: Okay, that's perfect. Charles, did you want to say something.

Charles Cooper: No. Hello! I just joined.

Parithosh Jayanthi: yeah, okay, that's perfect. In that case, then, if the dependency issues are fixed while Devnet 2 is still live, then I do think it's fine to deploy like a fork of something that's unmerged purely to catch bugs earlier, so that we have more time to fix them. But if not, it sounds like it would be ready in time for Devnet 3.

Bharath Vedartham: Yeah, yeah, that's that's the point.

Parithosh Jayanthi: Okay, perfect. Thank you for that. Continuing on the Devnet topic. We do have a state a state bloat network that's been working over the weekend. I think there was some minor things found in. Never mind that. They're still investigating. but we are aiming to have 2 times the state size of Mainnet. Soon we. There is a a telegram group where we're trying to coordinate metrics. So in case there's any El that it hasn't already been added to the group. Then please reach out. There's a list of metrics and type of data that we want to gather, and that's very client specific. So we're gonna need your help to to get the metrics. The next topic is, 45 million gas limit lighthouse made a release last week, and I wanted to know what the status is of the other cls.

in terms of releases. Okay? Then I guess we take that offline? At least the good thing is over the last week. Nimbus also has done this release as well, so we already have numbers as well as lighthouse with their release and according to the relay Apis that we've been tracking, we have roughly 40 ish, 41% indicating 45 million gas we have around half indicating 36 million gas and a few which? yeah, we're still figuring out that indicate 30 million. Yes. so at least over the next days. I think that should sort itself out, and we should be fine and just reading from the chat. I think prism lodestar as well as kind of have releases

either tomorrow or later this week. Okay, thank you for that. There was one following topic for fusaka.net. 3. There's this open pr blob transaction limit that hasn't been merged yet. Does someone want to give context here and figure out what's missing.

Barnabas Busa: I think they are approved are missing. They've discussed this topic many times already on Acd. E. And as well just for a quick recap. We are to say that we're gonna be removing the Max Blobs per transaction from the blob schedule configuration, and we're going to have it hard coded for perfork. so no more no longer gonna be part of the Bpo. But it's gonna be part of the work.

Parithosh Jayanthi: Okay, I think at the very least we need either Mark or Raul to approve it as eip authors. But it would be great if other El teams can also leave their comments down. Okay, does anyone have anything else to add for the topic? If not, we can move on. Okay. Joacham had a presentation prepared for Eip 7, 9 0, 7. Do you wanna go, Jokom.

Jochem Brouwer: Yes, let me share my screen. Yeah. Can you see my screen and also my mouse?

Parithosh Jayanthi: Yes.

Jochem Brouwer: Okay, great. All right. I wanted to bring up the well. The the big problem is, we want to raise the coder size limit. This seems like a trivial problem. But from my side this is not trivial to solve at all. We are currently introducing eap 7,907, and this is currently scheduled for inclusion for Fusaka. And in this presentation I'm looking at the version of 8 July 2,025. So that's from last week I just saw that there was a commit merge. But that didn't change a lot was just a clarification. And what it does is, it raises the Coder size limits from from 24 kB to 48 kB, so it doubles it. and it also introduces

this this metering formula for large code sizes. So you pay more for large code, so that that all looks very logical. And and this so if we would raise the code size limit. Again. then we would also use this formula again, if we if we raise the this limit. and how I'm thinking about this eap currently is also that we are basically using this as a framework for the future to handle or price in these even bigger contracts. And that's maybe also to think about how accurately present this this. Yeah in this presentation. And and I want to mainly to to raise that point. To think about this is because we currently want to introduce this mechanism.

and if we change it later, that would not be nice. Because then we have this historical code steps. So it would be nice to just do it right on the 1st try? Basically. So this pricing formula, how does it work? And the 1st thing what it does is it introduces a new, warm, and cold state. So what we currently have is that we have a warm and cold state for every account. Each time that you read a new account which you have not touched into the current transaction. and that's when you move it from the cold state to a warm state. And yeah, so we have a warm and cold account. But we also have warm and cold code now. So if you read cold.

and this would move the codes from cold to warm, and the accounts would already be warmed up. So what's it's currently what you do is you have to pay 2,100 guests from cold code to make it bar. And for the big contracts we use this, we introduce this dynamic formula, this only kicks in. If you read bigger contracts than the current limit of 24 kB. And if you do that. then you have this formula, and what you essentially essentially do is that for every 32 Byte words which you which the code is over the original 24 kB limit is, you pay 4 extra guests. and this coder size feeding. This is actually a problem, because this coder size is something which you cannot directly read from the merkel particia tree.

And to actually read this from the data structure is what you do. Is you open the account from the Mpt. Then you read the code, hash. This points to the the entire code. And from that you can actually read the code size. So this code size is not part of the account. And and if we will use that. So we are not going to do any optimizations in our well, in our clients data structure, we have a dose factor. And this dose factor is that we can read N. Times, Z. Bytes of data per transaction. This nest amount of context which we can, that we can read per day transaction. And this is currently, if we will take the 30 million guest limit.

This is about 11,000 contracts. and that is this maximum code size. And just as an illustration. How would you do this? What you do is you have a proxy contract you call into this contact from? Well, I can call it a tech contract. We give us the exact amount of guess which we would have to use to read this contract, but only to read the the 24 kB contract. So not the bigger contract. And if we do this for bigger contracts, then we can actually pay the static cost. But we cannot pay for the dynamic cost. And the problem here is that if we have to calculate what the dynamic cost is, we need to know the code size. And because we need to know the Coder size. This means that we have to read. If we do not have this optimization, we have to read

entire codes from the merkel partition tree. And of course, we can get around this by this optimization. But yeah, this is then so yeah, this is basically an implicit optimization which every client then has to use. and there is also a new row here. I will share the presentation after this, by the way, in the execution spec test repository. So you can also see in practice how this would look. So, as I said, the solution for this problem is that, well, we have this code hash, decoder sites and implicit or mandatory lookup cache. or what would maybe be nicer, is to add this coda size to the account rop. And what we'll do then is we could either introduce a new account in the account rop, or we could do something else like encode in an already existing field like in the nuance.

There are, of course, many variations for this to do this. There are also some other possible problems which I might see is that if you bump the Coder size, we also have this bigger witness size. Because currently, in the Coder witness, we have to add the entire code to the witness. And another problem which I can see that's more from an economical perspective, is that we have to wait for we have to pay for all the codes. So if you are calling a contract which is big, then you have to pay this dynamic cost for all the codes. and my main concern is that we would end up well in the end, that people will still split up the contracts into multiple contracts to avoid that, people are paying for for these big contracts if they are not using this.

So you are actually paying for what you are using. And as an example, here we have this big contract here, and if you use all the code in this big contract in your transaction, then it's fine. We just pay this extra gas. But what if this is, for instance, like an esc, 20 contract, we have this transfer method, which is a very small method itself. Then at some point as an contract offer, we might realize, okay, I don't want that. All my users are going to pay this extra fee for reading all this code. So what I can then do is I can just split up my big contract into smaller contracts. And okay, I've only put one here, but I will put my popular methods in the root contracts, and then I will put the unpopular methods into all the contracts, such as I am only paying for calling these methods when I actually need those.

And this 3,000 cost is only for the 48 kB. But what if we would raise this code even further, for instance, to the 256 kB. This would actually cost 30,000 extra gas per call. And yeah. I could imagine that we don't want our users to actually pay this impacted. And that will mean that we will end up splitting up our contacts again. But yes, if we would do that in practice. That's essentially some kind of code imagalization. because in the end we want to pay for what we use, and not that we are paying for everything in which we are loading. So just to quickly go over these concerns again. The main concern which I have is it's implicit code hash to the code size lookup, cache.

I don't think we have ever done this before, but I might might have missed something, but I don't think we've ever done this before in a network upgrade that we have this implicit well, new data structure. And yeah, which is, yeah, which which we would need. I'm also not sure what would economically happen with this? Yeah, with having to pay for these big contracts that you have to pay for all the code which you load. So are we going to see that contacts are actually going to be split up? The other concern is that? Well, what if we will change, for instance, in Glamsterdam our strategy again. Then we still have this coded depth that we have changed. We have added added this pricing formula, and then we'll change it again.

and also things which we should solve also so much short term like, okay, we now reach 4, 4, guess by 32 Byte words. Is this too much. Is this too cheap? Well, we don't know. We should solve this. and these are, of course, like some small things which we can all fix on the fly. But there are also some things to think about like, okay, we have this 2,100 extra gas to pay. If you read the new account. If you read the code and currently, in the specifications, you also have to pay this code, if you want to. For instance, transfer, if you to an Eoa, so we would call an Eoa. Then we also have to pay this 2,100 extra gas, even though we know that this account does not have any code in it.

and also in the terms of testing this, I think that testing the current ep is very big to test. because we have this extra warm slash, cold category of accounts. So the account is warm and cold, and also the code is warm and cold. And yeah, my final thoughts is, I want to stress that I really know that this 24 kB is super small, and we should change it. We should raise it. But we should also think of the side effects what this might imply and introduce. And yeah, that was my my talk. I will share the slides afterwards. Yeah, any questions. or maybe maybe let's read it yet. Okay, Barnabas is saying, could you not just charge for the worst case scenario?

yeah. The answer was already saying this, this will very likely break existing contracts. And we also have to think about this because this is like basically like an aggressive way to solve this problem. But this would work in the current context, maybe for 48 kB, that this might break a very small amount of contracts. But what if we would think of expanding this further to like, for instance, the 256 kB that would mean that you have to pay upfront the 30,000 gas. And that's, of course, a lot. So I do not see this this happening and a static cost. Yeah, the the problem is still that. Yeah, that this will very likely break a lot of contracts.

So yes.

Parithosh Jayanthi: Rather than.

Dragan Rakita: Joshua. I think we had this discussion already in the discord. So I don't see those responses that you basically see from both Charles and Ben addressed here. So maybe we can from the previous slide. Maybe we could go through the list that you made. and you try to address them concerns basically all of them. Why, I think most of them are already addressed in the discord. So. for the sake of discussion, you should be good to address them here.

Jochem Brouwer: Okay, could you? Maybe because I know we discussed this. But I think.

Parithosh Jayanthi: Yeah, I was not. Come on. Maybe give us a summary of what was discussed on this call.

Jochem Brouwer: Least, yeah.

Parithosh Jayanthi: To these concerns.

Dragan Rakita: For example, implicit code, hash, code, size, lookup, cache. Do you remember what was discussed there? I think clients I can. It's hard to speak for all of them. but I think they're fine even to. We had discussed this in Berlin to make this implementation detail. Some clients are going to add this field inside accounts. Some of them are going to add this inside the bytecode. They're going to read from. Some of them are need. They're in need of this additional table. But even that lookup on that new table is a lot easier than traversing the tree or anything like that. It's a lot faster. Ben is even proposing to drop that static gas cost that we currently have.

And he seems reasonable. Unclear. What economically happens? Split contract up, I think, Charles. and we we bend, and Ben said that there is big incentive to extend, even pay higher gas, because the split of the contract is very hard.

Charles Cooper: Yeah.

Dragan Rakita: So.

Charles Cooper: I can add a little bit more to that, basically. Yes, you pay for loading the whole contract. But the developer knows this. And so it's a trade-off whether they want to like split some cold paths into like another auxiliary contract. This is actually what I imagined when I drafted Eip 7,903, which doesn't touch the runtime code size at all. But it just increases the init code limit. So that in theory you can have a really really big creation code and create, I guess, like a a single logical contract which has a a lot of physical auxiliary contracts which hold all the code. But this isn't so easy to implement. And because code might be shared between different parts of the contract. So if you imagine, like in the Rc. 20, transfer and transfer from

functions, they might share some code internally, and if they're in the same contract, then everything is fine, because they just jump to the same internal function. But if the developer or the compiler has to split them across contracts, then the code has to be duplicated. So you don't necessarily get a benefit of like if you split some contract into N different smaller contracts that the size of each auxiliary contract is one over N. There may be a lot of overhead for sharing, and in some pathological cases like there may be very little benefit to splitting the contract.

Dragan Rakita: So last codeept. I'm not sure how exactly the end goal of the byte code loading is going to be. Maybe it's going to be chunking. Maybe it's going to be something else. That's basically there wasn't any discussion in. When that's going to happen. It will probably going to be depending on the Zk vm, or Zk Vm. World. or how we are going to facilitate that a little bit easier. You learn more.

Guillaume Ballet: Yeah. So the way you solve it in Zkvms is precisely to introduce code chunking. Because if you don't, then you have all those prover killers. You can just call xcode size very, or xcode hash, or whatever actually, code hash doesn't matter. But you can. You can call all those functions that load the entirety of the code, and it will make the provers. Om. So I don't think you can go around chunking, so there's no way you cannot do code chunking.

Dragan Rakita: I would agree with that to be honest, but at this point of time it's maybe some new novelty will come.

Charles Cooper: Yeah, how feasible is it to introduce code chunking in the near future, like, let's say, the 6 month, one year timeframe.

Guillaume Ballet: Well, 6 months. It depends on Glamsterdam, the scheduling of Glamsterdam. So if you believe Glamsterdam can come. Q. 1, 2026. Yeah, I would say, it's probably doable. But yeah, like, I said, it depends on the on the timeline. How easy is it to do? Well, there's an eip that just got resurrected 2926 of which I happen to be the co-author, and trying to introduce this without all the frails of changing a tree, the tree structure just doing what we learned from Verco and from binary trees, and do it in the Mpt. So how is it? How realistic, is it? I'm not promising 6 months. But yeah, it's still quite realistic.

Dragan Rakita: In general code chunking requires some kind of tree changes while this doesn't. So I think code tracking is a better solution. But I think the Glam Glam standarm is going to be ball or some other Aips. so I'm not sure if we have the space for the trunking.

Guillaume Ballet: If if I may disagree changes has been pretty simple has been demonstrated, and it's only unlike the big tree change. It's only 10 GB that need to be copied so that can be done in a day, if not an hour. I think I think it's pretty it's pretty realistic. And I would contend that writing like creating code that is going to be obsolete. Because once again, code shunking is. I mean, okay, pending a huge discovery that no one has made so far. It's the only way you're going to allow for Zkvms. So yeah, like, you will need to do it eventually, I would say, might as well do it right. The 1st time.

Dragan Rakita: You will still need to code load, and that notion of the warm and cold loading.

Guillaume Ballet: Yeah. So it's not going to be.

Dragan Rakita: This aip. It's going to change how the gas is calculated. But the structure is still going to be there some way or form.

Guillaume Ballet: Absolutely, the gas computation has to match basically what we do in vertical or binary trees, like 4,762, you will need to charge per load per code load. That's not a big problem. It's just basically the same idea as is present in 7,907. I find the numbers in 7,507 really low, but I'm happy to change them if it makes sense. I'm happy to lower the number from 4,762. But once again, this is something that we have understood for over 4 years now. So it's pretty easy to do.

Parithosh Jayanthi: Okay. Couple of conversations from chat, perhaps for the 1st one. We're talking about code size data structure being an implementation detail. And one of the asks was, a, which clients do need to have it, and B. If they do need to have it, could we agree to have it at Fusaka. Devnet. 3. And if so, what would the timeline be there? Because if this is going to be a part of the critical part. Then we have to get that. It will be a delay, and we have to figure out what sort of delay we're accepting.

Guillaume Ballet: Yeah, it might be an implementation detail. But you will still need to go and build that index somehow. If you put it in the byte code. If you put it in the account wherever you put it, you will need to do exactly the same thing that a tree transition does. You will need to go over every code and go and put it there, or you will need to build that index. So I would say, from what I can see every client will actually need to build that index. because if they don't want to do some kind of process exactly like the tree transition.

Parithosh Jayanthi: Okay, that makes sense. And just surfacing maybe 2 more related points one from Marius saying that it's this. Yeah, he still feels under, explored or specified, and he doesn't think we should ship a half big solution, and Anskar already has his hand up, so I would let him speak, and probably also include his message from Chat.

Ansgar Dietrichs: Yeah, actually, I wanted to briefly. Just say, I think where I mostly agreed with Guillaume. I think actually, one thing, he said, is not quite right, because I don't think there would be the need to populate the code size index with for existing contracts. I mean again, that also would be an implementation detail for clients that for some reason would want to do that. That's fine. But you wouldn't have to do it right, because you know that up to the Fork boundary. All contracts are below the 24 kB limit, and that's the only information you need for them. You don't need the exact size. You just need that. It's below the 24 kB. So basically, if you just don't find it in the index, you know, it's below 24. And so that's

all you need. So you don't need to go and rotate through the existing contract. So just a small thing that makes it actually simpler. yeah. My comment in chat was specifically like, I would argue that we should make it a hard requirement that before we actually like make the very final call for having 7, 9, 0 7 in Fusaka, that we have high quality benchmarks that show that all clients can handle these kind of worst case load patterns at a hundred 1 million throughput. A post post 7, 9 or 7 live. and that probably means all of them need to have the index implemented. Of course, if some clients, for some reason just, are performing enough, even without the index to do that, all the better. But basically, I would argue that we should officially say, Look, we need to be 100% certain that this will not introduce a new performance bottleneck here. Otherwise we'll pull it out.

Parithosh Jayanthi: That's fair, but that sounds like it will still take some time before we 1st have the index implemented, and do the benchmarks right.

Ansgar Dietrichs: Well, yeah, basically, the argument is implicitly, if we feel like we can't do that in time. Or basically, we will only have that. Those numbers say 2 months from now, because it takes time to implement the index, and 2 months from now it's too late to pull it back out then that I would argue that should mean we should just pull it out immediately, because we don't have that databases. If it is realistic. If all the clients say that is realistic to get those benchmark numbers in time to make the final go. No, go decision, then. I'm personally happy to keep it in, for now.

Parithosh Jayanthi: Okay, I do. Wanna maybe mention one thing. This discussion topic is also slated for Acde. The idea was that Joachim presents all of the information. Here we have a 1st discussion. If there was any information required to be collected over the course of this week, then that, and then present to get an acde. And that's where we would potentially make a decision of how we move forward with the eip. That being said, I think Drakman wanted to say something, and then Ben.

Dragan Rakita: Yeah, I would like to wait the client's opinion on this, because we're talking about if the clients can handle this kind of like new Ddos attacks that could potentially happen. I didn't hear anybody concerned about that other than we should test it. So I would take that opinion in discussion.

Parithosh Jayanthi: Could you repeat that point, please? What ddos attack? Do you mean.

Dragan Rakita: I was gonna do the metric, because if we have 100 million, if all clients can handle Aip 7, 9, 0 7 or 100 million. it should be okay. But yeah, Marius, what's your concern?

Marius van der Wijden: I, and like, we still don't really have good reliable numbers on this, you know, like we, we have some tests for it. But the problem with the tests is that they like potentially, potentially, even with 24 k. you can pull up something like one and a half gigabytes or or something of of of contracts with with at a hundred 1 million you can a hundred 1 million like 128 pay contracts. You can pull out like something like 10 or 11 GB. So that is like, it's just a huge amount of data that you need to load from disk in a very short amount of time. And the the thing is the tests that we have, I think, for, like

45 million gas, we're not wrong with a hundred 1 million gas. and only for like for small like, not the full amount of contracts. And they yeah, like, if the if the con like, it's kind of hard to like you can, you can. You can create a bunch of interesting edge cases, contracts, calling contracts, calling contracts, doing a bunch of jump test analysis. And I just don't see this. All of this being as easy as people think.

Dragan Rakita: My question is, Does this is still concerned. Without adding this aip, even with 24 k. You will, if you have, conserve with 48, you will have conserve with 24. It's not. We are tripling the size in this aip. That's why we're just doubling it.

Marius van der Wijden: Yeah, I I do. I do have similar concerns with 24 k. Add a hundred 1 million guests.

Dragan Rakita: So it's not exactly the problem with IP with, but with different issues that we need to address.

Charles Cooper: The effective rate is at 2,600 gas for 24 kB is 3.3 8 gas per word. A recent change was to forecast per word for the marginal cost, which I personally think is excessive. But even if so, with the cip, it's actually more expensive to load. a very large contract and multiple small countries.

Parithosh Jayanthi: Ben, do you wanna go? And then Julio.

Ben Adams: Yeah, are we 100% certain that there are no contracts above 24 kB that were created before the limits were put in.

Parithosh Jayanthi: Joachim says yes, a hundred percent. Julio.

Giulio Rebuffo: Yeah, I just wanted to say whether it is we are still in time to maybe just just to bump simply the limit without 7 9 0. 7 at this point. But if it's too late.

Parithosh Jayanthi: Yeah, I think that would have to be something we have to print as an option on acde But it is probably a realistic option.

Giulio Rebuffo: Yeah, okay.

Parithosh Jayanthi: Also this timeline perspective wise we are in mid July, and I think if we want to have any hope of having Fusaka done before that connect this year. We do need to already start talking about hardening our our fork and shipping it, instead of figuring out the constraints of the fork. What would be asked from this discussion. Then what are data points that we can still collect? It seems like one could be that we benchmark, how things look at a hundred 1 million. There is still no index, but it could still help us at least get some initial data points as to how clients perform at 100 million. Are there any other asks from this discussion before Thursday?

Yeah. Milan.

Milen Filatov: Yeah, Hi, it's not an ask, but more of a question. so I was thinking a few days ago that there's currently 2 Aips about limiting the transaction gas limit. and the 1st one is 30 million, which I think is going into Osaka. But then there's another one that I saw that further lowers this down to 16 million. And if you have a 16 million gas transact gas transaction limit, you're actually have an upper bound on like what is the largest contract codes that you can deploy, which I don't know. Haven't done the maths, but like it's quite low, like it's I don't know. 80, let's say, 80 kB. So the in in my head there, there's 2 things that are competing here, and if we're gonna introduce

such aps in the future with 16 million transaction. That's limit size. Then we shouldn't really be discussing like 256 kB quote size, because I'm not sure how we're gonna deploy these so kinda I feel like all these worries are kind of being a bit exaggerated because I don't see how we would deploy such like large contracts if we have such a low transaction gas limit.

Parithosh Jayanthi: Yeah, I'd imagine that in the future we, if we do have higher contract limits, we also increase the transaction gas limit. But, I don't think we've thought that approach fully through yet. Sorry. Just trying to quickly catch up on the chat. Is there any specific message people want to bring back to the call. Well, I just.

Ben Adams: Slide to follow up on Melan's Point that 16 million is in Devnet 3 it got reduced. So you might want to implement that if you haven't.

Milen Filatov: Okay, yeah. So I mean, that means that we're even for definitely 3, we're sort of limited, quite a lot in terms of like, what is the theoretical Max code size that you can deploy? See? I'm I'm not sure why, like it's a concern. Why, we're discussing 256 kB when we actually can't really reach that.

Marius van der Wijden: Because in the future you might be able to awesome.

Milen Filatov: Even with with low transaction gas limit and 60 million.

Marius van der Wijden: No, but maybe in the in the future, deploying a contract will be cheaper. Maybe in the future we will remove the transaction gas cost limit like there's no point in specifying that we want to have a hundred, 28 kB contracts. If we will not be able to deploy 128 kB contracts. So at some point either the the camp will go or we will have some other mechanism of deploying big contracts, or like. maybe maybe even just L twos will will remove the contract the the transaction cap. But even then, we should be making these these test cases and these benchmarks to see. Is it actually safe even for you to to have this? These large contracts.

Dragan Rakita: In general, I would say that this a lot depends on client implementations. so I would like to hear from clients on few days on acde if they think that this is going to be problematic or not even.

Parithosh Jayanthi: Yeah, I think.

Dragan Rakita: Okay.

Parithosh Jayanthi: That can be concrete? Asks so clients would need to come to acde with a opinion on how difficult it would be to implement the index. The second one would be if they would imagine that it's problematic for larger contract contact sizes. And the 3rd one is we would need to get benchmarks at a hundred 1 million to make sure that we're not bottlenecking on a new front before we even get to 100 million. Yeah, you have them.

Jochem Brouwer: Yeah, one question is because we need these benchmarks. But what benchmarks do we need? Specifically because I did not get that? Is it, Jim test? Is it code reading? Is it? What is it.

Parithosh Jayanthi: Well, which of the parts mainly stresses the client the most? Yeah, maybe Tony has an answer, Tony. or is it a different topic.

Toni Wahrstätter: No, I have a different one.

Parithosh Jayanthi: Okay, then let's finish this 1 first.st does any client team have, like concrete assumptions of what the Ddos attack would be or what the attack would be.

Dragan Rakita: Marius, do you have example?

Marius van der Wijden: Yes. So, what I would like to see is. and I think you already implemented. This is just touching contract. I don't know where you get the 11 K number from, because when I computed it, it's like 36 K contracts that you can touch at a hundred.

Jochem Brouwer: Yeah, sorry. That's that's per per transaction. What I'm talking about, not per block. But yeah.

Marius van der Wijden: Per transaction. Oh, yeah. So I'm yeah. I was when when I did this test, it was it was per 100 million transaction or per block and so I could touch 36 k. Contracts. Hmm, and then Every contract contains a bunch of junk dust and then jumps to the end of the contract so that it also triggers the jump desk analysis, or contains randomness, whatever you want to do, and then the other one that I would like to see is hmm contracts that call other contracts. 1024 layers deep, and all of them will will have to be will have to stay in memory. And then and then it goes basically goes back up one step, and then it calls into a second.

another 10 like another contract, and then goes back up a step and bought into another contract. So you have this chain of big contracts that call each other. The other stuff is like X code size at a hundred 1 million without the indices. And then X code size at a hundred 1 million with an index. And yeah, I think those those are the main ones that I would like to see.

Jochem Brouwer: Yep. Cool. Thank you.

Dragan Rakita: General, I'll code code size. A code analysis is going to be because we are spending more gas with the big code loading. It would be better with this IP, so the attack is mostly concerned about older current present bytecode, and even it's Aip 7, 9 0 7. We have additional cost static cost for loading the code. So we will reduce the attack vector with the cip. If this cost is here.

Marius van der Wijden: Oh, 1 1 other thing is like calling a contract and then reverting because you don't at the the required gas to do the to pay for loading the contracts. That would that would trigger this edge case where you also need the the index for it right.

Parithosh Jayanthi: Okay, I'd like to stop the 7, 9 0, 7 discussion here, and then maybe to 20.

Toni Wahrstätter: Yeah, just regarding the transaction gas limit. 7, 8, 25. I put it on to the. So last week after the testing call after we. and loaded from 30 million to 16,000,060.7 million. I put it on onto the Ecde agenda this week. So I think we we should discuss it there again.

Parithosh Jayanthi: Yeah, perfect. Thank you. And Barnabas, do you have some update on Devnet? 3. Planning, what else is left over before we launch Devnet 3. And what's the timeline there.

Barnabas Busa: So this is probably one of the main blockers for devnetary, and not sure how clients are with the implementing. All the different repricing vips especially it should be up updated, and I think we only have 3 more open prs that needs to be merged before we can launch.

Parithosh Jayanthi: Okay, and I think one of them was the pr, I will merge during the call right.

Barnabas Busa: Oh, that has been there still. The yeah. Yeah. So the blob per transaction limit has been merged. So then there's 1 more for the execution. Api and the builder spec would also probably want like I I would like to get that all submersion.

Parithosh Jayanthi: Okay, that sounds good. Then I guess the after we have a decision on 7, 9 0, 7 on Ecd. On Thursday we should be have a we should have a timeline for definitely 3 as well. Yeah, we can discuss the yeah, we can discuss the execution. Api eip it's the one from rule about partial responses. Does someone have a status update on how this is going.

Raúl Kripalani: Yeah. So this was discussed in Acdc last week. There was a bunch of considerations there. But overall the sentiment was we should just push into it now, and there's been one approval, and we're just waiting to for more El and Cl. Devs to to chime in and just approve if they still see a fit before we go ahead and merge, and I think the idea is to freeze the the execution. Api spec. Soon. So this would be stopping, stopping it from that.

Parithosh Jayanthi: Okay, perfect. So let's try and get this eip as well emerged in before Thursday, and I think we should be very close to. Then figuring out a timeline for definitely 3 the Sunnyside Labs team wanted to give an update on their latest testing. Do you want to go.

J Sunnyside Labs: Yeah, sure. Thank you. Let me just post the link to the chat. yeah. So briefly, just summarizing what we have done. So we've ran every single cl devnets and er devnets, except for Nimbo CEO with 8 validators for full nodes this time, and then every single cl that nets were able to reach up to more than up to more than 60 blocks per block and nimbus, which previous pre previously was at 9 blobs during Berlin was able to reach up to 40 or more. Yeah. We also could confirm that. All the tested el clients supported more than 72 blocks per block

and we also then tested whether clients can sustain high blobs. high blood droplets, and we found with a hundred, 28 node mixed combinations. At 60 blocks per block for every block. On average we could maintain stable.net for 48 h. We then limited network bandwidth at 30 megabits per second which we found on single Cl devnets we were able to achieve around 60 blobs per block, and with the 128 node devnet we were able to achieve around 45 blobs. say. And then we looked at like what kind of things that limited the

block throughput on such bandwidth caps, and we found should both in track network traffics. Kind of bounded the network usage. the block, drop it limit, and other than that there were minor findings in the networking resource usage. We've also done Genesis sync test which we were able to confirm that all the Cls and Els passed except for Gath. But the fix for death is up in the review, so. I guess, like we are at pretty good stage at the moment, and, as Parish said, hardening the cls and Els for Fussaka will be quite important next steps by testing out edge cases and continue doing stress testing and interrupt testing.

Parithosh Jayanthi: Yeah, I think one So Barnabas had a couple of test scenarios that he wanted to see done. I think he sent you guys a list as well as including transactions in the devnets. Right? we spammer should have a bunch of scenarios, and I think we'd like to see a version of this benchmark result also with the default spammer transactions going in.

J Sunnyside Labs: Yeah, I I think Marius and Raoul also commented about that. So we should definitely add that to the next.

Parithosh Jayanthi: Perfect.

Raúl Kripalani: Yeah. So just to chime in here, there's there's a there's a bunch of things that this is great testing, and it's great that we have you to do it. Just to kind of like make it more realistic. There's a bunch of things here that I think we'll we'll need to do, we'll need to constrain the bandwidth, the upside, and the downside of the bandwidth. And differently, we'll need to have different types of nodes that follow the I think it's cip 7,870 specifications. So we'll need to have different, which which mandate different bandwidth requirements depending on the node profile. So we'll need to. We'll need to add that I think we'd benefit as well from backfill

tests that we do here. We do want to create blocks, for example, that are competing with blobs during propagation, and specifically blocks that are saturating the available blocks like that are saturating gas and creating pathologically large blocks to disseminate after compressed right? Because this is the object of dissemination. So things like that are things that I think will continue giving us way more signal. And yeah, and I think we also want to apply different latency distributions here. And we want to definitely capture the latency distributions that we've applied for each of these devnets. Another thing that we'll want to do, I think, is we'll want to constrain artificially, constrain the gossip parameters because these are small testnets. These are 50 nodes.

which means that there are very few hops if we're using the the gossip sub parameters of Mainnet. So we'll wanna artificially constrain those so that we're replicating the number of hops and kind of like the travel time that messages will have to do in Mainnet to get better signal. So so yeah, I'm I'm writing all of these things up. I'll I'll send you some feedback. And and yeah, Barnabas, happy to to integrate any any other tests you you want down here as feedback for sunny Satellite Stream.

Parithosh Jayanthi: Perfect. Thank you. Guys so much. Is there any other topic we want to talk about? There's a point from Francesco about skewing bandwidth findings. Maybe we take that one to discord, since what happened. And thank you. Everyone for joining. Okay, have a nice day.

Anders Kristiansen: So.

Toni Wahrstätter: Thank you. Bye-bye.

Jochem Brouwer: Thank you.

Antoine James: Thank you. Bye-bye.

Justin Traglia: Bye, thanks, everyone.

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