AllCoreDevs - Testing #044

|2025-07-14| Agenda: #1609| canonical JSON

Transcript

Pooja Ranjan:We are, live.

Parithosh Jayanthi:Thank you.

Parithosh Jayanthi: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: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,

Barnabas:we had a few

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

Barnabas: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:Nothing really like right now we are investigating some metadata box, that tech with the

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

Barnabas:And this is going to really help us Debug

Barnabas:smaller problems and figuring out if specific notice costing the columns that they say they would

Barnabas:still a bit work in progress. But hopefully,

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

Parithosh Jayanthi:Yeah. And Justin says there was a small nimbus issue that was fixed and new consensus specs.

Parithosh Jayanthi:yeah. And the result of verifies that Kcg proof patch wasn't being checked properly.

Parithosh Jayanthi:Thank you for the update

Parithosh Jayanthi:and on the topic of consensus specs. I also see this as one Pr from Leo that adds,

Parithosh Jayanthi: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

Justin Traglia: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: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: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

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

Parithosh Jayanthi:Is Bharat. On the call I saw he had posted a message with an update on med testing.

Bharath:Yeah. So I'm on the call. Yeah. So in terms of the update to the workflows

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

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

Bharath:it's working. I was able to see like blobs being produced locally and stuff.

Bharath:So yeah. So that's that's the update

Bharath:would love to get out on Devnet, too. But one of the problems

Bharath:you know, in having in the Tg chat with Roman is like.

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

Bharath: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: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:Yeah, yeah, that's that's the point.

Parithosh Jayanthi:Okay, perfect. Thank you for that.

Parithosh Jayanthi: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.

Parithosh Jayanthi:but we are aiming to have 2 times the

Parithosh Jayanthi: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

Parithosh Jayanthi: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.

Parithosh Jayanthi: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.

Parithosh Jayanthi:in terms of releases.

Parithosh Jayanthi:Okay? Then I guess we take that offline? At least the good thing is over the last week.

Parithosh Jayanthi: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?

Parithosh Jayanthi:yeah, we're still figuring out that indicate 30 million. Yes.

Parithosh Jayanthi: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

Parithosh Jayanthi:either tomorrow or later this week.

Parithosh Jayanthi:Okay, thank you for that.

Parithosh Jayanthi:There was one following topic for fusaka.net. 3. There's this open pr blob transaction limit that hasn't been merged yet.

Parithosh Jayanthi:Does someone want to give context here and figure out what's missing.

Barnabas:I think they are approved are missing. They've discussed this topic many times already on Acd. E. And as well

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

Barnabas:perfork.

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

Parithosh Jayanthi:Okay, does anyone have anything else to add for the topic? If not, we can move on.

Parithosh Jayanthi: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.

jochem-brouwer:Yeah. Can you see my screen and also my mouse?

Parithosh Jayanthi:Yes.

jochem-brouwer:Okay, great.

jochem-brouwer:All right. I wanted to bring up the well. The the big problem is, we want to raise the coder size limit.

jochem-brouwer:This seems like a trivial problem.

jochem-brouwer:But from my side this is not trivial to solve at all.

jochem-brouwer:We are currently introducing eap 7,907, and this is currently scheduled for inclusion for Fusaka.

jochem-brouwer: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.

jochem-brouwer:And what it does is, it raises the Coder size limits from from 24 kB to 48 kB, so it doubles it.

jochem-brouwer:and it also introduces

jochem-brouwer:this this metering formula for large code sizes. So you pay more for large code, so that that all looks very logical.

jochem-brouwer:And and this so if we would raise the code size limit. Again.

jochem-brouwer:then we would also use this formula again, if we if we raise the this limit.

jochem-brouwer:and how I'm thinking about this eap currently is also that we are basically using this as a framework

jochem-brouwer:for the future to handle or price in these even bigger contracts.

jochem-brouwer:And that's maybe also to think about how accurately present this this. Yeah in this presentation.

jochem-brouwer:And and

jochem-brouwer:I want to mainly to to raise that point. To think about this is because we currently want to introduce this mechanism.

jochem-brouwer: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.

jochem-brouwer:So this pricing formula, how does it work?

jochem-brouwer: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.

jochem-brouwer:Each time that you read a new account which you have not touched into the current transaction.

jochem-brouwer:and that's when you move it from the cold state to a warm state.

jochem-brouwer:And yeah, so we have a warm and cold account. But we also have warm and cold code now. So if you read cold.

jochem-brouwer:and this would move the codes from cold to warm, and the accounts would already be warmed up.

jochem-brouwer:So what's

jochem-brouwer:it's currently what you do is you have to pay 2,100 guests from cold code to make it bar.

jochem-brouwer: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.

jochem-brouwer:And if you do that.

jochem-brouwer: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.

jochem-brouwer: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.

jochem-brouwer:And to actually read this from the data structure is what you do. Is you open the account from the Mpt.

jochem-brouwer: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.

jochem-brouwer:And

jochem-brouwer: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.

jochem-brouwer:And this dose factor is that we can read N. Times, Z. Bytes of data per transaction.

jochem-brouwer: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.

jochem-brouwer:This is about 11,000 contracts.

jochem-brouwer:and that is this maximum code size.

jochem-brouwer:And just as an illustration. How would you do this?

jochem-brouwer:What you do is you have a proxy contract

jochem-brouwer: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.

jochem-brouwer:And if we do this for bigger contracts, then we can actually pay the static cost.

jochem-brouwer: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

jochem-brouwer:entire codes from the merkel partition tree.

jochem-brouwer:And of course, we can get around this

jochem-brouwer:by this optimization. But yeah, this is then so yeah, this is basically an implicit optimization which every client then has to use.

jochem-brouwer: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.

jochem-brouwer: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.

jochem-brouwer:or what would maybe be nicer, is to add this coda size to the account rop.

jochem-brouwer: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.

jochem-brouwer:There are, of course, many variations for this to do this.

jochem-brouwer: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.

jochem-brouwer:And

jochem-brouwer: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.

jochem-brouwer:So if you are calling a contract which is big, then you have to pay this dynamic cost for all the codes.

jochem-brouwer: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.

jochem-brouwer: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

jochem-brouwer: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

jochem-brouwer: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.

jochem-brouwer: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.

jochem-brouwer: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.

jochem-brouwer:But yes, if we would do that in practice. That's essentially some kind of code imagalization.

jochem-brouwer: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.

jochem-brouwer:So just to quickly go over these concerns again.

jochem-brouwer:The main concern which I have is it's implicit code hash to the code size lookup, cache.

jochem-brouwer: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.

jochem-brouwer:And yeah, which is, yeah, which which we would need.

jochem-brouwer: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?

jochem-brouwer: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.

jochem-brouwer:and also things which we should solve also so much short term like, okay, we now reach 4, 4, guess by 32 Byte words.

jochem-brouwer:Is this too much. Is this too cheap? Well, we don't know. We should solve this.

jochem-brouwer: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.

jochem-brouwer:and also in the terms of testing this, I think that testing the current ep is very big to test.

jochem-brouwer: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.

jochem-brouwer: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.

jochem-brouwer:But we should also think of the side effects what this might imply and introduce.

jochem-brouwer:And yeah, that was my my talk. I will share the slides afterwards. Yeah, any questions.

jochem-brouwer:or maybe maybe let's read it yet.

jochem-brouwer:Okay, Barnabas is saying, could you not just charge for the worst case scenario?

jochem-brouwer: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.

jochem-brouwer: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

jochem-brouwer:I do not see this this happening and a static cost.

jochem-brouwer:Yeah, the the problem is still that.

jochem-brouwer:Yeah, that this will very likely break a lot of contracts.

jochem-brouwer:So yes.

Parithosh Jayanthi:Rather than.

draganrakita:Joshua. I think we had this discussion already in the discord.

draganrakita:So I don't see those responses that you basically see from both Charles and Ben addressed here.

draganrakita:So maybe we can from the previous slide. Maybe we could go through the list that you made.

draganrakita:and you try to address them

draganrakita:concerns basically all of them. Why, I think most of them are already addressed in the discord. So.

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

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

jochem-brouwer:Least, yeah.

Parithosh Jayanthi:To these concerns.

draganrakita:For example, implicit code, hash, code, size, lookup, cache. Do you remember what was discussed there?

draganrakita:I think clients I can.

draganrakita:It's hard to speak for all of them.

draganrakita:but I think they're fine even to.

draganrakita:We had discussed this in Berlin to make this implementation detail.

draganrakita:Some clients are going to add this field inside accounts. Some of them are going to add this

draganrakita:inside the bytecode. They're going to read from.

draganrakita:Some of them are need. They're in need of this additional table.

draganrakita:But even that lookup

draganrakita:on that new table is a lot easier than traversing the tree or anything like that. It's a lot faster.

draganrakita:Ben is even proposing to drop that static gas cost that we currently have.

draganrakita:And he seems reasonable.

draganrakita:Unclear. What economically happens?

draganrakita:Split contract up, I think, Charles.

draganrakita:and we we bend, and Ben

draganrakita:said that there is big incentive to extend, even pay higher gas, because the split of the contract is very hard.

Charles:Yeah.

draganrakita:So.

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

Charles:But it just increases the init code limit. So that in theory you can have a really really big creation code and

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

Charles:code might be shared between different parts of the contract. So if you imagine, like in the Rc. 20, transfer and transfer from

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

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

draganrakita:So last codeept.

draganrakita:I'm not sure how exactly the end goal of the byte code loading is going to be.

draganrakita:Maybe it's going to be chunking. Maybe it's going to be something else.

draganrakita:That's basically there wasn't any discussion in.

draganrakita:When that's going to happen. It will probably going to be depending on the Zk vm, or Zk Vm. World.

draganrakita:or how we are going to facilitate that a little bit easier.

draganrakita:You learn more.

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

Guillaume:I don't think you can go around chunking, so there's no way you cannot do code chunking.

draganrakita:I would agree with that to be honest, but at this point of time it's

draganrakita:maybe some new novelty will come.

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

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

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

Guillaume:So how is it? How realistic, is it?

Guillaume:I'm not promising 6 months. But yeah, it's still quite realistic.

draganrakita:In general code chunking requires some kind of tree changes while this doesn't.

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

draganrakita:so I'm not sure if we have the space for the trunking.

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

Guillaume:a day, if not an hour.

Guillaume:I think I think it's pretty it's pretty realistic.

Guillaume:And I would contend that writing like creating code that is going to be obsolete. Because once again, code shunking is.

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

draganrakita:You will still need to code load, and

draganrakita:that notion of the warm and cold loading.

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

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

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

Parithosh Jayanthi: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?

Parithosh Jayanthi: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: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.

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

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

Ansgar Dietrichs:all you need. So you don't need to go and rotate through the existing contract. So just a small

Ansgar Dietrichs:thing that makes it actually simpler.

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

Ansgar Dietrichs:high quality benchmarks that show that all clients can handle these kind of worst case load patterns at a hundred 1 million throughput.

Ansgar Dietrichs:A post post 7, 9 or 7 live.

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

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

draganrakita:I didn't hear anybody concerned about that other than we should test it.

draganrakita:So I would take that opinion in discussion.

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

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

draganrakita:it should be okay. But yeah, Marius, what's your concern?

Marius van der Wijden:I,

Marius van der Wijden: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

Marius van der Wijden:like potentially, potentially, even with 24 k.

Marius van der Wijden:you can pull up something like one and a half gigabytes or or something of of of contracts

Marius van der Wijden:with with at a hundred 1 million you can a hundred 1 million like 128

Marius van der Wijden:pay contracts. You can pull out like something like 10 or 11 GB.

Marius van der Wijden:So that is like, it's just a huge amount of data that you need to load from disk

Marius van der Wijden:in a very short amount of time.

Marius van der Wijden:And the the thing is the tests that we have, I think, for, like

Marius van der Wijden:45 million gas, we're not wrong with a hundred 1 million gas.

Marius van der Wijden:and only for like

Marius van der Wijden:for small like, not the full amount of contracts.

Marius van der Wijden:And they yeah, like, if the if the con like, it's kind of hard to

Marius van der Wijden:like you can, you can. You can create a bunch of

Marius van der Wijden:interesting edge cases, contracts, calling contracts, calling contracts, doing a bunch of jump test analysis.

Marius van der Wijden:And I just don't see this.

Marius van der Wijden:All of this being as easy as people think.

draganrakita:My question is, Does this is still concerned. Without adding this aip, even with 24 k.

draganrakita:You will, if you have, conserve with 48, you will have conserve with 24.

draganrakita:It's not. We are tripling the size in this

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

Marius van der Wijden:Add a hundred 1 million guests.

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

Charles:The effective rate is at 2,600 gas for 24 kB is 3.3 8 gas per word.

Charles:A recent change was to forecast per word for the marginal cost, which I personally think is excessive. But

Charles:even if so, with the cip, it's actually more expensive to load.

Charles:a very large contract and multiple small countries.

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

Ben Adams:Yeah, are we 100%

Ben Adams:certain that there are no contracts above 24 kB

Ben Adams:that were created before the limits were put in.

Parithosh Jayanthi:Joachim says yes, a hundred percent.

Parithosh Jayanthi:Julio.

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

Parithosh Jayanthi:But it is probably a realistic option.

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

Parithosh Jayanthi:our fork and shipping it, instead of figuring out the constraints of the fork.

Parithosh Jayanthi: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?

Parithosh Jayanthi:Yeah. Milan.

milen | Erigon:Yeah, Hi, it's not an ask, but more of a question.

milen | Erigon:so I was thinking a few days ago that there's currently 2 Aips about limiting the transaction gas limit.

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

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

milen | Erigon:deploy, which I don't know. Haven't done the maths, but like it's

milen | Erigon:quite low, like it's I don't know. 80, let's say, 80 kB.

milen | Erigon:So the in in my head there, there's 2 things that are competing here, and if we're gonna introduce

milen | Erigon:such aps in the future with 16 million

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

milen | Erigon:so kinda I feel like all these worries are kind of being a bit exaggerated because

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

Parithosh Jayanthi:Sorry. Just trying to quickly catch up on the chat. Is there any specific message people want to bring back to the call.

Parithosh Jayanthi:Well, I just.

Ben Adams:Slide to follow up on Melan's Point that 16 million is in Devnet 3 it got reduced.

Ben Adams:So you might want to implement that if you haven't.

milen | Erigon:Okay, yeah. So I mean, that means that we're even for definitely 3, we're sort of limited, quite a lot

milen | Erigon:in terms of like, what is the theoretical Max code size that you can deploy?

milen | Erigon:See? I'm I'm not sure why, like it's a concern. Why, we're discussing 256 kB when

milen | Erigon:we actually can't really reach that.

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

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

Marius van der Wijden:there's no point in specifying that we want to have a hundred, 28 kB contracts.

Marius van der Wijden:If we will not be able to deploy 128 kB contracts.

Marius van der Wijden:So at some point either the the

Marius van der Wijden:camp will go or we will have some other mechanism of deploying big contracts, or like.

Marius van der Wijden:maybe maybe even just L twos will will remove the contract the the transaction cap.

Marius van der Wijden: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.

draganrakita:In general, I would say that this a lot depends on client implementations.

draganrakita:so I would like to hear from clients on few days on acde

draganrakita:if they think that this is going to be problematic or not even.

Parithosh Jayanthi:Yeah, I think.

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

Parithosh Jayanthi: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?

Parithosh Jayanthi:Yeah, maybe Tony has an answer, Tony.

Parithosh Jayanthi:or is it a different topic.

Toni Wahrstaetter: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

Parithosh Jayanthi:or what the attack would be.

draganrakita:Marius, do you have example?

Marius van der Wijden:Yes.

Marius van der Wijden:So, what I would like to see is.

Marius van der Wijden:and I think you already implemented. This is

Marius van der Wijden: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

Marius van der Wijden: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.

Marius van der Wijden:So I'm yeah. I was when when I did this test, it was

Marius van der Wijden:it was per 100 million transaction or per block

Marius van der Wijden:and so I could touch 36 k. Contracts.

Marius van der Wijden:Hmm, and then

Marius van der Wijden:Every contract contains a bunch of junk dust

Marius van der Wijden:and then jumps to the end of the contract

Marius van der Wijden: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

Marius van der Wijden:hmm contracts that call other contracts.

Marius van der Wijden:1024 layers deep, and all of them

Marius van der Wijden:will will have to be will have to stay in memory.

Marius van der Wijden:And then and then it goes basically goes back up one step, and then it calls into a second.

Marius van der Wijden:another 10 like another contract, and then goes back up a step and

Marius van der Wijden:bought into another contract. So you have this chain of

Marius van der Wijden:big contracts that call each other.

Marius van der Wijden:The other stuff is like X code size at a hundred 1 million without the indices.

Marius van der Wijden:And then X code size at a hundred 1 million with an index.

Marius van der Wijden:And yeah, I think those those are the main ones that I would like to see.

jochem-brouwer:Yep. Cool. Thank you.

draganrakita:General, I'll code code size. A code analysis is going to be

draganrakita:because we are spending more gas

draganrakita:with the big code loading. It would be better with this IP,

draganrakita:so the attack is mostly concerned about older current present bytecode, and even

draganrakita:it's Aip 7, 9 0 7.

draganrakita:We have additional cost static cost for loading the code.

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

Marius van der Wijden:calling a contract and then reverting because you don't at the

Marius van der Wijden:the required gas to do the

Marius van der Wijden:to pay for loading the contracts.

Marius van der Wijden: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 Wahrstaetter: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.

Toni Wahrstaetter: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

Toni Wahrstaetter:we should discuss it there again.

Parithosh Jayanthi:Yeah, perfect. Thank you.

Parithosh Jayanthi: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:So this is probably one of the main blockers for devnetary, and

Barnabas: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:Oh, that has been there still.

Barnabas:The yeah. Yeah. So the blob per transaction limit has been merged. So then there's 1 more for the execution. Api and

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

Parithosh Jayanthi:Yeah, we can discuss the

Parithosh Jayanthi:yeah, we can discuss the execution. Api eip it's the one from rule about partial responses.

Parithosh Jayanthi: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.

Raúl Kripalani: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

Parithosh Jayanthi: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.

J Sunnyside Labs:yeah. So briefly, just summarizing what we have done. So we've ran

J Sunnyside Labs:every single cl devnets and er devnets, except for Nimbo CEO

J Sunnyside Labs:with 8 validators for full nodes this time, and then

J Sunnyside Labs:every single cl that nets were able to reach up to more than up to more than 60 blocks per block

J Sunnyside Labs:and nimbus, which previous pre previously was at 9 blobs during Berlin

J Sunnyside Labs:was able to reach up to 40 or more.

J Sunnyside Labs:Yeah. We also could confirm that. All the tested el clients supported

J Sunnyside Labs:more than 72 blocks per block

J Sunnyside Labs:and we also then tested

J Sunnyside Labs:whether clients can sustain high blobs.

J Sunnyside Labs:high blood droplets, and we found with a hundred, 28 node mixed combinations.

J Sunnyside Labs:At 60 blocks per block for every block. On average we could maintain stable.net for 48 h.

J Sunnyside Labs:We then limited network bandwidth at 30 megabits per second

J Sunnyside Labs:which we found on single Cl devnets we were able to achieve

J Sunnyside Labs:around 60 blobs per block, and with the 128 node devnet we were able to achieve around 45 blobs.

J Sunnyside Labs:say. And then we looked at like what kind of things that limited the

J Sunnyside Labs:block throughput on such bandwidth caps, and we found

J Sunnyside Labs:should both in track network traffics. Kind of bounded the network usage.

J Sunnyside Labs:the block, drop it limit, and other than that there were minor findings in the networking resource usage.

J Sunnyside Labs:We've also done Genesis sync test which we

J Sunnyside Labs:were able to confirm that all the Cls and Els passed except for Gath. But

J Sunnyside Labs:the fix for death is up in the review, so. I guess, like we are at

J Sunnyside Labs:pretty good stage at the moment, and, as Parish said, hardening the cls and Els for Fussaka will be quite important next steps

J Sunnyside Labs: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

Raúl Kripalani: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

Raúl Kripalani: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

Raúl Kripalani:creating pathologically large blocks to disseminate

Raúl Kripalani: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.

Raúl Kripalani: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.

Raúl Kripalani: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?

Parithosh Jayanthi: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.

Parithosh Jayanthi:Okay, have a nice day.

Anders Kristiansen:So.

Toni Wahrstaetter:Thank you. Bye-bye.

jochem-brouwer:Thank you.

Antoine James:Thank you. Bye-bye.

Justin Traglia:Bye, thanks, everyone.

Chat Logs

Barnabas:https://dora.fusaka-devnet-2.ethpandaops.io/clients/consensus

Justin Traglia:There was a small nimbus issue that was fixed this week. Some new consensus spec tests found it. The result of verifyCellKzgProofBatch wasn’t checked properly.

Barnabas:this page has eth-das-guardian enabled already

Parithosh Jayanthi:https://github.com/ethereum/consensus-specs/pull/4439

Barnabas:Teku and nimbus are having issues with eth-das-guardian still .

Parithosh Jayanthi:https://github.com/ethpandaops/kurtosis-sync-test/actions

Barnabas:sounds like something we can yolo roll on devnet 2 tho

Barnabas:could we add new metrics to http://github.com/ethereum/execution-metrics ?

James He:We are working on release soon

Phil Ngo:Should be out tomorrow without issues for Lodestar

saulius:Grandine should have release this/next week.

Parithosh Jayanthi:https://github.com/ethereum/EIPs/pull/9981

Francesco:Seems good as is

Raúl Kripalani:I can take a look

Raúl Kripalani:Replying to "I can take a look" Approved

FLCL:Replying to "I can take a look" Thanks!

Barnabas:Could you not just charge for worst case scenario, and give a refund later?

Ansgar Dietrichs:Replying to "Could you not just c..." the worry there is that it would break existing contracts that hard code gas only for a 24kb access

Ansgar Dietrichs:Replying to "Could you not just c..." otherwise yes, that would be the cleanest way. doesn’t even have to be a refund, just throw if they could not pay for the largest code possible. then you can still only charge the actual amount

Charles:there is quite a large overhead to call another contract. so it is a tradeoff, but it's left to the developer to optimize it

Charles:"easy" splitting also assumes there is no shared code between the code paths that are split. if transfer() and transferFrom() both use the same internal function, that shared code must be duplicated across the two physical contracts

Barnabas:Replying to "Could you not just c..." can’t we just have static cost? 2100 for 24kb 4200 for anything 24kb+ ?

Ansgar Dietrichs:Replying to "Could you not just c..." yes but again, you only know afterwards

Ansgar Dietrichs:Replying to "Could you not just c..." so what do you do if someone asks to access code, but they only have 2100 gas left?

Ansgar Dietrichs:Replying to "Could you not just c..." you either throw (just in case that target is too large), but that might break existing contracts or you allow it, but then if that triggered full code load and it was 48kb, now you got that for cheap

Charles:like for certain kinds of contracts it is not even possible to split them up

FLCL:Btw cold code is not unique code to be loaded first time, but potentially the same code for different accounts loaded twice (second time is easier)

Raúl Kripalani:Replying to "I can take a look" Merged

Ansgar Dietrichs:it’s fine to make the codeSize data structure an implementation detail, but we do have to make sure every client has some version of it by Fusaka

Parithosh Jayanthi:Replying to "it’s fine to make th..." Which clients need to have it done? And what timeline would they have?

Parithosh Jayanthi:Replying to "it’s fine to make th..." Ie what does this add to our fusaka timeline

draganrakita:Replying to "it’s fine to make th..." I think all clients will have it in Fusaka,

Francesco:Replying to "it’s fine to make th..." What does “by Fusaka” mean?

Francesco:Replying to "it’s fine to make th..." Does this not need to exist in devnets?

Parithosh Jayanthi:Replying to "it’s fine to make th..." Lets say this needs to be at fusaka-devnet-3

Marius van der Wijden:My take is that 7907 and its consequences still feels underexplored/underspecified and I don't think we should ship a half baked solution before that

Ansgar Dietrichs:I still think 7907 was the wrong way to go for Fusaka. It’s clearly designed to be forward compatible with later larger limit raises, otherwise it’s unnecessarily complex. But it is highly questionable whether we will want to use this logic to ever go beyond 48kb. we could have gotten a one-time bump just via Giulio’s EIP (keep cost as-is, bump limit to 32KB), then figured out the proper way for Glamsterdam

Francesco:Replying to "it’s fine to make th..." Can we explicitly (on the call) decide if that’s the case? (what exactly is the requirement here and what that means for this EIP)

iPhone:If this is dependent on zkEVMs, then I think we should benchmark it to see what the difference will be

Ansgar Dietrichs:do we have proper benchmarks on pre and post 7907 code load performance at 100M yet?

Ansgar Dietrichs:Replying to "do we have proper be..." it feels like we should make that a hard requirement for shipping 7907 in Fusaka

Ben Adams:None of the Shanghai DoS contracts were above 24kB?

Marius van der Wijden:Not quite true with snap sync @Ansgar Dietrichs

Ansgar Dietrichs:Marius is concerned and a client dev

Ansgar Dietrichs:Replying to "Not quite true with ..." say more?

jochem-brouwer:Yes

jochem-brouwer:100%

Ansgar Dietrichs:there is the precautionary principle though: if we already think at 24k this could potentially be a bottleneck at 100M, we should not make it even worse by 2x

jochem-brouwer:Before EIP-170 the block gas limit was too low to deploy 24 KiB+ contracts

Charles:Replying to "there is the preca..." the cost is marginal though

Ansgar Dietrichs:Replying to "there is the precaut..." fwiw I actually think it is *ptobably* fine, but that’s why we should go and get good benchmarks

Marius van der Wijden:Replying to "Not quite true with ..." If you snap sync, you don't know if there are contracts that go beyond 24k after snap syncing

Charles:Replying to "there is the preca..." like the figure that matters for marius's concern is gas per word, not contract size limit

Ansgar Dietrichs:in the attack we discussed (load code without enough gas to pay for 48kb), the contract would remain cold. But is there also a different edge case, where keeping a lot of warm code in memory would be an issue? say at 100M max code loads, would be big issue if that would force the oldest code to be discarded from memory again, while still warm. then you can load it again super cheaply, but it would trigger another disk lookup

Charles:Replying to "in the attack we d..." that is more related to tx gas limit than block gas limit

Ben Adams:16M is in devnet3

Charles:Replying to "in the attack we d..." but yea

Guillaume:@Ansgar Dietrichs you misunderstood what I said: you described building the index, I said that's what every client will have to do if they don't want to have to go over their code. An alternative would be to only have an extra field for contracts > 24kb, but that won't work to place it with the bytecode, as it's not possible to tell the difference between an index and bytecode. In the account, it's possible to have an extra rlp field, but you need to make sure it's not hashed - not very practical

Ansgar Dietrichs:Replying to "in the attack we dis..." ah, good point. also this might not get worse with 7907 at least, given that you would charge proportionally to actually make the code warm

Ansgar Dietrichs:Replying to "@Ansgar Dietrichs yo..." right, so some implementation variants would require you to update all existing contracts

Ansgar Dietrichs:but then can’t we just solve all of this by trying to get reliable benchmarks asap? ideally we see that there is no issue here at all

jochem-brouwer:Antwoord verzenden naar "but then can’t we..." Can we assign someone to this and also what benchmarks need to be done specifically?

Barnabas:whats the max contract size you can deploy with 16M gas?

Parithosh Jayanthi:Replying to "but then can’t we ju..." @jochem-brouwer would you have some time to get these benchmarks?

jochem-brouwer:Antwoord verzenden naar "but then can’t we..." Yes :)

Parithosh Jayanthi:Replying to "but then can’t we ju..." Thank you!

jochem-brouwer:Antwoord verzenden naar "whats the max cont..." limit / 200 theoretical hard cap

Ansgar Dietrichs:I think the most critical one is the code reads with insufficient gas

Mario Vega:Regarding the concerns that Marius mentions which require benchmarking, I think this file already contains the tests required to benchmark this: https://github.com/ethereum/execution-spec-tests/blob/main/tests/benchmark/test_worst_bytecode.py @jochem-brouwer

Ansgar Dietrichs:Replying to "I think the most cri..." because none of the others are worse under 7907 than today, right?

jochem-brouwer:100M / 2600 theoretical max accounts

jochem-brouwer:30M / 2600 per tx

Ansgar Dietrichs:but jumpdest analysis only runs if the load was successful, right? so at that point you were already charged double for a large contract, so then it’s fine to take twice as long for jumpdest, no?

Barnabas:Replying to "30M / 2600 per tx" why 30M?

Barnabas:Replying to "30M / 2600 per tx" the new proposed tx max was 16,777,216

jochem-brouwer:Antwoord verzenden naar "30M / 2600 per tx" Yes sorry in that case the 16m :)

Marius van der Wijden:Also reverting in the call

Gabriel Trintinalia | Besu:Besu on track, pending 7907

Ben Adams:When devnet3?

Marius van der Wijden:Oh and jumpdest analysis on initcode that reverts

Barnabas:https://github.com/ethereum/execution-apis/pull/674

Barnabas:can we discuss this?

Barnabas:Anyone opposed this change ?

Barnabas:also builder spec stil open: https://github.com/ethereum/builder-specs/pull/123

J Sunnyside Labs:https://testinprod.notion.site/Sunnyside-Devnet-Updates-07-14-2308fc57f5468054b18fcbff31cc032c?source=copy_link

Roman:one caveat re reth, the tag that was used was just before the peering fix

Charles C:Hopping off, thanks everyone

Marius van der Wijden:Csaba also had some scenarios that he would like to have tested

Francesco:If we constrain the mesh parameter, that will skew the bandwidth findings though, right?

nixo:hiccup