Tim Beiko:Okay, welcome everyone to acde number 212
Transcript
Tim Beiko: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.
Tim Beiko: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.
Tim Beiko: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
Tim Beiko:before we jump into the Fussaka planning discussion. Perry, do you want to give us an update on the current state of implementations.
Barnabas:Yes, I can. I'm not sorry, but
Barnabas: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
Barnabas:probably request our clients to have backfill working by like Devnet one or Devnet 2.
Barnabas: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
Barnabas: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
Barnabas:we recently as well, and they were also able to sync up to head. And
Barnabas:I made some deposits, and they have some index returning, and we have 100% participation.
Barnabas:So that is, regarding Devnet 7. And on Monday we plan to launch physical devnet 0.
Barnabas:And I am actively testing now the different client combos we have grandin prism load start deku working on the cl side
Barnabas:and get on the yeah. 3, rd as of now.
Barnabas:we're still waiting for nimbus and lighthouse to have the branches published for this year, and pretty much all the other ears to.
Barnabas: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.
Parithosh Jayanthi: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:Eventually, yes.
Tim Beiko:So we we have not yet, but we we will.
Barnabas:We? We haven't yet. We have a critic test for basically creating a perfect pure desk network where we have 16
Barnabas:16 nodes. And each node is basically just
Barnabas: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: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.
Tim Beiko:Oh, new consensus specs releases nice.
Barnabas: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.
Tim Beiko: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.
Andrew Ashikhmin:once, like the engine Api changes and the
Andrew Ashikhmin: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.
Som | Erigon:Sorry. Yeah. So well, I think we might be able to publish. A branch
Som | Erigon:may not be merged into main yet, but oh, we can do that.
Tim Beiko:Okay.
Tim Beiko:okay, anything else on this academics?
Tim Beiko:If not, then. Yeah. So
Tim Beiko: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.
Tim Beiko: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
Tim Beiko: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.
Tim Beiko: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
Tim Beiko: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
Tim Beiko: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
Tim Beiko:like this 3 teams, one of them in Devnet one.
Tim Beiko:I'm yeah. I'm curious. Guess, Russ, how do you feel about those.
lightclient:I'm honestly still trying to understand what the transaction gas cap is trying to target.
lightclient: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
Roman:like it. It really helps
Roman:with prevailization and not not having to care about this worst case. One transaction that you cannot like, execute in preval or pre-worm.
Roman:or do anything with it, is it how to do it sequentially.
lightclient: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.
lightclient:you know, with 7,702, we're almost certainly going to see an increase in the average transaction size over the next 12 months.
lightclient: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
Andrew Ashikhmin:we'd like to avoid massive transactions.
Andrew Ashikhmin: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:Why is it not fair to the protocol?
lightclient: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
Tim Beiko: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
Ben Adams:a transaction that's the size of a block. So as if it's
Ben Adams: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:Yeah, I just wanted to say that
Giulio: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
Giulio:2 transactions per block instead of one. It's it's just 21,000 gas.
Giulio:It's not that much? Really?
Giulio: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:Well to do that, we would have to have the individual operations in the bundle exposed.
lightclient: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:Correct.
Dankrad Feist:Right? Right? Right?
Dankrad Feist:Okay.
lightclient: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.
Dankrad Feist: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
Ansgar Dietrichs: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
Ansgar Dietrichs: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
Ansgar Dietrichs: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.
Łukasz Rozmej: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
Łukasz Rozmej: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
Łukasz Rozmej:and in terms of when to introduce this kind of cap, the sooner the better, because this is hard to retroactively change.
Łukasz Rozmej:I think 30 million is, you know
Łukasz Rozmej: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: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.
Ben Adams:they would have to run serially.
Ben Adams:and it would take double the time. So I mean, it's even better that way.
lightclient:We don't have block access lists.
lightclient:So.
Ben Adams:Yeah, but it's proposed for lunch today.
Barnabas:Isn't this like a security
Barnabas: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
Ben Adams:and of the last.
Ben Adams:Was it last 30 days.
Ben Adams:The only transaction above 5 million guests were scam, scam, token sense, and Zen contract mining.
Ben Adams:which can easily be batched in smaller amounts.
Ben Adams:They're they're just massive batch transactions.
Ben Adams:and they could be bachelors. A smaller level.
Tim Beiko:Right? So the
Tim Beiko: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.
Tim Beiko:They're amortized across 2 or 3 transactions versus one.
Tim Beiko:So it seems like given that the potential risks.
Tim Beiko:Yeah, of of not having this and raising the gas limit, we should probably move forward with it.
Tim Beiko:Yeah, any other objections.
Tim Beiko:And yeah, in Amsterdam. We can always revisit if if we want to.
Tim Beiko:Okay. So let's move eip 7, 8, 2, 5 to Sfi. Add it to the devnet, one spec.
Tim Beiko: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?
Tim Beiko:so yeah, the idea there is to add a cap to the Rlp payload to match the Cl. Gossip, cap.
Tim Beiko:I don't know if Guest breast 2 of you had opinions on this.
Roman:For him.
Marius:I like the idea of capping the the size of the block.
Marius: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
Marius:coding can be quite weird.
Marius:But yeah, I think in general, this this idea of
Marius: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
Tim Beiko: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
Ben Adams: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?
Paweł Bylica:I mean, who?
Paweł Bylica: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
Paweł Bylica:delivers this block to the yeah. Right? So it knows already that it's too big. So
Paweł Bylica: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.
Ben Adams:not build blocks too large, and also
Ben Adams: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
Paweł Bylica: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
Łukasz Rozmej: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: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.
lightclient: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.
Ben Adams:For the every transaction or anything.
Paweł Bylica:But they don't necessarily add up to the to the like, the the results
Paweł Bylica:until you actually encode it right online, we need to predict what the encoding will be on the fly.
Ahmad Bitar | Nethermind:Receipts, though. No, only the receipts
Ahmad Bitar | Nethermind:like. If that transaction is Rlp. Encoded already.
Ahmad Bitar | Nethermind:you can just add that number and then see if there is any receipts also, and.
lightclient: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:And if they don't come from the network.
lightclient:if they come from Json, Rpc.
Ahmad Bitar | Nethermind: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: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
lightclient:it seems like it would be useful to actually see what the impact is on.
Łukasz Rozmej:So.
lightclient:People who are building Mev blocks.
Ben Adams:Either either that or the blocks fail.
lightclient: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:No.
Ben Adams:That's that cannot be gossiped. So
Ben Adams: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:But like, you guys need to encode it
Giulio: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.
Giulio: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
Giulio: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.
Giulio:right like.
Ben Adams:Yeah, it's just it's just the calendar.
Giulio:Canceled additions.
Ben Adams:It's just the bytes at the front of the block with of the count of transaction.
Giulio: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
Giulio:to sum a bunch of numbers.
Ben Adams:We. We have already implemented this another mountain. It's not very hard.
Ben Adams:So we re when we're picking transactions, we reject transactions. If it if it will cause the block to become too big.
Ben Adams:which we had to do for perfnet. And it's 5 gig of gas limit.
Ben Adams: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.
Paweł Bylica:but maybe it's time to present it. So
Paweł Bylica: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.
Paweł Bylica:I'm I'm slightly concerned about how we're actually going to test this, because
Paweł Bylica:I'm sure I want to see like 10 plus
Paweł Bylica: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:The check on the Cl is on the uncompressed size, though.
Giulio: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:Okay.
Mario Vega:Yep.
Tim Beiko:Okay. So if we have an implementation, the testing to work, and it seems relatively easy to
Tim Beiko:calculate this as you're rebuilding the block.
Tim Beiko:Does it make sense to move forward with it? And that's on the test net.
Tim Beiko: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.
Ben Adams:So before you do anything, just check the the size of the the message.
Marius: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
Tim Beiko: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.
Roman:And then you can proceed. I think this is not ideal.
Tim Beiko:Julia.
Marius:That's kind of what I'm.
Giulio:Sorry.
Giulio:Yeah, it's kind of.
Marius:Sorry you kind of what I'm saying with the
Marius:the I I do like this eip. I just don't know if
Marius: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.
Ben Adams: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.
Ben Adams:you can just check its size before trying to decode it.
Ben Adams: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
Tim Beiko:don't have a great understanding if the designs
Tim Beiko:space. So should we just
Tim Beiko: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.
Tim Beiko:okay.
Tim Beiko:Yeah. Judo.
Giulio: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
Giulio:the some of the transactionalp, and not the rest of the block, because you are actually forwarding the adder.
Giulio: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.
Giulio:so you know the size of the other. So you there is no need to keep it out just
Giulio:to have a slightly simpler way like it's equally simple.
Giulio:essentially. So. That's why I didn't really like the design. When I 1st it was 1st proposed.
Tim Beiko:Got it?
Tim Beiko: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.
Tim Beiko:I'm and then, okay, so of the other eips
Tim Beiko:the sorry. Let me just look at the list real quick.
Tim Beiko: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,
Tim Beiko: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.
Tim Beiko:These are kind of the other all the other vips that are that are being
Tim Beiko:that we're already cfi'd in without them. We still.
Tim Beiko: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.
Tim Beiko:Okay, so
Tim Beiko: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.
Roman: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
Roman: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
Tim Beiko: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
Tim Beiko: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
Ben Adams:if, our if our goal for free soccer, I believe, is performance.
Ben Adams:And we're increasing the gas limit. And we're
Ben Adams:potentially increasing the slot times.
Ben Adams:next to it, there's a there's a lot of moving pieces. If we then increase the contracts to 256
Ben Adams:Kilobytes and the init code to half a Meg.
Ben Adams:So it feels like there's too many unknowns with it.
lightclient:I mean, that's why we meter it, though, so you can
lightclient:appropriately charge for loading the code.
Ben Adams:Yeah. But as a
Ben Adams:I don't feel the analysis on the the metering doesn't feel properly looked into at the moment.
Ben Adams:I agree that it is me, too. Yeah, but
Ben Adams:I'd like some more research around it.
lightclient:Like, what kind of research
lightclient: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.
Ben Adams:We've done a lot of study on the state database. But the code database.
Ben Adams:I don't think we know much performance characteristics of it
Ben Adams:across plants.
Ben Adams:I mean, for example, the amount of work that's being put into.
Ben Adams:you know, can we increase the gas limit to 60 million
Ben Adams:is is quite extreme, whereas the amount of
Ben Adams: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
Ben Adams: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:Why would state bloat have anything to do with this.
Ben Adams:Okay? Code, code blue.
Ben Adams:Because why does code.
lightclient: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.
lightclient:And because we can meter based on how long it takes.
lightclient: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.
Ben Adams:You can add in a single transaction.
Ben Adams:Quarter of a megabyte of permanent storage.
lightclient:I mean, you can already do that today. You just have to split it across multiple contracts.
lightclient: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.
lightclient: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.
lightclient: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.
Tim Beiko:Yeah, Powell.
Paweł Bylica:The one off of the cost
Paweł Bylica:factors is jump this analysis to my understanding of the IP. And I think to my understanding of Vm as well.
Paweł Bylica:For that I I plan to do benchmarking, anyway, in some other context, but I think I can commit to
Paweł Bylica:prepare some report about this this kind of performance.
Paweł Bylica:and for for the next call
Paweł Bylica: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
Paweł Bylica:we definitely need to track it. So I will do some.
Paweł Bylica:Yeah, we'll propose some benchmarks that
Paweł Bylica: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.
Paweł Bylica:It's the one from that cups. The
Paweł Bylica:wow. Okay, I'm kind of mixing 2 2 dimensions here. But
Paweł Bylica:yeah, I can. I can. If you want. I can describe like benchmarking scenarios in the next day, and
Paweł Bylica:if that's accepted, I can then work on this to get the number so, or we can prepare the
Paweł Bylica:the benchmark in some format that anyone can try later.
Tim Beiko:Okay? And I guess so for the cip,
Tim Beiko: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
Tim Beiko: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,
Tim Beiko:and yeah, try to at least get definite one done today. Because, yeah, there's other Vip that big people
Tim Beiko: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.
Tim Beiko:And then okay. So the other.
Tim Beiko: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
Tim Beiko: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
Nicolas Consigny:unlucky us there is like a slight issue with the existing rip. It's not a big big issue, but
Nicolas Consigny:with crypto precompied. You can't really allow any type of uncertainty.
Nicolas Consigny:so we should just either rewrite the vip with a small fix and discuss with the
Nicolas Consigny:roll-ups that have already implemented it so they can maybe fork out and go to the new version.
Nicolas Consigny: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.
Nicolas Consigny:So just rewriting the Vip should be, or I mean writing a new IP, I think should be the best.
Nicolas Consigny:Pass forward. And yeah, and
Nicolas Consigny:working out of the air. IP. 7 to 12 for existing for existing roll-ups.
Nicolas Consigny:I will contact the others to see if they want to champion this or I. We can probably
Nicolas Consigny: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
Nicolas Consigny:Antonio, I I guess. Yeah, I guess probably having Antonio from the cryptography team, and maybe
Nicolas Consigny:Renault from the Kennox who wrote one verifier would be great I would, if
Nicolas Consigny:if I could force them to do it, I would.
Tim Beiko:Is there anyone else on this call who can like?
Tim Beiko:And the next 2 weeks looking into this
Tim Beiko: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
Nicolas Consigny: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
Andrew Ashikhmin:keep the original contract at the at the Rip address unchanged.
Andrew Ashikhmin: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.
Tim Beiko:like, yeah, that feels like a no brainer. Yeah. Adrian.
Hadrien Croubois (OpenZeppelin):Yeah. I just wanted to say that I don't think it's just about Rip 7, 2, 12,
Hadrien Croubois (OpenZeppelin):Adrian, your mic is cutting.
Hadrien Croubois (OpenZeppelin):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.
Hadrien Croubois (OpenZeppelin):and I don't think solidity wants that either, like nobody wants that.
lightclient: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.
lightclient: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.
Tim Beiko: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
Andrew Ashikhmin: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 (OpenZeppelin):That would be great. Yes.
Tim Beiko:Yeah, they can obviously redeploy it. Yeah.
Tim Beiko: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.
Tim Beiko:Does it make sense to people.
stokes:Yeah, let's do it.
Tim Beiko:Yeah, and so to, I guess to recap. So right now
Tim Beiko: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
Tim Beiko:and increasing that for Devnet 2 potentially looking at 7, 2, 1, 2 for devnet 2 potentially
Tim Beiko: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
Tim Beiko:in flight that we need to figure out for that bit, too.
Tim Beiko: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.
Tim Beiko:And I think, let me check real quick.
Tim Beiko:so basically, never mind. Aragon all wanted it in Devnet, too. I don't know, Geth and rest how you feel about it, but
Tim Beiko: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:Sorry, which one.
Tim Beiko:S. 7, 9, 1, 8. The blood base fee change.
lightclient: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
lightclient: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.
lightclient: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.
Ansgar Dietrichs: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
Ansgar Dietrichs: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
Ansgar Dietrichs: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.
Ansgar Dietrichs: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
Ansgar Dietrichs: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.
Anders Elowsson:yeah, yeah. So I can use.
Anders Elowsson: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.
Anders Elowsson:And
Anders Elowsson: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.
Anders Elowsson: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
Anders Elowsson:posted. But it's just a change of constant, actually.
Anders Elowsson: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.
Tim Beiko:does anyone feel strongly? We should include in Devnet one. Otherwise
Tim Beiko:we can discuss this in the next 2 weeks and then see if we want to include it in Devnet, too. But I
Tim Beiko:I will flag that we. We're starting to have a bunch of stuff that's like Tbd for Devnet 2.
Tim Beiko:no.
Tim Beiko:yeah. Okay. So no strong support for devnet one.
Tim Beiko:Then.
Tim Beiko:Okay. The last one we we haven't discussed yet.
Tim Beiko:Well, I guess. Why not the net one? I don't. I don't think any team has signaled towards that, and then
Tim Beiko: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.
Ben Adams:we already have a Pr for it.
Tim Beiko:Okay. So never mind.
Tim Beiko: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
Tim Beiko: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
Ben Adams:and then we're having Bpos. So we're we're messing in the Blob market massively in terms of supply.
Ben Adams:So it's better to have it in before that.
Tim Beiko:Yeah, there's a question on unders. Do you know.
Tim Beiko:what? What do we expect the change on fees to be? And I know there's many different
Tim Beiko: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
Anders Elowsson: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
Anders Elowsson: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.
stokes:And maybe just to reiterate, how exactly, then, does it improve the functioning of the fee market
stokes: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
stokes:better functioning fee market.
Anders Elowsson:Yeah, that's.
stokes:Such as.
Anders Elowsson:Well, so essentially blob consumers are affected by the the execution base fee
Anders Elowsson: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
Anders Elowsson: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.
Anders Elowsson: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: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.
terence: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.
terence: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.
terence: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
terence: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
Ansgar Dietrichs: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
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs:And
Ansgar Dietrichs: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.
Tim Beiko: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.
Ben Adams:And since in Fusaka we're including Bpo forks, and you know we're constantly changing.
Ben Adams:We're messing with the blob supply continuously after Fusaka.
Ben Adams:I think it's quite important to to stabilize the market.
Tim Beiko:Okay, so
Tim Beiko: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
Tim Beiko:okay, so let's do that. Let's move this one to devnet one
Tim Beiko: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.
Tim Beiko:Yeah. Geth and Ruth, do. The 2 of you have opinions about it.
lightclient:Sorry, which one again.
Tim Beiko:At pay OP. Code 5, 9, 2 0.
lightclient: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.
lightclient:I'm a bit worried about the implications on our compute model because
lightclient:sending yeth without execution makes it difficult to do accounting nicely.
lightclient:But obviously we can already do this today with self-destruct. So it's not really like, it's adding new functionality.
lightclient:I'm kind of indifferent.
lightclient: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.
Roman:That that
Roman:that the sender is the I guess maybe you cannot trigger the payoff code in the payout transaction. It just proposes the
Roman:often that the tier recipient to
Roman: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
Tim Beiko: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
Tim Beiko:make sense?
Tim Beiko: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
Tim Beiko:we would have
Tim Beiko: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.
Tim Beiko:Yeah.
Tim Beiko:And
Tim Beiko:okay. Anything else on Fusaka. Scope.
Tim Beiko:Yeah. So only 2 new vips for definite one. Yeah. And the goal is, we launched one before
Tim Beiko:on on June 9, th at the latest.
Tim Beiko:Okay, testnet deployments. Alan wrote this post on. If they are magicians a couple months ago.
Tim Beiko:Alan, are you on the call?
Tim Beiko:Oh, I'm not sure.
Tim Beiko:Oh, I don't think she's on the call.
Tim Beiko:So basically, okay, the idea was that we should
Tim Beiko:really avoid breaking test nets for application developers, and
Tim Beiko:and and basically try to get a commitment that Hoodie should be that Hoodie should be the kind of long term application testnet.
Tim Beiko: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.
Tim Beiko:yeah. So I guess, do people feel strongly about like trying to
Tim Beiko:keep Hoodie the last testnet that we fork one
Tim Beiko:one concern is that we'll never have.
Tim Beiko:So okay, so supportives. Yeah, so sorry. So one concern is that we'll never have like a perfect staging environment unless we
Tim Beiko: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,
Tim Beiko:yeah, we would want to make Hoodie more of a a hey?
Tim Beiko:A app like stage environment.
Tim Beiko:And oh, and I think Alan just joined.
Alon Muroch | SSVLabs: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 | SSVLabs:Yeah, I would love to. So my name is Alan. I'm from the Ssb network.
Alon Muroch | SSVLabs: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
Alon Muroch | SSVLabs: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
Alon Muroch | SSVLabs: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
Alon Muroch | SSVLabs: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.
Alon Muroch | SSVLabs: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
Alon Muroch | SSVLabs:long term encourage a lot of developers to treat it as their stage environment, meaning
Alon Muroch | SSVLabs: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
Alon Muroch | SSVLabs: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
Alon Muroch | SSVLabs: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
Alon Muroch | SSVLabs: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.
Tim Beiko:yeah, like that. It's it's kind of hard to have forever running test nets. But I don't know. Like, yeah, Barnabas.
Tim Beiko:yeah. Like clients.
Tim Beiko:You want to add more.
Alon Muroch | SSVLabs:I. I know that I spoke with a a bunch of people from the FI think there is a kind of a
Alon Muroch | SSVLabs: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?
Alon Muroch | SSVLabs: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
Tim Beiko:to maintain and there's kind of no incentive
Tim Beiko: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 | SSVLabs: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.
Alon Muroch | SSVLabs: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
Alon Muroch | SSVLabs: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
Alon Muroch | SSVLabs: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
Alon Muroch | SSVLabs: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: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
lightclient:since the launch of Sepolio. We've kind of had this plan of having minimum 5 years per testnet.
lightclient:for, like many of the reasons that you're describing.
lightclient:So I think it's important to disambiguate the fact that there are pretty long running testnets.
lightclient:The main issue that we've run into is that there was a hard forking bug recently on Hawashi.
lightclient:and had we not.
Alon Muroch | SSVLabs:Not only that. Sorry. Go ahead.
lightclient:I'm just saying, had we not had that, I don't think that we would be having this conversation.
Alon Muroch | SSVLabs: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
Alon Muroch | SSVLabs:and and we did like going back to Prader and others. We did find ourselves
Alon Muroch | SSVLabs:much more frequently than 6 years changing pending tests for various reasons. So it's not always the intent. But that's realistic.
lightclient:I mean sure.
Alon Muroch | SSVLabs:At least this is our experience.
lightclient: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.
lightclient: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
lightclient:the whole testing ecosystem.
Alon Muroch | SSVLabs:I just don't really know if there's a way around that
Alon Muroch | SSVLabs: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.
Alon Muroch | SSVLabs: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.
Alon Muroch | SSVLabs: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
Tim Beiko:and that
Tim Beiko: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
Tim Beiko: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
Tim Beiko: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.
Tim Beiko:yeah.
Alon Muroch | SSVLabs: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
Tim Beiko: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
Tim Beiko: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.
Tim Beiko:But yeah, realistically, that risk is not 0. And we.
Tim Beiko: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
Tim Beiko:equal or less than Mainnet.
Tim Beiko:And yeah, potentially like, yeah, we could have just done this slower for for Petra. Yeah, I'm
Tim Beiko: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?
Tim Beiko:yeah.
Alon Muroch | SSVLabs: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.
Tim Beiko:Yeah.
Barnabas:So can I raise a point here.
Alon Muroch | SSVLabs:Yeah, well.
Barnabas:So I really wish everyone would deploy everything as soon as possible on that.
Barnabas:And it's just not realistic, because that nets will break a lot.
Barnabas:So this is why we have testnets. And this is why we have.
Barnabas:the the longer equipment runs, basically
Barnabas: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 | SSVLabs:So.
Barnabas:We want everyone to deploy everything on the test net and make deployment basically
Barnabas:as easy as possible and as automated as possible.
Barnabas:So if anything, we should probably aim for left. That's not not more more. That's not left.
Alon Muroch | SSVLabs:I can. I can only kind of speak from our experience.
Alon Muroch | SSVLabs:Right? I can only speak from our experience. But there's definitely more than one test that people are referring.
Alon Muroch | SSVLabs: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.
Alon Muroch | SSVLabs:you know. Reflect what what we've experienced. So
Alon Muroch | SSVLabs: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
Alon Muroch | SSVLabs: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
Alon Muroch | SSVLabs:and I think we're quite a long way from there.
Alon Muroch | SSVLabs: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
Tim Beiko:like we having a staging environment that forks after Mainnet might look different than having a test set that we test upgrades on and
Tim Beiko: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
Tim Beiko: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
Tim Beiko:brings the risks to basically 0.
Tim Beiko:But it still be harder to do for something like staking pools.
Alon Muroch | SSVLabs: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
Alon Muroch | SSVLabs: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
Alon Muroch | SSVLabs: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.
Alon Muroch | SSVLabs:Yeah.
Tim Beiko:Yeah.
Alon Muroch | SSVLabs:And.
Tim Beiko:Okay, I just wanna be mindful of time here, like, I think,
Tim Beiko: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.
Tim Beiko:We can significantly change.
Tim Beiko:Yeah, like client. You want to discuss the Rpc proposals.
lightclient:I think I saw Zane on the call.
lightclient: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
Zane Starr: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.
Zane Starr: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
Zane Starr:new items into
Zane Starr: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.
Zane Starr:But boom!
Zane Starr: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
Zane Starr: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?
Zane Starr:and get that going. So I'm just gonna pass this over to Raj because he's done a lot of the implementation work.
Zane Starr: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
Zane Starr: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
Tim Beiko:and so there's a chat on the discord. But is there also, like a Rpc. Standardization called next week. Is that right?
Tim Beiko:That might be like a better place.
Justin Florentine (Besu):That's right.
Justin Florentine (Besu):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
Tim Beiko: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.
Tim Beiko: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
Tim Beiko: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
Tim Beiko:kind of exclude everything else from Fusaka. So we have at least a full scope.
Tim Beiko:Anything else before we wrap up.
Tim Beiko:Okay?
Tim Beiko:Well, yeah, thanks everyone and talk to you all soon.
Pooja Ranjan:Thank you.
Chat Logs
00:01:28
Tim Beiko:We’ll take it 😄
00:03:17
Parithosh Jayanthi:https://hive.ethpandaops.io/#/?group=fusaka-devnet-0
00:03:55
Marius:Have we ever had a devnet without any supernodes? Is that something that we should test?
00:04:04
Barnabas:Replying to "Have we ever had a d..."
soon
00:04:10
Csaba Kiraly:Replying to "Have we ever had a d..."
absolutely
00:04:38
Mario Vega:@geth the failing tests in hive is due to EIP-7823
00:05:06
Justin Traglia:We’ve also made a new consensus-specs v1.6.0-alpha.0 release for fusaka-devnet-0: https://github.com/ethereum/consensus-specs/releases/tag/v1.6.0-alpha.0
00:05:50
Parithosh Jayanthi:Maybe the EEST/Consensus specs teams can tell us what the coverage status is and what’s coming up?
00:05:53
Marius:We haven't merged 7823 into that branch yet, will do during the call
00:06:10
Kamil Chodoła:Nethermind should be ready by tomorrow
00:08:14
lightclient:we should put in EIP-7212
00:09:00
Tim Beiko:7212 was +1’d by all 3 teams across devnet 1 + 2
00:09:25
Dankrad Feist:tx gas target achieves both execution and prover parallelization
would be really good to have it
00:09:50
Francesco:But what’s the problem with having 10 large ones instead of 1 huge one?
00:09:55
Ansgar Dietrichs:you can always split a 4337 bundle into several txs, no harm in that
00:10:30
lightclient:well it’s more expensive to split it out
00:10:34
Kamil Chodoła:Based on Ben data in last 30 days we hadonly 500txs bigger than 5Mgas and only single ones around 30
00:10:37
Ansgar Dietrichs:Replying to "you can always split..."
and in principle 4337 is only supposed to be a temporary situation anyway, if we ever get to native AA that would be resolved
00:10:41
Marius:I also like this because of the fairness aspect of it
00:10:45
Dankrad Feist:can the bundles apply the limit to individual transactions?
because that would still achieve the same goal
00:11:01
Ansgar Dietrichs:Replying to "well it’s more expen..."
right, so start with a reasonable cap
00:11:34
Jason Vranek:Proposals like Ultra TXs from Gwyneth use batched transactions to help with L1<>L2 composability. They rely on very very large txs for atomicity https://ethresear.ch/t/ultra-tx-programmable-blocks-one-transaction-is-all-you-need-for-a-unified-and-extendable-ethereum/21673
00:11:40
Sophia Gold:If we don't cap it now, we potentially break more thiings if we cap it in the future when the gas limit is higher
00:12:08
Tim Beiko:Is there a CR risk to have a txn == to max block size be the norm?
00:12:09
Francesco:If we’re talking about 30M gas txs, the 21k overhead is irrelevant anyway
00:12:18
Toni Wahrstaetter:We should even go to 5m or 10m. The additional costs are negligible
00:12:37
Ansgar Dietrichs:overhead is more than 21k to be fair, have to run the entire bundle processing logic twice
00:12:38
Toni Wahrstaetter:of course, might be problematic with backwards compatibility. 30m is safer
00:12:40
Ahmad Bitar | Nethermind:Replying to "Proposals like Ultra..."
IIUC, ultra TXs aren't that large
00:12:53
Ansgar Dietrichs:“bundles” are not an enshrined concept
00:12:57
Roman:what’s a bundle today?)
00:12:58
Łukasz Rozmej:Replying to "overhead is more tha..."
can be done in parallel?
00:13:27
Giulio:Replying to "overhead is more tha..."
Still not significant
00:14:09
Marius:I think its important to ship it now, before we increase the gas limit
00:14:22
lightclient:i think we can include it, i just don’t want to paper over issues with resource pricing by capping the tx limit
00:14:36
Marius:Replying to "I think its importan..."
Otherwise users will demand it to match the max gas limit
00:14:56
Ben Adams:Replying to "i think we can inclu..."
Don't let the perfect be the enemy of the good
00:14:58
Csaba Kiraly:I would also limit transaction size in bytes, so that the required settings in the network stack stay clean.
Implementations have limits, a size limit could also be derived from gas, yet it is cleaner to have an explicit size limit as well.
00:15:02
thomasthiery:Replying to "Is there a CR risk t..."
I don’t think so, it still needs to pay more fees than all other txns combined to be prioritized. And if you keep filling up blocks with single large txns it becomes very expensive (base fees will increase by 12.5% every full block)
00:15:06
Kamil Chodoła:Replying to "I think its import..."
you mean wat with another gas increase until this is implemented and released?
00:15:25
Marius:Replying to "I think its importan..."
Yes
00:15:35
Barnabas:30M gas limit per tx will be more than enough for non malicious transactions.
If someone can bring up a valid non malicious use case, we should consider raising it further.
00:15:36
Ansgar Dietrichs:Replying to "I think its importan..."
didn’t want to say it’s not urgent, more wanted to say we need it anyway
00:15:50
Tim Beiko:Replying to "30M gas limit per tx..."
Large AA bundle is what ligthclient was alluding to
00:16:14
Ansgar Dietrichs:to be clear with 30M, we should communicate that it can go lower in the future
00:16:23
Francesco:Replying to "30M gas limit per tx..."
Amortizing things from ~0 to even closer to ~0 isn’t really a use case though
00:16:34
Marc:Replying to "to be clear with 30M…"
it seems easier to go lower and raise than the other way around
00:16:45
Justin Florentine (Besu):these numbers seem like guesses
00:16:49
Ansgar Dietrichs:Replying to "to be clear with 30M..."
I don’t think that’s right? why is that right?
00:17:01
Tim Beiko:Replying to "these numbers seem l..."
They are — 30m was the block gas limit
00:17:07
Ansgar Dietrichs:Replying to "to be clear with 30M..."
we are already going down from whatever we are at right before Fusaka (say 60M) to 30M
00:17:13
Marius:I think 30m is the easiest and most uncontroversial
00:17:20
Ansgar Dietrichs:Replying to "to be clear with 30M..."
so why not go down again later?
00:17:21
Tim Beiko:Replying to "these numbers seem l..."
When the EIP was drafted
00:17:26
Marc:Replying to "to be clear with 30M…"
because raising it can’t break anything, people won’t get used to sending bigger transactions
00:17:30
Luis Pinto | Besu:The only DOS concern that make sense are if tx is above the block gas limit
00:17:43
Marc:Replying to "to be clear with 30M…"
if we find that it’s safe to allow larger txs and we need to we can always raise it
00:17:46
Ansgar Dietrichs:Replying to "I think 30m is the e..."
seems like 30M has broad support, let’s just agree and ship it
00:17:46
Ahmad Bitar | Nethermind:not all 7702 users will use bundlers. they can submit their own transactions/batches
00:18:14
Luis Pinto | Besu:For parallelisation lets discuss when that is implemented
00:18:24
lightclient:last 30 days not a useful metric due to bundling in the future
00:18:37
lightclient:the limit seems fine though, we can do 30m
00:18:46
Łukasz Rozmej:Replying to "For parallelisation ..."
and have one user whining because they implemented they solution that uses 100mgas transactions?
00:18:52
Łukasz Rozmej:Replying to "For parallelisation ..."
self destruct all over again
00:19:03
Barnabas:Lets circle back and raise it further when we have legit AA batches?
00:19:06
Łukasz Rozmej:Replying to "For parallelisation ..."
btw we have parallelization now
00:19:07
Sophia Gold:It's more important for zk proving than traditional parallelization because they can checkpoint the trace and start proving it without waiting to execute a entire block, which is CPU-bound
00:19:07
Barnabas:Sounds like a pretty easy number to bump
00:19:08
Francesco:Replying to "For parallelisation ..."
Parallelisation is implemented in besu already I thought?
00:19:13
Ansgar Dietrichs:let’s ship 30M now, and then by glamsterdam we can have precise metrics on how much of an efficiency penalty for bundled use cases a reduction would be
00:19:18
Luis Pinto | Besu:Replying to "For parallelisation ..."
It is but not full parallelisation
00:19:22
Luis Pinto | Besu:Replying to "For parallelisation ..."
Like BAL
00:19:23
Francesco:Replying to "For parallelisation ..."
still
00:19:37
yoav:In EIP-7701 (native AA) there's no notion of bundles.
00:19:37
Luis Pinto | Besu:Replying to "For parallelisation ..."
It is around 60% right now
00:19:48
yoav:Each AA transaction is a separate trandaction
00:19:50
Ameziane Hamlat:Here is an interesting use case for capping transaction gas limit , if we would to have high gas limits, more than ~105 mgas : without capping the transaction gas limit, we can create a transaction that is bigger than 10 MiB size, so there would need a way for dapps to evaluate the size of transactions in the same way as they estimate gas with eth_estimateGas before sending them.
00:20:09
Łukasz Rozmej:Cap is still there this is just formalizing it
00:20:37
Karim T.:Replying to "For parallelisation ..."
Yeah intermediate values in BAL will help to have 100% of parallelization
00:20:45
Roman:Replying to "Cap is still there t..."
exactly
00:20:50
Guillaume:SSZ-encoded block? :P
00:21:05
Karim T.:Only last values of the block will not help to increase this number we have in besu
00:22:02
Ansgar Dietrichs:capping it lower could be problematic as we start raising the gas limit
00:22:25
Justin Florentine (Besu):then we need to raise the upstream bandwidth reqs
00:22:26
Ansgar Dietrichs:Replying to "capping it lower cou..."
it should really only ever be binding for maliciously crafted blocks
00:22:34
Francesco:Replying to "capping it lower cou..."
We could always increase the cap
00:22:35
Mario Vega:CL doesn’t know because it doesn’t encode to RLP
00:24:09
Łukasz Rozmej:receipts are not a part of a block
00:24:10
Roman:Receipts are not in the block
00:24:46
Ansgar Dietrichs:can buidling not just err on the safe side? stop adding txs way under that limit, have a way to “estimate” rlp size without ever fully calculating it?
00:25:01
Ansgar Dietrichs:Replying to "can buidling not jus..."
like even if you are over cautious by a factor of 2, nbd
00:25:14
Justin Florentine (Besu):i don't see any issue building this in besu, idk about mev
00:25:25
Marc:If it turns out to be complicated for building could drop the EIP later
00:25:30
Ansgar Dietrichs:why is it pointless to make the MEV people dance a bit for us? :-)
00:25:31
Csaba Kiraly:Replying to "can buidling not jus..."
I’m sure you can make the heuristics.
00:25:59
Justin Florentine (Besu):Replying to "why is it pointless ..."
this is not a compute starved userbase
00:26:44
Justin Florentine (Besu):its an accumulator, nbd
00:26:47
Ansgar Dietrichs:you don’t need to be precise, just ensure you stay under the cap
00:27:26
Marius:Where is it verified in the engine api?
00:27:46
lightclient:if you guys have implemented and it seems good, then let’s do it
00:28:29
Kamil Chodoła:We tested it out on perfnet where we were reaching cap commonly and stopped missing slots
00:28:29
Ansgar Dietrichs:I do think getting the “where is it enforced” right is super important though, so we should be certain that the rlp encoded block is the best place
00:28:30
Marius:Replying to "if you guys have imp..."
We have the tx size in our transaction implementation already, so building should not be a big problem for us
00:28:41
Csaba Kiraly:Replying to "Where is it verified..."
Best on both sides
00:28:58
Paweł Bylica:We haven't seen the implementation yet :)
00:29:19
Roman:Can we do a cap on total size of txs instead?
00:29:23
Csaba Kiraly:Replying to "Where is it verified..."
Like passing it on to the other side if you know its wrong is stupid, but receiver side must check.
00:29:36
Ansgar Dietrichs:Replying to "I do think getting t..."
would be nice if that check would e.g. not have to be replicated in many places, so that it would be easy to modify / remove in the future
00:29:50
Justin Florentine (Besu):i think that breaks down significantly if BAL hits
00:30:03
Roman:Tx total + BAL
00:30:34
Kamil Chodoła:Replying to "We haven't seen th..."
Cap block build size in bytes by benaadams · Pull Request #8486 · NethermindEth/nethermind
00:30:56
Justin Florentine (Besu):CL should decide this, it's their limit no?
00:30:58
Ansgar Dietrichs:given that there is still uncertainty about how to do it, is the goal to resolve right now? or look into it more and make a more informed decision?
is main difference devnet-1 readiness?
00:31:41
Ansgar Dietrichs:we can already decide now that we will have some variant of this EIP that equals a rough ~10MB cap in fusaka, and ready for devnet-2
00:32:22
Marius:I would cap it to 9mb and only count the txs
00:32:52
Ahmad Bitar | Nethermind:cant receipts exceed 1 mb?
00:32:52
Ansgar Dietrichs:how many other EIPs are there?
00:33:23
lightclient:Replying to "cant receipts exceed..."
receipts aren’t in the block RLP for purposes of the EIP though right?
00:33:33
Ahmad Bitar | Nethermind:Replying to "cant receipts exceed..."
ah, right
00:33:34
lightclient:Replying to "cant receipts exceed..."
since CL doesn’t propagate receipts
00:33:40
Vectorized (Solady):i propose EIP-7939 (CLZ) a pretty easy opcode.
00:34:03
lightclient:I really think we should add 7212 and 7907
00:34:17
lightclient:Replying to "I really think we sh..."
we want to signal to devs we are listing and making things better for them
00:34:29
Ansgar Dietrichs:what exactly are we deciding? add to fusaka but not devnet-1?
00:34:46
Nicolas Consigny:We need to solve a few things with 7212 first
00:34:48
Justin Florentine (Besu):Replying to "I really think we sh..."
strong opinion on which particular devnet?
00:34:55
Ansgar Dietrichs:Replying to "We need to solve a f..."
does this have a champion?
00:34:55
Nicolas Consigny:The current specification of RIP-7212 compares the x coordinate with the signature r value directly (as integers, presumably), which may return false when the standard result should be true
00:35:00
Ansgar Dietrichs:Replying to "We need to solve a f..."
seems like zero progress in a year
00:35:25
stokes:Replying to "The current specific..."
Can we just write an EIP-7212 that fixes this?
00:35:25
Marius:No strong feelings for any of these from me
00:35:33
lightclient:Replying to "I really think we sh..."
depends on how much there is for devnet 1
00:35:50
lightclient:Replying to "I really think we sh..."
i think we are targeting devnet 1 for berlin
00:36:16
Nicolas Consigny:Replying to "The current specific..."
Hmmm yes kind of but then we would have some conflict with existing 7212 on rollups 🤷
00:36:21
Nicolas Consigny:Replying to "The current specific..."
So I would say yes
00:36:25
Nicolas Consigny:Replying to "The current specific..."
if they fork out
00:37:27
Barnabas:Replying to "I really think we sh..."
yes devnet 1 is targeting to launch on monday 9th of June
00:38:20
Ansgar Dietrichs:@Tim Beiko which 4 did you mention just now? I see 5 open EIPs on the CFI list, which one was the one out?
00:38:27
CPerezz:Replying to "I really think we sh..."
REG: r1 support. We have some L2s supporting it which will like to be “Based”/“Native”.
If L1 doesn’t have the precompile they won’t be able to.
Also, r1 is mostly interesting for keystone interactions no?
(Not that ‘m in favor or against though).
00:38:46
Ansgar Dietrichs:Replying to "@Tim Beiko which 4 d..."
(already ignoring EIP-7762 in favor of EIP-7918 in that count)
00:39:09
Tim Beiko:Replying to "@Tim Beiko which 4 d..."
EIP-5920: PAY opcode
RIP-7212: Precompile for secp256r1 Curve Support
EIP-7907: Meter Contract Code Size And Increase Limit
EIP-7918: Blob base fee bounded by execution cost
00:39:30
Ansgar Dietrichs:if there are concerns, can we push this to devnet-2 and make sure we have confidence in 2 weeks?
00:39:56
Łukasz Rozmej:any bottleneck on jumpdest analysis?
00:40:16
lightclient:jumpiest analysis has been shown to be linear cost per code size
00:41:03
Łukasz Rozmej:do clients persist jumpdest analysis or do it always on the fly?
00:41:16
lightclient:https://github.com/charles-cooper/eip-3860-benchmarks/blob/master/benchmark_results/summary_report.md
00:41:16
Marius:Replying to "do clients persist j..."
We compute it on the fly
00:41:28
lightclient:^ jumpdest analysis limit
00:41:28
Nicolas Consigny:Replying to "The current specific..."
RIP-7212’s verifier should reduce the affine x-coordinate of the reconstructed point modulo n before it is compared with r, and it must explicitly reject the point-at-infinity.
Without these two rules different EVM chains can accept or reject exactly the same P-256 Schnorr signature, because an attacker can pick a nonce whose x-coordinate lies in [n, p) or that reconstructs to ∞
00:41:31
Sophia Gold:If you're concerned about the effect of code size, we should add the new SWAPs and DUPs in glamsterdam
00:41:33
Łukasz Rozmej:Replying to "do clients persist j..."
we to, I consider saving it with the code directly
00:41:35
Barnabas:Replying to "I really think we sh..."
how much impl are these eips require?
00:41:43
Ansgar Dietrichs:Replying to "@Tim Beiko which 4 d..."
that seems to only leave
EIP-7917: Deterministic proposer lookahead
Is the idea to reject this for Fusaka today, or make a decision for devnet-2 later?
00:42:07
Nicolas Consigny:Replying to "The current specific..."
Can probably fix
00:42:10
stokes:Replying to "@Tim Beiko which 4 d..."
7917 is more of a CL call
00:42:25
Ansgar Dietrichs:Replying to "@Tim Beiko which 4 d..."
aah, I realized that just as you wrote that. never mind then
00:42:56
CPerezz:Replying to "I really think we sh..."
r1 is just a copy-paste of k1 impls right? So should not be crazy. Just changing a few constants and not much more work.
00:43:12
stokes:Replying to "I really think we sh..."
My understanding is that impl is quite low
00:43:22
stokes:Replying to "I really think we sh..."
Many langs have a library that is more or less 1:1 to EIP ready
00:43:29
stokes:Replying to "I really think we sh..."
And much smaller surface area than say 2537
00:43:44
Ansgar Dietrichs:context: that RIP is already live on some L2s
00:44:11
CPerezz:Replying to "I really think we sh..."
I still think the most important part is considering the Based/Native rollup idea.
As if we don’t support this, they’ll need to remove it if they want to be based/native.
00:44:25
Ansgar Dietrichs:7212 seems to really urgently need a champion then if it still wants to have a shot for Fusaka
00:44:31
CPerezz:Replying to "I really think we sh..."
Unsure how clear this is. But can be a concern if this whole concept moves forward
00:44:50
Ansgar Dietrichs:Replying to "7212 seems to really..."
needing changes and being flagged as significant testing overhead
00:44:55
CPerezz:Replying to "7212 seems to really..."
Antonio is an expert on championing EC precompile additions ^^
00:45:11
Justin Florentine (Besu):7212 is not an eng challenge, it's a research one
00:45:21
Barnabas:Replying to "7212 seems to really..."
Its a huge UX + , I think we should include it in fusaka.
00:45:26
stokes:Replying to "7212 is not an eng c..."
What is there to research?
00:45:28
CPerezz:Replying to "7212 seems to really..."
Agree
00:45:35
Hadrien Croubois (OpenZeppelin):Replying to "7212 seems to really…"
What does it take to be a champion ? I don’t like the current format of the RIP, but I think it’s better than nothing
00:45:53
Justin Florentine (Besu):Replying to "7212 is not an eng c..."
safety, just need a signoff that it's good to go.
00:46:10
Barnabas:what changes need to be made to make it viable by devnet 2?
00:46:34
stokes:@Nicolas Consigny im interested in helping, will dm
00:46:48
Tim Beiko:Strong +1 on not having different code at the same address
00:46:57
CPerezz:Replying to "7212 is not an eng c..."
R1 is in safe curves already no? https://safecurves.cr.yp.to/
00:47:33
Marius:@Mario Vega updated our fusaka branch for 7823
00:47:43
Ansgar Dietrichs:sounds more like internet issues
00:48:23
Barnabas:we shouldn’t roll out a feature that has a known bug lmao
00:48:38
Barnabas:just because we don’t want compilers to target diff address based on chainid
00:48:39
stokes:Replying to "we shouldn’t roll ou..."
We would deploy the right thing to l1
00:48:51
Vectorized (Solady):agree with Hadrien. the point of making the precompile is so that existing code that use 7212’s 0x100 address will simply get speed up. if it’s on a different address, it’s pretty much pointless imo.
00:49:55
Barnabas:how much time would the modified version of this EIP take to get security audited tho? Would it delay shipping peerdas?
00:50:36
Nicolas Consigny:Replying to "how much time would ..."
Less than 3 month imo
00:51:05
Tim Beiko:https://eips.ethereum.org/EIPS/eip-7918
00:51:14
Nicolas Consigny:Replying to "how much time would ..."
If you meant 7212 😅
00:51:24
Roman:Agree with @lightclient , idt it’s a prio / smth we wanna rush
00:51:26
CPerezz:Replying to "how much time would ..."
It’s a NIST curve. So there’s formal specs and lots of references.
Also it’s a clone of k1 mostly but changing constants.
So should be quite easy to both implement and audit.
00:51:41
Barnabas:Replying to "Agree with @lightcli..."
shove it to Glamsterdam?
00:51:49
lightclient:sgtm
00:51:49
Roman:Replying to "Agree with @lightcli..."
What’s after?
00:52:03
Barnabas:Replying to "Agree with @lightcli..."
something Bogota
00:52:06
lightclient:how can zero be underpriced?
00:52:12
Roman:Replying to "Agree with @lightcli..."
smth bogota sg
00:52:22
terence:I thought this has been brought up to a RollUp call last November and L2s in presence all seemed ok with it, we didnt include it because of testing delay
00:52:26
Anders Elowsson:On EIP-7918. There has been this recent analysis: https://notes.ethereum.org/@anderselowsson/EIP-7918E
It essentially just expands the rationale, but would could then warrant another constant selection.
00:52:30
Łukasz Rozmej:Replying to "how can zero be unde..."
infinitely
00:52:33
stokes:I call it hogota
00:52:33
Ben Adams:Replying to "how can zero be unde..."
every number is over; so its under
00:52:41
stokes:Replying to "Agree with @lightcli..."
H-star + bogota
00:53:00
Justin Florentine (Besu):Replying to "Agree with @lightcli..."
BogotHa
00:53:15
Barnabas:Replying to "Agree with @lightcli..."
Hydra + Bogota?
00:53:29
Francesco:Replying to "Agree with @lightcli..."
Hog
00:53:59
Tim Beiko:So right now we have
Devnet-0:
EIP-7594: PeerDAS - Peer Data Availability Sampling
EIP-7823: Set upper bounds for MODEXP
EIP-7883: ModExp Gas Cost Increase
EIP-7892: Blob Parameter Only Hardforks
Devnet-1:
EIP-7825: Transaction Gas Limit Cap
EIP-7918: Blob base fee bounded by execution cost
CFI — maybe for devnet-2:
RIP-7212: Precompile for secp256r1 Curve Support
EIP-7907: Meter Contract Code Size And Increase Limit
EIP-7934: RLP Execution BlockSize Limit
EIP-5920: PAY opcode
DFI
EIP-7762: Increase MIN_BASE_FEE_PER_BLOB_GAS
00:54:01
Tim Beiko:Still TBD
EIP-7917: Deterministic proposer lookahead
00:54:03
CPerezz:Replying to "Agree with @lightcli..."
I think this is an example of something we can definitely speed up a bit in ACD.
It has no blockers nor anything and it’s quite similar to k1.
Can’t we ship for Fusaka or Glamsterdam at worst?
Why don’t we see this landing in Fusaka? What’s the exact blocker?
00:54:05
Ansgar Dietrichs:but to be clear, all of that EIP-7918 complexity is just on the rationale side, so no issues for implementation
00:54:17
Trent:EL naming sequence with 2/yr
'25 H1/H2 : Prague/Osaka
'26 H1/H2 : Amsterdam/Bogota
'27 H1/H2 : Istanbul/Bangkok
'28 H1/H2 : Buenos Aires/'26 city
'29 H1/H2 : '27 city/'28 city
'30 H1/H2 : '29 city/'30 event
https://x.com/trent_vanepps/status/1923069488880091406
00:54:50
Marc:Replying to "but to be clear, all…"
from implementing this and the other min blob base fee proposal, this one was actually much simper
00:55:14
Ahmad Bitar | Nethermind:why is there always fear from making L2 pay a bit for blobs? blobs are the most underpriced compute that Ethereum is providing while being the most valuable resource for L2s
00:55:16
Trent:Replying to "but to be clear, all..."
Interesting, wouldn’t have guessed that!
00:55:16
Ansgar Dietrichs:why not devnet-1?
00:55:21
Ansgar Dietrichs:Replying to "why not devnet-1?"
if it’s ready
00:55:41
Ansgar Dietrichs:Replying to "why not devnet-1?"
wait who wants to move it to a different fork? I think that’s not an option
00:55:43
Ansgar Dietrichs:Replying to "why not devnet-1?"
we need this for fusaka
00:55:54
Trent:Replying to "why is there always ..."
Are there other people with this view besides light client?
00:55:56
lightclient:Replying to "why is there always ..."
i mean the fear is we push L2s away from ethereum
00:55:57
Mario Vega:Which EIP?
00:56:03
Tim Beiko:Replying to "Which EIP?"
7918
00:56:16
stokes:Do we know how much 7918 would raise fees?
00:56:23
stokes:I feel like that would help ground the convo
00:56:25
Marc:Replying to "why not devnet-1?"
could do devnet-2 to have a bit longer to finalise spec details
00:56:48
Nicolas Consigny:Replying to "how can zero be unde..."
Ask the Move language based apps 🥲
00:56:52
terence:Replying to "why is there always ..."
This is good for L2, they actually want this EIP
00:56:57
Ansgar Dietrichs:if we need one more round of “should we even ship this in Fusaka at all”, we should do that now. we won’t have any new info in 2 weeks
00:57:04
Trent:Replying to "how can zero be unde..."
Too niche Nico lol
00:57:22
Trent:Replying to "why is there always ..."
I think this is worth surfacing terence!
00:58:04
Tim Beiko:Replying to "why is there always ..."
Yes @terence can you expand on it on the call?
00:58:27
Ahmad Bitar | Nethermind:if we dont raise the base fee, L2s then need to pay extra priority fee to the builders to compete with other L2s on inclusion. Builders dont really want to include a lot of blobs
01:00:16
lightclient:won’t the curve become more smooth when demand levels out in line with supply?
01:00:21
Francesco:One way to think about this is there’s two separate goals:
Solve the ramp-up problem by keeping the blob fee always at least in the ballpark of the execution fee
Charge blobs something that’s more related to the actual compute cost
We can solve 1. regardless, and then depending on the parameter setting we might go more or less towards 2. (e.g. we can decide to still keep blob-related computation more or less underpriced)
01:01:00
Anders Elowsson:Replying to "One way to think abo..."
Right so that is the great thing by shipping EIP-7918 and starting at a lower range
01:01:06
stokes:Replying to "One way to think abo..."
Doesn’t “keep blob fee in ballpark of execution fee” imply raising the blob fee substantially?
01:01:29
Francesco:Replying to "One way to think abo..."
Ballpark could mean 1/10, 1/100, not necessarily even the same order of magnitude
01:01:29
Ben Adams:Replying to "One way to think abo..."
Only when no blobs are being posted
01:01:44
Anders Elowsson:Replying to "One way to think abo..."
It would be at 10% as per recent discussion
01:01:48
stokes:Replying to "One way to think abo..."
Ok then I think im on board
01:02:31
Francesco:Replying to "One way to think abo..."
Then there’s a separate strategic discussion around actually charging “the fair price” for computation, but we don’t need to do that for the EIP to be useful
01:02:43
stokes:summary: makes fee more predictable and we can agree later on the exact fee level
So this sounds good
01:02:46
Ansgar Dietrichs:how to think about this EIP in general:
The “effective control floor” for the blob basefee varies when the normal gas basefee goes up and down.
If gas on mainnet is cheap, already a relatively cheap blob basefee allows for price discovery. But if the mainnet gas is high, the blob basefee floor also needs to be a bit higher, otherwise the normal gas cost of a blob tx just completely dominates the total cost
01:03:44
Justin Florentine (Besu):to me this falls in the category of servicing app devs
01:04:23
Vectorized (Solady):imo, its not adding new functionality.
01:04:24
Roman:It would break current men boost flow
01:05:13
Marc:Nethermind would support in devnet 1 or 2
01:05:43
Vectorized (Solady):i propose replacing PAY with CLZ.
01:05:43
lightclient:why not remove? if we’re going to do 6 months forks lets just revisit later
01:06:13
Marius:Replying to "i propose replacing ..."
Very similar features tbh
01:06:15
Luis Pinto | Besu:Replying to "i propose replacing ..."
Why not both?
01:06:28
Vectorized (Solady):Replying to "i propose replacing …"
if we are ambitious, both is good
01:06:33
Justin Florentine (Besu):i'd like to hear stronger case for not breaking mev with PAY, i don't understand it enough to sympathize yet
01:06:45
Barnabas:so only 2 eip for devnet 1 ?
01:06:54
Barnabas:are we gonna let the devs slack off?
01:07:09
lightclient:Replying to "are we gonna let the..."
we have so many eips to review though ;)
01:07:09
stokes:Replying to "are we gonna let the..."
Lets not bite off more than we can chew
01:07:23
Tim Beiko:https://ethereum-magicians.org/t/methodology-for-ethereum-testnet-networks/23164
01:08:28
Sophia Gold:I thought Sepolia was for app devs?
01:08:35
Barnabas:we had holesky as the last devnet to fork 😂
01:08:48
lightclient:Replying to "I thought Sepolia wa..."
we realized that some apps need to use staking features
01:08:59
nixo:alon is here now
01:09:01
Alon Muroch | SSVLabs:Hi everyone!
01:09:04
Marius:Should be community driven imo
01:09:27
Parithosh Jayanthi:Replying to "Should be community ..."
Didn’t work out so well when it was tried with holesky originally
01:09:29
Barnabas:I think the idea is to have devnet - x forks then sepolia/hoodi/mainnet
01:09:56
Marius:Replying to "Should be community ..."
Welll...
01:10:12
Marius:Replying to "Should be community ..."
That was maybe because of the team behind it
01:10:21
Justin Florentine (Besu):eternal mainnet shadow fork?
01:11:15
Barnabas:I don’t think we should have a “forever running testnet”
01:11:37
lightclient:i think we just rushed the deployment of pectra
01:11:54
Barnabas:Dev teams should have automated tools to deploy their stuff on testnets, if we have a very long running very stable testnet, then their tooling will get old, and become untested.
01:12:05
lightclient:Replying to "i think we just rush..."
we still need to test on the testnets, we just need to be more confident that we won’t break them
01:12:13
Marius:Replying to "I don’t think we sho..."
I don't care, as long as its community driven and we don't need to do anything for it. Means apps using it should also run the nodes etc
01:12:18
Roman:We didn’t intentionally break holesky, promise
01:12:20
Marc:we could fork hoodi last and still have a bit of a gap to observe before mainnet
01:12:59
Hadrien Croubois (OpenZeppelin):Would state expiry make such a testnet viable ?
01:13:08
lightclient:Replying to "Would state expiry m..."
it would help a lot
01:13:11
Tim Beiko:Replying to "Would state expiry m..."
I think that would solve most issues
01:13:14
lightclient:Replying to "Would state expiry m..."
but we still have some issues with eth supply
01:13:27
Barnabas:The community can launch a long running testnet if they want. But I don’t think we should do that.
01:14:28
lightclient:holesky is designed to last 6 years, is that not enough?
01:14:53
Barnabas:Replying to "holesky is designed ..."
was designed **
01:15:00
lightclient:Replying to "holesky is designed ..."
yeah that is a different issue
01:15:04
stokes:Replying to "holesky is designed ..."
Yeah aren’t we dropping in a few months
01:15:31
lightclient:we’ve only had 1 bug like this in modern history on testnets
01:18:42
Francesco:After mainnet would be very weird 😄We’d rather anything but mainnet breaks first
01:19:17
Barnabas:I’m really against running anything over 6years.
01:19:24
Barnabas:even 3yrs is too much imho.
01:19:29
lightclient:Replying to "After mainnet would ..."
this ^^^^
01:20:00
Csaba Kiraly:Agree. The right question is: if one fails, which one your would choose? Obviously best if none, but if something is slipping through, I would prefer catching it on the one where apps are only tested.
01:20:07
lightclient:i think we’re over indexing on the bug on holesky
01:20:47
lightclient:i think pectra was a mess and we were rushing to get the testnets launched when we should have relaxed a little more
01:21:25
Barnabas:Replying to "i think pectra was a..."
I still think it was good idea to launch hoodi tbh
01:21:36
lightclient:Replying to "i think pectra was a..."
as opposed to?
01:22:47
Vectorized (Solady):Base Sepolia is now our preferred testnet ;)
01:23:08
Justin Florentine (Besu):app devs unite and re-use panda tech to shadow fork mainnet?
01:24:22
Marius:Hahaha rope in devs with a great testnet experience, dissapoint them on mainnet
01:25:23
Barnabas:You should push those applications to deploy on testnets
01:25:38
Barnabas:They should practice deploying on kurtosis
01:25:54
lightclient:can we talk about the RPC proposals?
01:26:16
Parithosh Jayanthi:Yeah we can work on pushing more people to deploy on hoodi
01:26:29
Justin Florentine (Besu):RPC call next monday if not
01:26:34
Alon Muroch | SSVLabs:Thank you everyone!
01:26:40
Tim Beiko:https://github.com/ethereum/execution-apis/issues/658
01:27:12
Barnabas:I think its time to just yeet JSON-RPC altogether.
Lets just do REST.
01:27:25
Marius:Rpc error codes, what a great idea :D
01:27:47
Zane Starr:👋 Hey Zane here from Open-RPC helping with error standardization in conjunction
Execution-APIs issue:
https://github.com/ethereum/execution-apis/issues/658
Standardized Code Proposal:
https://github.com/user-attachments/files/20363196/ENG-ERC_.Standardized.JSON-RPC.Error.Codes.and.Messages-210525-082426.pdf
PR for execution Apis:
https://github.com/ethereum/execution-apis/pull/653
PR for rpctestgen:
https://github.com/lightclient/rpctestgen/pull/42
OpenRPC
https://open-rpc.org
OpenRPC Error groups Extension
https://github.com/open-rpc/tools/tree/main/packages/extensions/src/x-error-groups
OpenRPC - New Repo
https://github.com/open-rpc/tools
OpenRPC- Generator
https://github.com/open-rpc/generator
01:27:50
Barnabas:Replying to "I think its time to ..."
maybe something for glamsterdam?
01:27:53
Luis Pinto | Besu:Why do we have a standard around error codes AND messages?
01:28:14
Tim Beiko:What’s the best place to discuss this async, given we’re out of time?
01:28:28
Justin Florentine (Besu):rpc channel in discord
01:28:40
Barnabas:#json-rpc-api
01:28:44
Maintainer.eth:Thank you all, GM!
01:28:48
Luis Pinto | Besu:Replying to "Why do we have a sta..."
It feels like clients can already work with error codes but maybe I’m missing something
01:29:52
Justin Florentine (Besu):sorry, not ythoclock its on the calendar, and eth/pm repo
01:30:10
Tim Beiko:https://eips.ethereum.org/EIPS/eip-7939
01:30:15
Tim Beiko:https://github.com/ethereum/EIPs/pull/9792