All Core Devs - Execution #212

Transcript

Tim Beiko: Okay, Josh, do you wanna move us over.

Josh Davis: Your life.

Tim Beiko: Okay, welcome everyone to acde number 212 bunch of different things on the agenda today. But 1st thing will be to finalize the list of Fusaka vips for def net one we'll also get some updates on implementation from teams. Then Alan had written a good post about how we should approach test deployments after we had these issues with Petra. So we should discuss this a bit. then, after that I want to discuss with how we should approach Glamsterdam scoping under this new process. We've been discussing these past couple of weeks. Couple of other things related to that around just how we should approach reviewing breakouts. Input collection. And then, if we have time, there's a couple of different proposals. I wanted a quick review. But otherwise we can move that Async

before we jump into the Fussaka planning discussion. Perry, do you want to give us an update on the current state of implementations.

Barnabas Busa: Yes, I can. I'm not sorry, but close enough. So we have a few dozen currently running. We do not have too much fuzzing going on here. We just basically do a stable spamming of blobs and different clients are testing whether they are able to sync up and whether they can do backfill. I think, as of right now, most of the clients are unable to backfill anything, and we're going to be probably request our clients to have backfill working by like Devnet one or Devnet 2. You also do not yet have valid custody implemented by many clients, so we don't really does that because that would just cause unnecessary chaos when we we know that it's not supposed to work just yet. But other than that we have on boarded almost all the different clients

we recently as well, and they were also able to sync up to head. And I made some deposits, and they have some index returning, and we have 100% participation. So that is, regarding Devnet 7. And on Monday we plan to launch physical devnet 0. And I am actively testing now the different client combos we have grandin prism load start deku working on the cl side and get on the yeah. 3, rd as of now. we're still waiting for nimbus and lighthouse to have the branches published for this year, and pretty much all the other ears to. Oh, publish working branches.

Parithosh Jayanthi: Yeah.

Tim Beiko: Too.

Parithosh Jayanthi: Follow up. We have the East tests that were released yesterday, I think, and now there's a hive instance for it already. We have only one result so far from Geth, so if other emails give us an image, we're happy to start running them against East tests. And for us testing the security team has a tool that allows us to create network partitions. And I've been playing around a little bit with it. There's a lot more features coming in over the next days, but it seems like the partition test is already failing, and might have caught something. So I'll try to dig in a bit more and figure out what's going on there.

Tim Beiko: Thank you. Yeah. Question by various in the chat that we tried it. That's without super nodes. Is that something we should test.

Barnabas Busa: Eventually, yes.

Tim Beiko: So we we have not yet, but we we will.

Barnabas Busa: We? We haven't yet. We have a critic test for basically creating a perfect pure desk network where we have 16 16 nodes. And each node is basically just taking 8 columns for themselves. So no super notes. And we will have 100% coverage of all, 1, 28 columns that way.

Tim Beiko: Got it.

Barnabas Busa: So in technically, we could, we could test this perfect good desk. And see if it's working fine that way.

Tim Beiko: Okay, anything else on the peer dos devnets or devnet 0 0 that we're about to launch. Oh, new consensus specs releases nice.

Barnabas Busa: So we have reached out to every single client, and everyone got back to us. Everyone is still working on implementation. Hopefully. By Monday we can have a pretty stable, and then we're gonna be shutting off.

Tim Beiko: Sounds good. Does any team think they will not be able to make it on Monday?

Andrew Ashikhmin: Well, we might not be able to make it on Monday, because we we've implemented like the, but we haven't implemented the Ps. once, like the engine Api changes and the Tx pools, the expos changes. So maybe like, I think so, someone's working on it. So maybe some. You can comment on the status.

Somnath Banerjee: Sorry. Yeah. So well, I think we might be able to publish. A branch may not be merged into main yet, but oh, we can do that.

Tim Beiko: Okay. okay, anything else on this academics? If not, then. Yeah. So last week we we discussed finalizing the scope for devnet one on this call and potentially trying to get the full set of vips for Fusaka sorted. I think there's value in in kind of breaking down which Ips we want, in which Devnet, so that we don't have a like set of 6 new vips coming in, and all the clients working on different ones and and making it harder to kind of move, move forward as a group. So I asked if people could share their preferences for Devnet, one devnet 2, and then potentially making devnet to the last devnet, where we accept new vips for Fussaka. So this gives us kind of 2 more rounds, and then.

I guess, related to that is, whether we should remove some things from the Cfi list. Because, you know, at this point we we don't think we're gonna make them So 3 teams, I think. Never mind Aragon, and basically shared their views before this call. The the one thing that seemed like all of them are sorry. The the there were 2 eips that seem like both of them agreed should go into the next devnet devnet. One was eip, 7, 8, 2, 5 transaction gas limit cap, and then eip 7, 9, 3, 4, the Rlp block size limit, and both of these seem like this 3 teams, one of them in Devnet one. I'm yeah. I'm curious. Guess, Russ, how do you feel about those.

Lightclient (Matt Garnett): I'm honestly still trying to understand what the transaction gas cap is trying to target. Because I think most of the motivation doesn't really make sense in the eap.

Roman: We are. We're for that in the transaction desktop, just to try to transfer that's point like it. It really helps with prevailization and not not having to care about this worst case. One transaction that you cannot like, execute in preval or pre-worm. or do anything with it, is it how to do it sequentially.

Lightclient (Matt Garnett): Yeah. But I think that this is kind of missing the point of where we're going, which is large transactions that are batching many user operations together. you know, with 7,702, we're almost certainly going to see an increase in the average transaction size over the next 12 months. and it's going to have big implications on things like this.

Tim Beiko: I'm yeah. No, Andrew, did you want to answer that.

Andrew Ashikhmin: So, yeah, we we are working on parallel execution. And we'd like to avoid massive transactions. So yeah, this this cap will help with the with the throughput.

Tim Beiko: Thanks. Roman, yeah.

Roman: Yeah. Well, one more follow up. Comment is, I don't think it is fair to the protocol. If the the user or like the badger combines all the operations into a single transaction, and bypasses paying the base transaction cost.

Lightclient (Matt Garnett): Why is it not fair to the protocol? The protocol's resource pricing is transparent and fair and equal.

Tim Beiko: So I guess what's the argument for having a no cap like if we if we have a cap now, that's effectively close to the block size limit. Couldn't we raise it in the future? Is it just that? Then it becomes bottlenecked on all core devs? And if we have a hundred 1 million gas, and we don't want to raise the cap to 100 million gas. Then people have to pay for 3 transactions instead of one.

Ben Adams: You can, you can only run a transaction that's the size of a block. So as if it's if you've got 4 transactions that are quarter of the block, you can run them all at once.

Tim Beiko: I'm yeah, junior.

Giulio Rebuffo: Yeah, I just wanted to say that the limit is is kind of a 30 million. And it's basically an entire block. The main reason just to the main rational action is that if we increase the gas limit we don't want to have to think about with the worst case transaction cases so limiting, it makes sense for the future. That's the main rational just to clarify that. But even in the context of a of a big of one block transactions. Even if you have the overhead of sending 2 transactions per block instead of one. It's it's just 21,000 gas. It's not that much? Really? Yeah.

Tim Beiko: Yeah, dunkrat.

Dankrad Feist: Yeah, I was wondering like it with the bundles. Do we actually have to apply the limit to the bundle, or can't we just apply the limit to the individual transactions in the bundle.

Lightclient (Matt Garnett): Well to do that, we would have to have the individual operations in the bundle exposed. What their limits are, and that's kind of native account obstruction which.

Dankrad Feist: Don't have yet right. Oh, so we cannot know what the gas limit for the transactions in the bundle.

Lightclient (Matt Garnett): Correct.

Dankrad Feist: Right? Right? Right? Okay.

Lightclient (Matt Garnett): Yeah, I mean, I don't think.

Dankrad Feist: Otherwise, like the main reason for the whole thing is like a transaction is kind of a nice object, with very clear in and outputs right? But splitting up one. Transactions can have like very complex state and a big memory and stuff like that. So it feels like for the bundles. That's not actually true, like, you don't actually transfer a complex state between the transactions in the bundle. So it feels like you could do something more there if you wanted to.

Tim Beiko: Yeah, I'm Anzgar.

Ansgar Dietrichs: Yeah, I just wanted to say, I think, whether to ship this now in Fusaka or not is not so so important, maybe necessarily yet, but I think medium term we will need this anyway. Or there's several reasons, I think. Also, for example, I mean zk evm proving but then there's also, for example, something that we recently came across, which is that for capping individual types of consumption. So, for example, if you want to like, have a maximum amount of S stores that you have in a block or something that in principle is something very desirable. So we can basically like handle worst cases more easily without making the entire operation more expensive. And the problem is that that opens you up to this like really bad dos issues where basically, you just don't see in advance how many stores a transaction will want to consume. So if you basically just have an upper gas limit

per transaction. That means, for example, if you have a 10 million gas limit per transaction and you have a hundred 1 million block gas limit, then you just know that you can always set that cap at 10% of what the worst case could be for block. And you never run into these dos issues. So basically meaning, I think, at the latest in Amsterdam. We want this, anyway, and I think, introducing it in Fuzaka already with a not so punishing limit like maybe more. 30 million like it's proposed, I think, would be just a very elegant way of of doing it now, while we have the resources. So I'd be in favor of doing it.

Tim Beiko: Thanks. Lukash.

Łukasz Rozmej: Yeah. So one of the proposed changes for the future are block access lists. and one of the flavor of block classes list allows for perfect parallelization, so parallelizing even the transactions that are dependent on each other on the State because of block abscess list, intermediate data, let's say so here, having a cap on the transaction. So basically guaranteeing that there are at least as many transactions in the block is would be directly connected to throughput and in terms of when to introduce this kind of cap, the sooner the better, because this is hard to retroactively change. I think 30 million is, you know the minimum, the like minimum maximum. We should aim for. Even the Ben kind of convinced me, with his latest stats that we should. We could aim for something lower like 15.

Lightclient (Matt Garnett): But the latest stats are not useful, because with eap 7,702, it totally changes the structure of how people are submitting transactions onto Mainnet. So looking at Pre, 7,702 doesn't give you good data on what could be post.

Łukasz Rozmej: Yeah, that's a point. So I'm happy to also go with like 30, or if you want 36 million. But whatever I would like to have something. Then, if we go to, for example, in a year of to I don't know 100 200 300 million gas that we will guarantee that there are multiple transactions there.

Ben Adams: I mean, okay, even even for Aa. If the A. Bundler sent 2 transactions, they could be run with block access list that could be run in parallel and complete in half the time, whereas if they sent one transaction that consumed the block it would. they would have to run serially. and it would take double the time. So I mean, it's even better that way.

Lightclient (Matt Garnett): We don't have block access lists. So.

Ben Adams: Yeah, but it's proposed for lunch today.

Barnabas Busa: Isn't this like a security vip? Basically because we don't necessarily know what such big transactions would do to the network. So like, I think it's better to go the same way rather than just kind of, and let whatever size transactions through.

Ben Adams: So at at the moment. The transaction pool, I think in most clients limits you to 128 kB.

Dankrad Feist: Okay.

Ben Adams: Op stack can upgrade an entire L two's contracts in under 9 million gas and of the last. Was it last 30 days. The only transaction above 5 million guests were scam, scam, token sense, and Zen contract mining. which can easily be batched in smaller amounts. They're they're just massive batch transactions. and they could be bachelors. A smaller level.

Tim Beiko: Right? So the only argument I guess I guess this limit is that if we move to a future where there's huge a batches, and they're somehow cost prohibitive because they're not amortized. They're amortized across 2 or 3 transactions versus one. So it seems like given that the potential risks. Yeah, of of not having this and raising the gas limit, we should probably move forward with it. Yeah, any other objections. And yeah, in Amsterdam. We can always revisit if if we want to. Okay. So let's move eip 7, 8, 2, 5 to Sfi. Add it to the devnet, one spec. the other eip that people that based in the mind Aragon, all felt was should be included in indefinite one is 7, 9, 3, 4. Which is this? Rlp execution block size limit?

so yeah, the idea there is to add a cap to the Rlp payload to match the Cl. Gossip, cap. I don't know if Guest breast 2 of you had opinions on this.

Roman: For him.

Marius van der Wijden: I like the idea of capping the the size of the block. I've not really looked into into the eap, so I cannot say if I if I really like the idea of capping the size of the Rlp encoded block. Because European coding can be quite weird. But yeah, I think in general, this this idea of of limiting the the worst size of block that we accept seems good to me.

Łukasz Rozmej: So if I can add something, I would say the cap is already there. It's just not explicit, and this just makes the cap explicit.

Tim Beiko: Okay? So yeah, and I assume it seems pretty small in terms of change, just like the transaction cap. So any objection to including that one too.

Ben Adams: Again. There's a question. Do we want to cap it lower, like 7.5 MB rather than just the network one, because it's there. It's a direct impact on our recommended bandwidth cause. It's it's quite large.

Tim Beiko: And Howell, do you have thoughts on this.

Paweł Bylica: No. I just wanted to ask is this like cl change or El change? I mean, who? Yeah, I'll change.

Tim Beiko: This is the point 7 9 3 4 is adding it on, adding a cap on the El block size.

Paweł Bylica: Yeah, yeah, that's true. But Cl delivers this block to the yeah. Right? So it knows already that it's too big. So I mean, who will actually implement this check.

Kamil Chodoła: It's the check on block building.

Ben Adams: The the Al would have to check perfect. not build blocks too large, and also prevent it. The Cl. Could also do it if they wanted to.

Paweł Bylica: But most of the blocks are coming from the network, right? So you need to check there as well.

Łukasz Rozmej: So El will check it on peer to peer goes like thinking, maybe era files importing. For example, if VR files are not weird in that way. It could also check the blocks that it is building, that they are beneath this value, because if it El doesn't know about this value and builds a too big block, and then the slot will be missed right? So there are this kind of situations.

Lightclient (Matt Garnett): Has anyone implemented this check in building and determine, like what the impact on building will be, because if you need to Rlp encode the block after every transaction. Then that's going to add a lot of extra compute to build in.

Ben Adams: I mean, it's fairly minimal, because you have all the Rlp. For the every transaction or anything.

Paweł Bylica: But they don't necessarily add up to the to the like, the the results until you actually encode it right online, we need to predict what the encoding will be on the fly.

Ahmad Bitar: Receipts, though. No, only the receipts like. If that transaction is Rlp. Encoded already. you can just add that number and then see if there is any receipts also, and.

Lightclient (Matt Garnett): They already? Why are the transactions already? Rlp encoded? If you're building a block like the transactions are represented in just your native runtime.

Ben Adams: That's how you get them off the network.

Lightclient (Matt Garnett): And if they don't come from the network. if they come from Json, Rpc.

Ahmad Bitar: Most likely you use central transaction.

Łukasz Rozmej: You probably sent the transaction to the network, so you already encoded it so we can know the length.

Lightclient (Matt Garnett): I just think that we're saying that we can add this check during building no problem, but no one's implemented it in building. And it seems like it would be useful to actually see what the impact is on.

Łukasz Rozmej: So.

Lightclient (Matt Garnett): People who are building Mev blocks.

Ben Adams: Either either that or the blocks fail.

Lightclient (Matt Garnett): I mean, sure. But if you make it really expensive for them, if you make it expensive for Mev builders to build blocks like, sure, you know, we can impose these protocol constraints, but it's kind of pointless to impose a bunch of compute for them that is not really useful in any way.

Ben Adams: Okay. But then.

Giulio Rebuffo: No.

Ben Adams: That's that cannot be gossiped. So it's essentially an invalid block, so either they check it or they don't. But the blocks can be invalid regardless.

Tim Beiko: I guess. How hard is it to get the numbers around the like relative time to encode the block and Rlp.

Giulio Rebuffo: But like, you guys need to encode it like, I think it's kind of easy to predict what it is like based summing just the transactionalp which we already have, anyway from the Cl. and, like the other, is always also fixed size. You know the size of the other 2. You don't have receipts. So actually, it's just kind of a bunch of additions which or it's not computationally expensive. You don't need to to re-encode it all the time while being the block, either, if you do it in a smart way. right like.

Ben Adams: Yeah, it's just it's just the calendar.

Giulio Rebuffo: Canceled additions.

Ben Adams: It's just the bytes at the front of the block with of the count of transaction.

Giulio Rebuffo: I mean you don't. You don't need to even encode the block. The the thing is that you don't even need to encode. You just need to sum a bunch of numbers.

Ben Adams: We. We have already implemented this another mountain. It's not very hard. So we re when we're picking transactions, we reject transactions. If it if it will cause the block to become too big. which we had to do for perfnet. And it's 5 gig of gas limit. because we were building blocks that were too big.

Tim Beiko: Okay. How old is that? What you want?

Paweł Bylica: Yeah, I wanted. I wanted to ask if we can see a prototype implementation, but Ben, already mentioned, there is one. but maybe it's time to present it. So because we're kind of discussing, this is easy or not easy. But if if you can present a prototype implementation, that is simple, I think that's fine. I'm I'm slightly concerned about how we're actually going to test this, because I'm sure I want to see like 10 plus a Mega Json files with the text. But okay, that's maybe the other concern.

Mario Vega: The the tests are compressed. So if we fill the the test with zeros, it's not gonna be a big burden. I think.

Giulio Rebuffo: The check on the Cl is on the uncompressed size, though. So you're actually gonna see the burden, even even if it's zeros.

Mario Vega: I just meant for the Json files in the tests.

Giulio Rebuffo: Okay.

Mario Vega: Yep.

Tim Beiko: Okay. So if we have an implementation, the testing to work, and it seems relatively easy to calculate this as you're rebuilding the block. Does it make sense to move forward with it? And that's on the test net. Yeah. And Marius has a question about where we actually enforce this in the engine. Api

Ben Adams: It's part of part of it.

Tim Beiko: I guess.

Ben Adams: Tracks on the block. So before you do anything, just check the the size of the the message.

Marius van der Wijden: But the size of the mess, like the messages Jason encoder right.

Ben Adams: Yeah, you you you decode the Json to get the Rlp. Which then you decode to get the block.

Tim Beiko: Under the question around, can we do a cap on the total size of the transactions instead.

Roman: Yeah, I think Paris is right, like you would have to encode your Json block to only European code just to check. And then you can proceed. I think this is not ideal.

Tim Beiko: Julia.

Marius van der Wijden: That's kind of what I'm.

Giulio Rebuffo: Sorry. Yeah, it's kind of.

Marius van der Wijden: Sorry you kind of what I'm saying with the the I I do like this eip. I just don't know if doing this check on the total, like on the Rp. Encoder block is the right way to go, or whether we should do something like Roman, said.

Ben Adams: Well, I mean, either either you can do the check on the message you've got from the Cl. Or you have to decode it. Decode everything. Then get the transactions out, and then you can measure it. So it's whether you want to measure it. Immediately the Cl. Sent you a block, or you got it from the network. you can just check its size before trying to decode it. or if you want to do it on transactions, then you have to start decoding the block in order to get to the transactions.

Tim Beiko: So I guess yeah, for this vip does feel like we maybe don't have a great understanding if the designs space. So should we just yeah, should we just take the next 2 weeks to figure this out and try to make a final call about it on the next Acd. okay. Yeah. Judo.

Giulio Rebuffo: Yeah, I just wanted to say that regarding the alternative design, I kind of already thought about it. But the thing is that it kind of makes no sense to just use, like the some of the transactionalp, and not the rest of the block, because you are actually forwarding the adder. Oh, and like also the adder with the block in the Cl. It so it doesn't make any sense not to include it. And also it's not, you know. So it's really not significant difficulty, because the other size is capped like you know it ahead of time. It's not like the only thing you don't know state time is the state truth, but you know that the state root is 32 Byte.

so you know the size of the other. So you there is no need to keep it out just to have a slightly simpler way like it's equally simple. essentially. So. That's why I didn't really like the design. When I 1st it was 1st proposed.

Tim Beiko: Got it? yeah, I do think, like, yeah, we're 3rd into the call yet. Then there's this other things to discuss. So I would hold this one for the next 2 weeks. Try to align on a design. And then, yeah, make a call about it for yeah, on the next operatives. I'm and then, okay, so of the other eips the sorry. Let me just look at the list real quick. the other vips that people wanted to signal for either devnet, one or devnet 2 were 7, 9 0, 7, increasing the code size. The code size limit basically wanted in Devnet 2, I think. Never mind, was against it. And Aragon also wanted it in Devnet 2,

then eap 7, 9, 1 8, the Blob base fee being bounded by the execution cost. It seemed like, basically, Never mind. Argon wanted this, and Devnet 2 7, 2, 1, 2, the r 1 curve pre compile. There was a mix between Devnet one and Devnet 2, and it seemed like people generally wanted this and then payop code was maybe the most contentious where Argon just wanted it removed, and then, basically wanted it in the next devnet. And never mind Devnet 2. These are kind of the other all the other vips that are that are being that we're already cfi'd in without them. We still. I haven't heard from. I guess Reth and geth on those already. So I don't know if yeah breath or Geth, you have some thoughts on on this list. So 7, 9, 0, 7, 7, 9, 1, 8, 7, 2, 1, 2 and 5, 9, 20 contract code size the blob, basically change our one precompile and the pay. OP. Code.

Okay, so live client, saying he thinks we should have 7, 2, 1, 2, and 7, 9 0, 7. So sorry, Roman, you were just coming off mute.

Roman: Yeah. I believe we posted this in in the original Cfi prioritization list. But basically no strong opinions on 5, 9, 20 and 7, 9, 18 and then supportive of 7, 9, 0, 7, did I miss something.

Tim Beiko: The the r. 1 precompile, I think, for us.

Roman: Oh, yeah, it's yes, this is supportive of it as well. 7, 2, 1, 2.

Tim Beiko: Okay. And so so for 7, 9, 0 7, it seems like everyone supports it except for another mind. So I don't know. Nethermind, you wanna maybe share your rationale here.

Ben Adams: Sorry which one's this one.

Tim Beiko: It's the contract code size.

Ben Adams: Yeah. So there's not been a huge in depth analysis done on it. And if we're increasing the if, our if our goal for free soccer, I believe, is performance. And we're increasing the gas limit. And we're potentially increasing the slot times. next to it, there's a there's a lot of moving pieces. If we then increase the contracts to 256 Kilobytes and the init code to half a Meg. So it feels like there's too many unknowns with it.

Lightclient (Matt Garnett): I mean, that's why we meter it, though, so you can appropriately charge for loading the code.

Ben Adams: Yeah. But as a I don't feel the analysis on the the metering doesn't feel properly looked into at the moment. I agree that it is me, too. Yeah, but I'd like some more research around it.

Lightclient (Matt Garnett): Like, what kind of research like? What things would you want to see? To be confident that we should do this.

Ben Adams: So I mean not not. There's not. We've done a lot of study on the state database. But the code database. I don't think we know much performance characteristics of it across plants. I mean, for example, the amount of work that's being put into. you know, can we increase the gas limit to 60 million is is quite extreme, whereas the amount of analysis that's done, you know. Let's try it on the test map. That's you know. Let's see what the impact of if we did increase this limit. And then we started stuffing loads of contracts with this, what would the performance be? What would the State like be that kind of thing?

Lightclient (Matt Garnett): Why would state bloat have anything to do with this.

Ben Adams: Okay? Code, code blue. Because why does code.

Lightclient (Matt Garnett): Upload, have anything to do with this, like? The only thing that should matter really is like, how long does it take to load the code from the database. And because we can meter based on how long it takes. it's really just a matter of figuring out what the correct cost for that load is.

Ben Adams: Yeah, but your your code, code, like state, is a permanent thing, and you're now saying you can. You can add in a single transaction. Quarter of a megabyte of permanent storage.

Lightclient (Matt Garnett): I mean, you can already do that today. You just have to split it across multiple contracts. I think this is one of the most important things that the community has been asking for. And if we're trying to signal that we're listening to them and improving them, improving the things about the Evm. Then this is one of the best things we can do in Fusaka. I agree, like the exact metering calculations are probably not near as robust as the work that's gone into the gas limit increase. But at some point like to get the robust numbers we have to kind of like commit that we want to do this thing. It's hard to get a lot of those numbers when we're doing a lot of other stuff, and we haven't really committed to doing the code size increase.

And it feels to me that there's only like this one moving variable about exactly how much we need to charge for loading the additional code, and that seems like very reasonable part of the implementation process of the IP.

Tim Beiko: I guess. Yeah. So to Ongar's comment, like, is there actually anything we can figure out in the next 2 weeks? Or should we just implement it. To what we learn most by actually implementing it in that net. Yeah, Powell.

Paweł Bylica: The one off of the cost factors is jump this analysis to my understanding of the IP. And I think to my understanding of Vm as well. For that I I plan to do benchmarking, anyway, in some other context, but I think I can commit to prepare some report about this this kind of performance. and for for the next call in terms of floating from database, I'm probably not the best person to to do so.

Tim Beiko: And so the thing we're concerned about this like, if jump desk analysis is super linear in coat size.

Paweł Bylica: Yeah, I mean, I'm not really concerned. But we definitely need to track it. So I will do some. Yeah, we'll propose some benchmarks that let's say we'll do the same scenario, but with different code size limits, and we can check the current performance with the current limit. The performance of the proposed limit. And this one more limits that comes from the other IP, which is around 2 MB of code. It's the one from that cups. The wow. Okay, I'm kind of mixing 2 2 dimensions here. But yeah, I can. I can. If you want. I can describe like benchmarking scenarios in the next day, and if that's accepted, I can then work on this to get the number so, or we can prepare the

the benchmark in some format that anyone can try later.

Tim Beiko: Okay? And I guess so for the cip, all of the teams that have voiced their opinions before kind of supported it for the basement Aragon basically supported for Devnet 2. I think, given that, there's other stuff for Devnet one, and we might kind of know more in the next couple of weeks I would maybe make this call 2 weeks from now, so leave it as Cf. 5, and then 2 weeks from now get the final set of vips that go into definit 2, and yeah, try to at least get definite one done today. Because, yeah, there's other Vip that big people we're we're considering for that. So I guess, just like 7, 9, 3, 4, and let's aim to make a final call on this one in the next 2 weeks.

And then okay. So the other. The other one on the list that I think was was mentioned by basically, never mind, Aragon, and then, I think both guest and and Reth was 7, 2, 1, 2. There's a bunch of comments in the chat about that eip having some potential issues and maybe needing a bigger rewrite. I know that when the testing team looked into it they also said that it had some some work. And it was kind of the the biggest. Yeah, if you could test. So yeah, I don't. Nico, do you want to maybe give some background on 7, 2, 1, 2.

Nicolas Consigny: Yeah. So unlucky us there is like a slight issue with the existing rip. It's not a big big issue, but with crypto precompied. You can't really allow any type of uncertainty. so we should just either rewrite the vip with a small fix and discuss with the roll-ups that have already implemented it so they can maybe fork out and go to the new version. should be doable doesn't seem like a huge work to be honest. Then the question is just always the same like about like putting the precompiler in the in the clients. And for this I don't really have the the answer, but it seems like client teams are okay with it. So just rewriting the Vip should be, or I mean writing a new IP, I think should be the best.

Pass forward. And yeah, and working out of the air. IP. 7 to 12 for existing for existing roll-ups. I will contact the others to see if they want to champion this or I. We can probably to it ourselves. It could be.

Tim Beiko: Yeah, this is a pretty big vip. So I think, like, yeah, is there anyone.

Nicolas Consigny: And Antonio, I I guess. Yeah, I guess probably having Antonio from the cryptography team, and maybe Renault from the Kennox who wrote one verifier would be great I would, if if I could force them to do it, I would.

Tim Beiko: Is there anyone else on this call who can like? And the next 2 weeks looking into this because I agree, like, I think, a lot of people keep saying that this is really important. But if if we.

Nicolas Consigny: I? Yeah, I can take the burden, but not like to. I can champion this thing. But I on the mass side I would refer to defer to Antonio or cryptographers with a lot of experience. Yeah.

Andrew Ashikhmin: So I'd like to suggest, because we're going to make a change. And then this this IP is already deployed on polygon, so probably the safest route is to deploy it on ethereum in the standard precompile range of ethereum, and keep the original contract at the at the Rip address unchanged. and then say, smart contracts on polygon. If they want to use the newer version, they just use the ethereum address.

Nicolas Consigny: This is the difficult part. I'm not sure. You want to be in a situation where like one signature can produce 2 different outcomes

Tim Beiko: Right? So the yeah. Different code should be at different addresses.

Nicolas Consigny: Yeah.

Andrew Ashikhmin: Yeah, that's what I'm saying.

Tim Beiko: Yeah, yeah, that's that. Yeah, that feels like, a, yeah, yeah. like, yeah, that feels like a no brainer. Yeah. Adrian.

Hadrien Croubois: Yeah. I just wanted to say that I don't think it's just about Rip 7, 2, 12, Adrian, your mic is cutting. We don't not know where the precompile is, and have to guess like, if Openzeplin or Soladi, or any other library, wants to make something that is scp 256 r. 1 compliant. We don't want to have to check the chain id, and then go to which precompile it is that we want to use. and I don't think solidity wants that either, like nobody wants that.

Lightclient (Matt Garnett): I mean, solidity is going to have to do this, though, because we're not going to end up in a world where everything on mainnet is going to perfectly match the L. 2 s. Or vice versa. like we have to have compile targets.

Tim Beiko: And also, like there's an issue. It's like, if there's a bug with it. yeah, it's it seems impossible to to avoid.

Andrew Ashikhmin: Well, I think in this case it's not a big problem, because for polygon, it's deployed on a different address starting with like hex 100 or something so, for when if we if we deploy it for ethereum on the standard like range of addresses, then it can be ported to Aragon, and it will be like all the L. Twos can simply like enable ethereum's version at Ethereum's address, and it will be the same.

Hadrien Croubois: That would be great. Yes.

Tim Beiko: Yeah, they can obviously redeploy it. Yeah. okay. So it seems like, Nico and Stokes. I can look into this over the next 2 weeks, but that there's broad support. So should obviously leave it. Cfi, and then have it as a candidate for definite, too. Does it make sense to people.

Alex Stokes: Yeah, let's do it.

Tim Beiko: Yeah, and so to, I guess to recap. So right now we, we had the we already had the MoD xp eips that are going into devnet 0 along with obviously pure das and the Bpo forks. We said we wanted to include the transaction gaps limit cap in Devnet one as well. We're looking at metering the code size limit and increasing that for Devnet 2 potentially looking at 7, 2, 1, 2 for devnet 2 potentially so the other the other vip that oh, sorry. The other one. Sorry we're looking for them to. Is this Rlp increase. So we already kind of have 3 in flight that we need to figure out for that bit, too. The other vip that seemed to to have broad support is 7, 9, 1 8, which is the which is the blob based. View one.

And I think, let me check real quick. so basically, never mind. Aragon all wanted it in Devnet, too. I don't know, Geth and rest how you feel about it, but if we like it, I would maybe push to have it in definite one rather than definite. 2 given. It's simple, and we already have a bunch of stuff pending for definite 2.

Lightclient (Matt Garnett): Sorry, which one.

Tim Beiko: S. 7, 9, 1, 8. The blood base fee change.

Lightclient (Matt Garnett): Right? Yeah, I mean, I think it's simple to implement. But like strategically, it's very complicated. And I honestly don't know if we've really had the time to make sure that this is the type of thing that we want to do increase the cost of blobs to L. 2 s. That seems like a major decision. and it shouldn't just be sort of wrapped up into the Devnet.

Tim Beiko: Okay, on to go.

Ansgar Dietrichs: Yeah, just to briefly report from from that side. So, and us has been kind of continued to work on this quite a bit, I think Anders might also be on the call and could get there. But basically high level summaries, just that like, while looking at this. there were some people people noticed that even today, basically, blob transactions are to some extent underpriced because they have this compute overhead. Of of these, of the proof verification that's not accurately priced in the normal gas right now. And the leading proposal right now is to just basically use that as a baseline for the, for the basically for the minimum price for for blobs. But the nice thing is basically in terms of like definite. As long as we are certain that we want to ship this at all. We can just go ahead with implementing this because the only potential change like that that is contingency, or where we might still want to change our mind over the next few weeks would be the exact level of this minimum

price. And that's literally just a constant in that eap. So that is a that is a constant value that is just used once in an if clause. So basically like that, that's just at the very top of the Ap. And if in 2 weeks or so we say, Hey, actually, that's a bit too high for L. 2 s. And we don't like that. We reduce it by half or something. If that, if that's already implemented in the definite by then, that's 1 constant change. So I think it would be safe to go ahead with implementing this now already. But when we're on that, I think my understanding is that there would be one more update to the eap that I think Anders would have ready

like by whenever it has to be ready, like by Monday by default, but also like by the end of today or tomorrow, if if necessary. With some small spec clarification.

Anders Elowsson: Yeah, do you hear? Me? Yeah. yeah, yeah. So I can use. Yeah, yeah, I can just mention that. Yeah. So there was this recent analysis I posted in the chat, and if we we expand the rationale a bit by by accounting for you know the the compute cost that globes actually impose on our notes. And yeah, we can use this to consider different constants. And and anyway, I will just update the eip with these reflections during the weekend. So we could. We could then have have some exact specification on Monday for the testing call, for example. But it's essentially that we would go with the if clause that looks more like the one in the in the in that text that I

posted. But it's just a change of constant, actually. yeah. So the implementation is very simple, as Oscar says.

Tim Beiko: Okay, so and then there's some comments about maybe moving it to Glamsterdam. So I guess, yeah. does anyone feel strongly? We should include in Devnet one. Otherwise we can discuss this in the next 2 weeks and then see if we want to include it in Devnet, too. But I I will flag that we. We're starting to have a bunch of stuff that's like Tbd for Devnet 2. no. yeah. Okay. So no strong support for devnet one. Then. Okay. The last one we we haven't discussed yet. Well, I guess. Why not the net one? I don't. I don't think any team has signaled towards that, and then some of the teams think we should move it to another fork, so.

Ben Adams: Happy, happy for definite one. It's much simpler than they. Basically. we already have a Pr for it.

Tim Beiko: Okay. So never mind. I mean, okay. So under in the chat, saying, Why move it to different fork, like like Roman and like kind. We're both saying we could push it to a different fork. It's not a priority. So.

Ben Adams: I mean, what one of the issues is. We're massively altering the blob and then we're having Bpos. So we're we're messing in the Blob market massively in terms of supply. So it's better to have it in before that.

Tim Beiko: Yeah, there's a question on unders. Do you know. what? What do we expect the change on fees to be? And I know there's many different moving parts here. But yeah.

Anders Elowsson: Maybe I can. Yeah. So I mean, this is this is the conversation we can have when we tune that that constant, essentially depending on how we want to sort of balance between. On on one side, we we might want to to actually charge blobs for the compute that they impose on on notes, or or we would like to ensure that the fee market functions, and on the other side, we want to keep blobs very cheap. And we can. Just the point is that we can just set this constant, rather low, and by doing so we we ensure that we are not imposing, like a race to the fee that is substantial when we, when we compare it with the cost of the blob current transaction itself.

Alex Stokes: And maybe just to reiterate, how exactly, then, does it improve the functioning of the fee market like that sounds interesting to me. We have the cip, and there's a parameter we can tune so that the fees end up in like a nice place. But then it sounds like we also get this other benefit of better functioning fee market.

Anders Elowsson: Yeah, that's.

Alex Stokes: Such as.

Anders Elowsson: Well, so essentially blob consumers are affected by the the execution base fee because they have to pay for the for you know the block kind transaction, anyway. So if you want to set some low limit to the, to the, to the blue base fee, then, if we have that limit, reflect the execution base fee. Then we can. We can. We can sort of assign a limit that will adjust correctly, dynamically, with with how the demand for global consumers are shifts. sounds good.

Tim Beiko: In the chat. Terrence said that the L twos actually want this. So, Terrence, do you want to give some context on this.

Terence Tsao: Yeah, so I can speak on behalf of option labs. We've done like a bunch of research over blog feed market over the fast, over the past few years. Right? And one deficiency that we have seen before. It's just that when the block base fee is very, very low, essentially becomes a priority gas option. So people start bidding heavily on tip. And that's not very nice, because that's not something that's predictable. So we want something that's more predictable in a way that like. And then it also varies a lot because of like blob men, pools has have different set versus transaction. So basically, you know it's more strict. you know, way that you have one blob that has a higher tip. Then you kind of crowd out the like 6, like, for example, like a 6 blob. So there's no like a small and mix and match. It becomes like a PA. If you have some very hard problem to solve. And that's why builders started opening up their costume like basically their costume endpoint. And people start using that because this allows more flexibility.

And that's not very nice. And one way to solve this is just have a basically like, like a very predictable, like base fee in a way that like when it essentially rises up so much. It's like the basically the like. Basically, the curve is more smooth. So in a way, in a way, this actually helps a layer 2 like, basically because I, because of the base speed, wouldn't suddenly just spike.

Tim Beiko: Okay. Thanks. Undergar.

Ansgar Dietrichs: Yeah, I mean, I just wanted to say, because if we if there's still uncertainty whether we want to ship this in Fusaka at all. I think we just need to have the discussion today, because we won't have any new information in 2 weeks. And so, like the more we push these like, the the more we we end up having to make the discussion rushed. So yeah, I would just argue for that. We should today decide to include this. That doesn't mean we can still wait for Devnet 2 to actually like have it in the Devnets. If that's preferable. I think there's no reason to not do it in devnet one. But yeah. And then we can still, for example, like, I do think the one consent that is reasonable is this question of

whether that that basically that constant parameter should be so high that it at least like somewhat meaningfully now, is, is a portion of the overall cost of of a blob transaction, even even if the the it's at at the floor level. But that we can. Then we can decide. In 2 weeks we can do in 2 weeks. We can have, like a proposal comparing, like, say, 2 different values for this parameter, one very conservatively low one a bit like this, this higher proposal. See just concrete numbers of like in terms of dollars, dollar terms like, what? What would the percentage change be for for sending a blood consection in either of these scenarios, and then just choose one of the 2.

And and so, if that means that we would want to like. Wait until Devnet 2 to even just include it in the Devnet. That's fine. I think it could already be implemented as of today.

Tim Beiko: Yeah, it would be towards if if we think we want to do this, and it's a question of what the fee is, then I would move it to Devnet one, because we have less stuff for devnet one right now. And this is a fairly simple addition. yeah. So I guess.

Ben Adams: I I would be very for being in that one's fine. It's a it's an easy implementation. And since in Fusaka we're including Bpo forks, and you know we're constantly changing. We're messing with the blob supply continuously after Fusaka. I think it's quite important to to stabilize the market.

Tim Beiko: Okay, so any objections to moving it into devnet one, and we can obviously tweak the constant as we as we learn more about the impact. But at least we'll have this implemented in clients and and tested okay, so let's do that. Let's move this one to devnet one and then the last vip on our list was the pay up code this one was the one that had the most, I guess uncertainty around. So Aragon was against it. Basically another mind maybe disagreed on when we should do it. So I don't know. Yeah. Geth and Ruth, do. The 2 of you have opinions about it.

Lightclient (Matt Garnett): Sorry, which one again.

Tim Beiko: At pay OP. Code 5, 9, 2 0.

Lightclient (Matt Garnett): Yeah, Millie, and I'll just some comments on the East magicians thread. But I understand that a lot of people really think pay is important. I'm a bit worried about the implications on our compute model because sending yeth without execution makes it difficult to do accounting nicely. But obviously we can already do this today with self-destruct. So it's not really like, it's adding new functionality. I'm kind of indifferent. But we have a lot of vips that we are considering to include. So maybe it doesn't make as much sense.

Tim Beiko: Any thoughts from Russ, I would break the current mev boost flow.

Roman: Yeah, in a way that currently delays validations. That that that the sender is the I guess maybe you cannot trigger the payoff code in the payout transaction. It just proposes the often that the tier recipient to to like a contract address, and they do different kind of stuff with the East that they receive.

Tim Beiko: Okay. So I just because we're also kind of getting no on time. And this one was kind of contentious. I would maybe not remove it now. But I think in the next 2 weeks, like, yeah, if client teams want to review that one alongside the 3 other ones we're considering for Devnet 2, which is 7, 2, 1, 2, 7, 9, 0, 7 and 7, 9, 3, 4. And we can make a call about which ones we include is that make sense? yeah, so, and and I'll update my message here that I had in the chat. But so in practice, it means that for today we we would have 7, 8, 2, 5 and 7, 9, 1, 8 indefinite one we review 7, 2, 1, 2, 7, 9 0, 7, 7, 9, 3, 4, 5, 9, 2 0 over the next 2 weeks. We've removed 7, 7, 6, 2, and then on the Cl call this next week we should review the proposal. Look ahead. Vip 7, 9, 1, 7.

Yeah. And okay. Anything else on Fusaka. Scope. Yeah. So only 2 new vips for definite one. Yeah. And the goal is, we launched one before on on June 9, th at the latest. Okay, testnet deployments. Alan wrote this post on. If they are magicians a couple months ago. Alan, are you on the call? Oh, I'm not sure.

Oh, I don't think she's on the call. So basically, okay, the idea was that we should really avoid breaking test nets for application developers, and and and basically try to get a commitment that Hoodie should be that Hoodie should be the kind of long term application testnet. Meaning that at the very least we should fork it only only like when, as the last testnet, when we're when we're sure. yeah. So I guess, do people feel strongly about like trying to keep Hoodie the last testnet that we fork one one concern is that we'll never have. So okay, so supportives. Yeah, so sorry. So one concern is that we'll never have like a perfect staging environment unless we

unless we effectively fork it after after magnet. Because there's always a risk of bugs but then sepolia is not sufficient to deploy complex lst protocols. So they they kind of need Hoodie for that. And therefore, like, yeah, we would want to make Hoodie more of a a hey? A app like stage environment. And oh, and I think Alan just joined.

Alon Muroch: Hi, everyone! Thank you for having me.

Tim Beiko: Yeah, do you want to give a quick context on your proposal? I was just trying to to summarize it, but doing a poor job of it.

Alon Muroch: Yeah, I would love to. So my name is Alan. I'm from the Ssb network. they're running a DVD network. We've kind of went through the entire kind of prices quote unquote with the with the last fork it became obvious that stability and test. This is something that is, has has a lot of value for developers both in terms of not needing to or test nets, integration testing and also in general stability, gives a lot of value to just developing and and kind of predictability and development. And so, after the latest works for that came up with the idea of maybe proposing at least one testnet that will be stable long term, and also as close to Mainnet as possible in terms of its in terms of our risk appetite, meaning that we fork it last, and we don't quote unquote experiment with it, but rather it's quite literally a a minute from gonna be forked a minute before maintenance.

And so I wrote about it in iter magicians, and then Tim and others, suggested I. I open it up to this conversation where the proposal is really to take Hoodie and try to make it after develop a testnet long term encourage a lot of developers to treat it as their stage environment, meaning for them to deploy their contracts. That's really important for integration testing and and so on. And maybe, more importantly, is to try to work with the with mainnet, or as close as possible to Mainnet, and not as a a testing for, but rather just a fork that needs to happen both on Mainnet and Hoodie the result of that will be signaling to the developers and in general signaling to everyone that Hoodie is really here as a really really stable testing for everyone to deploy their contract

and make sure that make sure that we don't have those issues like we had before, where either test nets forked out. Not in a good way. And then we kind of got stuck without test nets or every 6 months, maybe 12 months changing tests, which in of itself is quite difficult for developers to do so. That's kind of my my summary of of everything.

Tim Beiko: Okay, thanks for sharing. So there's a couple of comments in the chats around. yeah, like that. It's it's kind of hard to have forever running test nets. But I don't know. Like, yeah, Barnabas. yeah. Like clients. You want to add more.

Alon Muroch: I. I know that I spoke with a a bunch of people from the FI think there is a kind of a people don't really want a a forever going testnet. I would actually, maybe challenge that. And I'm not entirely sure. Why, why, it's a bad thing. We have a forever going mainnet. So why not have like a forever going stage environment? But but even a a very, very long term best net, which is there is as minimal risk as possible in terms of forks and also actively encouraging developers to treat it as their stage environment. So we can have a lot of different projects having their contracts there in a stable manner will really help with a lot of the integration testing and in general, just the stability and predictability of developers.

Tim Beiko: Right? And I think, okay. So the the challenge with these long term test nets is always just the state like, they become harder and harder to to maintain and there's kind of no incentive for anyone to run nodes there. So historically, you know, most of the nodes on these test notes are run by client teams and and the Ef devops teams so you could imagine. So I guess what Barnabas is suggesting now in the chat is, we could also imagine just having a community run test nets. That's long running. That even forks after mainnet the challenge is actually finding people to run those nodes and do so over the long term.

Alon Muroch: Maybe I have. Maybe I have a suggestion there. So most of the staking intra and applications already have a substantial amount of nodes running just because of the nature of what they, what they're building. And so potentially, we can harness them. For that, a, basically them taking the the bulk of the work of running those test nets. It's it's gonna be favorable with them as well, I know. projects like Lido and us. And others really really want that stability. And we also obviously run tested nodes. Because because we're doing a lot of testing around staking and infrastructure we're building. And so potentially, there is a way for guaranteeing a kind of a community driven where the base of it is

those types of projects which anyhow, need to run a lot of infrastructure for testing because of the nature of their of their products. And also we can harness others. Maybe I don't know from the top of my head. Maybe a project like gnosis really needs nodes as well, because that that's something that you know, they constantly need to make sure their their development is going correctly and also their users have a lot of integrations to know. So maybe that's beneficial for them as well. So maybe we can, we can find this set of of community projects of of community members that willing to to run it long term 6 years is amazing. but realistically, if I look at different networks for different things realistically, we are finding ourselves jumping from Tesla to test quite more frequently than I would love to.

Lightclient (Matt Garnett): I feel like you're conflating tests, testnets, and devnets here, though, like you've listed these Yolo devnets, and they're not really intended to be used by developers since the launch of Sepolio. We've kind of had this plan of having minimum 5 years per testnet. for, like many of the reasons that you're describing. So I think it's important to disambiguate the fact that there are pretty long running testnets. The main issue that we've run into is that there was a hard forking bug recently on Hawashi. and had we not.

Alon Muroch: Not only that. Sorry. Go ahead.

Lightclient (Matt Garnett): I'm just saying, had we not had that, I don't think that we would be having this conversation.

Alon Muroch: We, we definitely felt test. Let's we're jumping from Tesla to test it. More rapidly, more frequently than we would have wanted, maybe. Sepholia, for example, is is long running, but not everyone is on sepulia and and we did like going back to Prader and others. We did find ourselves much more frequently than 6 years changing pending tests for various reasons. So it's not always the intent. But that's realistic.

Lightclient (Matt Garnett): I mean sure.

Alon Muroch: At least this is our experience.

Lightclient (Matt Garnett): Sure I mean I totally get it, especially when the merge was sort of happening and the testing was happening. Then it totally makes sense the timelines were far shorter, but I think now we are in a much more solid position, and we have made a pretty strong commitment to having test nets 5 to 6 years. And so like you can definitely expect that there is an issue with Haleshki that we have to fix, and we should have a higher standard for what we put onto test nuts at the end of the day. We have a good track record for forking test nuts, and we've only had one hard forking bug in like the last 5 or 6 years, we should continue to minimize that. But sometimes it happens, and it's devastating for

the whole testing ecosystem.

Alon Muroch: I just don't really know if there's a way around that I think it's it's a it may be a matter of just defining, you know, in a way that is is much more communicated, much better to to developers, and also kind of enforcing those. So if if we do say, okay, this particular test is for 6 years maybe a decision to minimize the risk in terms of the force it it goes by. Again very close to Mainnet, or even after Mainnet, or with Mainnet even those small decisions will will greatly affect the stability of it. So it's it's less about having a dedicated test net more about like setting a a few. I don't know. I don't want to say rule, but, like, put a few conditions of how we treat those tests. It can get really go a long way. Instability.

Tim Beiko: So I think I I think one thing we we can do is commit to forking sepulia first.st and that historically, we kind of didn't want to do this. We thought Hoodie would be kind of the more chaotic test net. But then we we kind of realized that because of the open validator set. There's a bunch of stuff that can only be tested on Hoodie, I think, generally forking support. Your 1st is is a good approach there in terms of forking after Mainnet, or at the same time as Mainnet. Then, like, yeah, that feels like a whole new test net. We'd have to stand up, because realistically, we generally only have 2, and there's value in getting 2 kind of dry runs before mainnet

But then, yeah, that's maybe something that the community could stand up, which is like effectively a main net staging environment that only forks after. yeah.

Alon Muroch: After. It's maybe too aggressive, but very, very shortly before or right with the mainnet will be, will be great. And and again, I think it's it's about risk. Right? So if if there, if we're forking in order to test something, then we're carrying more risk on that test net, and that's fine. It's a staging environment that's fine. But I think that that's kind of there's a trade off between that right? So so maybe.

Tim Beiko: There is, and realistically, like we, the thing, the thing like we do try to minimize that risk as much as we can through devnets. But there are some things that end up only being possible to test in like semi production environments like test nets. So like we'll never get the risk to 0. I think we can more clearly communicate that like, okay. Well, for Kaleshki first, st and then Hoodie, or sorry we're for sepulia first, st and then Hoodie, meaning that, like Hoodie, should be least risky to be forked. But yeah, realistically, that risk is not 0. And we. you know, barring having another test net that only forks after mainnet. I don't think that there's a solution that brings your risk to like

equal or less than Mainnet. And yeah, potentially like, yeah, we could have just done this slower for for Petra. Yeah, I'm and and I guess on the comms, too. Like, I think we can. We can definitely make that clear. Like as we're working on the fork, like, okay? Which test notes are forking. And when and and why? yeah.

Alon Muroch: What about encouraging? Or, you know, gently pushing more developers to really have a a stable instance of their contracts on whatever testing. It's gonna be to really improve integration testing. And in general, the kind of between.

Tim Beiko: Yes, we do this, but they they don't listen to us. Yeah.

Barnabas Busa: So can I raise a point here.

Alon Muroch: Yeah, well.

Barnabas Busa: So I really wish everyone would deploy everything as soon as possible on that. And it's just not realistic, because that nets will break a lot. So this is why we have testnets. And this is why we have. the the longer equipment runs, basically the less it's going to be deployed on the on the future, that not because everyone that deployed on, for example, might have left the company, and whoever they hired have no idea how to deploy on the new testnet. So this is why I think it would be actually better to have more, not less. That's not.

Alon Muroch: So.

Barnabas Busa: We want everyone to deploy everything on the test net and make deployment basically as easy as possible and as automated as possible. So if anything, we should probably aim for left. That's not not more more. That's not left.

Alon Muroch: I can. I can only kind of speak from our experience. Right? I can only speak from our experience. But there's definitely more than one test that people are referring. We, for example, find ourselves booked on sepulia and and and Hoodie, for some reason for the same set of contracts. And so I can only kind of. you know. Reflect what what we've experienced. So Every much less than 6 years trying to kind of page test nets definitely using more than one for the same set of contracts. And and and I think that kind of if I need to put like a goal in mind about how an amazing test it should look like it's it's something along the lines of. I don't know if anyone ever interacted with the stripe

stage environment. It's it's amazing, the developer experience. There is amazing that that's kind of my my beacon of hope where tested can be and should be and I think we're quite a long way from there. yeah, that that's kind of from my experience. And what we've been been through the past couple of years, maybe 3 years.

Tim Beiko: And I think, like, yes, this is kind of a qualitatively different thing almost, which is like we having a staging environment that forks after Mainnet might look different than having a test set that we test upgrades on and and in practice, like, you know, if you're if you're like a company like or a project like Ssv or Obol, or like any other liquid staking provider you gonna kinda have to be on all of them because you're working. You're not just like writing contracts. You're you're working on like core staking infrastructure. But then, if you're just, you know, say, like a uniswap, or like a you know, any kind of defi or nft contract that that doesn't

actually interact with the validator set in like a a complex way. And you can imagine having, like a pretty good stage environment that's just based on that that just forks after Mainnet, and and that that brings the risks to basically 0. But it still be harder to do for something like staking pools.

Alon Muroch: I can. I I don't wanna name names, but it's it's not. It's from our. It's not just you know the the types of apps which are going for the info taking in front and and the user user facing size. A lot of kind of core, not core, but like very, very common types of applications. It's it's a lot of a lot of work to get them to work on on stage environments, and I think a lot of that is is because of that ambiguity. Where? Where should I deploy? How? How stable it is, and so on. And and and again it, it goes back to the developer experience, and how easy it is to build something mo-. Most applications are not standalone. Most application interaction with other types of contracts. I think from ens to nurses, to oracles to anything right? Other than that.

Yeah.

Tim Beiko: Yeah.

Alon Muroch: And.

Tim Beiko: Okay, I just wanna be mindful of time here, like, I think, yeah, I I think we should. We should table this for now. But I agree that there's probably something around application development that we can build. That's better. But the current, like core dev test nuts beyond just moving to Houdi being the last one and reducing risk. I I don't think we can. We can significantly change. Yeah, like client. You want to discuss the Rpc proposals.

Lightclient (Matt Garnett): I think I saw Zane on the call. saying, Did you want to mention.

Zane Starr: Hey? Yeah, thanks. Hey? Zane. Here from Openrpc, we actually do a lot of the documentation work for the Apis and things like that. And so recently, what we've done is we've overhauled Openrpc the ecosystem. So they're kind of new major version bumps so like for 2 XI did see a change coming in for like docusource, because people were having a hard time running locally. But actually the newer version, which is like on 2 X for the generator. Generates things like sort of locally. It allows you to run everything with the modern nodejs ecosystem things like that. There's other things like spac extensions. Which we just added. So there's now a roadmap to add new items into

the spec and to support things like error groups which I'm gonna pass this over to Raj very shortly to talk about the error groups. Proposal I'm gonna link drop real quick. But boom! So yeah, basically, there's a lot of cool things that we can do in the spec now that we weren't able to do before. And we've been working with chain link to like allow clients to be able to specify Error codes and a more sustainable way, because currently within the spec, there's only like one error code. But there's a lot more error codes that are out there. And it's a question of like, how do we organize things? and get that going. So I'm just gonna pass this over to Raj because he's done a lot of the implementation work.

And from the open Rc side. We've just been updating the ecosystem to do more awesome things, and I recommend you check out the tools repo because, like again, we've started overhauling things. So use no. Js, 20 whatever, and you'll be good to go. Okay, Raj, you wanna take.

Tim Beiko: Thanks. Sorry. So we are kind of at time. Yes, sorry about that. But I asked in the chat like, where can people kind of discuss this, and I think there's a and so there's a chat on the discord. But is there also, like a Rpc. Standardization called next week. Is that right? That might be like a better place.

Justin Florentine: That's right. That'll be 8 o'clock on Monday.

Tim Beiko: Yeah. So I think that might be a better place to have like a longer, deep dive discussion. Because I we're already at time. And there's a couple other things that we need to draw people' attention to. Sorry about that.

Zane Starr: Okay.

Tim Beiko: Do you have access to the discord and all of that.

Zane Starr: Yeah, I can drop this in the Rpc. Channel and discord which discord you've already.

Tim Beiko: Yes. Correct.

Zane Starr: Okay.

Tim Beiko: Okay. Thanks.

Zane Starr: Thanks.

Tim Beiko: I'm okay. And so we didn't have time to get to the Glam Saddam stuff today. I think it's just fine. We can discuss it in 2 weeks. Obviously, we shouldn't we? We should. we should basically figure out Fusaka before before we do that and then, in addition to this Rpc proposal, there were 2 other proposals that people wanted to get feedback on. So I'll just post these in the chat. And yeah, people can can review those Async and then in terms of next steps. So next week let's make a decision about the proposal. Look ahead, the IP on the Cl call, and in the next 2 weeks finalize the decisions for a definite 2, and by definition, what

kind of exclude everything else from Fusaka. So we have at least a full scope. Anything else before we wrap up. Okay? Well, yeah, thanks everyone and talk to you all soon.

Pooja Ranjan: Thank you.

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