Tim Beiko:Okay, thanks. Everyone. Welcome to acde number 2, 1, 5, have a couple of things on the agenda today. So a bunch of
Transcript
Tim Beiko:Fusaka scope finalizations questions to go through specifically around 7, 9 0, 7 the Max Blob for transactions. And then the MoD exp pre compile re pricing
Tim Beiko:Once we get to that, I wanted to chat a bit about the Amsterdam. So specifically, we have these headliners that have been proposed. We were hoping to finalize that in 2 weeks. But given, we have not yet finalized the few psychoscope that feels unrealistic. So yeah, we should probably revise that. And then finally,
Tim Beiko:Finally, Matt had a couple of things around the history expiry that he wanted to get feedback from teams on
Tim Beiko:but I guess to kick us off. Does Perry or Barnabas want to give us an update on Devnet 2. And how things are going there.
Barnabas:Yeah, sure so definitely not looking too great. We have on finalization for about 3 days now.
Barnabas:we had a bunch of peering issues. And
Barnabas:some fork id issues bezel had a forecast, had had some peering issue.
Barnabas:Nimbus and Nimbus El. Both are having issues. They are unable to sync,
Barnabas:we are about 56% right now. And yes, it's not looking too great
Barnabas:and tech. We also had some issues, and in the beginning be before we even hit Hulu, during full transition prison, had a bug as well.
Tim Beiko:Okay, do any of the client teams want to chime in about the issues they've encountered and
Tim Beiko:what the next steps are.
Tim Beiko:Yeah, Roman.
Roman:Yeah. We added some more logs to see what the parent issues are. Exactly. And the it seems to be work. Id related as well we we should fix it by the end of the day.
Tim Beiko:Okay, what did anything change in the fork? Id
Roman:It. It is more likely that we're
Roman:we're not initially treating videos as regular hard works.
Tim Beiko:Oh, okay. I see that. Okay.
Roman:Most likely. Video related.
Tim Beiko:I see it.
Tim Beiko:And Gabriel, when you say Basic was not calculating the forecast correctly. Is that also the the source.
Gabriel Trintinalia | Besu:Yeah. Exactly the same thing.
Tim Beiko:Okay, got it?
Tim Beiko:I know that. When we run into this issue or on the test nets for Petra, we said we would create some test suites to actually test these like static configs for clients. I don't know if we ever did it.
Tim Beiko:yeah, I think Daniel or and or Mario, we're working on this. I don't know if either of them has
Tim Beiko:context on it, but it it does seem like
Tim Beiko:this is also hitting us. Now, we should probably figure out a way to test it. Especially in the context of Vpos
Tim Beiko:easy.
Tim Beiko:Yeah. So I don't. Maybe.
Mario Vega:The in the East Repository. We can okay, work something out. Yeah.
Tim Beiko:Yeah, we yeah. And we can discuss this, I think, around the call Monday. But it does feel like,
Carson | STEEL (EELS):If this.
Tim Beiko:Oh, yeah, it does like, if you have a growing number of just parameters that clients need to align on in Genesis, we should have a way to just test that side. Oh, and yeah, thanks, Spencer.
Tim Beiko:yeah. Oh, I'm I'm not sure that
Tim Beiko:the thing you, link Spencer was the actual
Tim Beiko:was Diana's proposal. I I think he wanted to like extend this or something.
Tim Beiko:but yeah, can follow up Async about this.
Tim Beiko:Any other issue people wanted to discuss.
Tim Beiko:Oh, yes, okay. Sorry. That second link that Gabriel shared is what Daniel's proposal was. So I don't know if this would actually support Bpo's if not, we should probably extend it and
Tim Beiko:make sure we have some tests around this.
Barnabas:Is this something you could actually ask for next? Would it be hard to as another vip.
Barnabas:because this is just a Json Rp. Sequel, so it should be fairly easy to add.
Tim Beiko:Has have any clients actually implemented this.
Felix (geth):So we have nothing yet.
Tim Beiko:Do you have a sense of how
Tim Beiko:big of a lift it is to implement like.
Felix (geth):So one thing about this proposal for sure is that it requires basically a custom implementation of this method. So it's not something that just falls out of the genesis, for example. So we do have to write.
Felix (geth):okay.
Felix (geth):But there's we can. Yeah.
Tim Beiko:Yeah.
Tim Beiko:Yeah. And there's a Pr for base 2. Yeah. Oh, sorry. Some.
Barnabas:I I would really want this to be included. To be honest. And because we need to verify if the config is correct, and I just don't understand how this was not
Barnabas:there yet before.
Barnabas:Yeah. So I think all, all clients should use the same format. That would be very nice.
Tim Beiko:Yeah, like, all the clients will probably have to implement it a bit differently. But exposing.
Tim Beiko:yeah, like, yeah, exposing the the call in the same format would be really helpful.
Tim Beiko:I guess I maybe one thing that could be helpful is if teams have time before Monday's testing calls to get like a a rough sense of what the implementation lift would be.
Tim Beiko:We can make a call then about having it be a prerequisite for definite 3. Does that make sense?
Tim Beiko:And I think, okay, if if we chat about it as well on Monday,
Tim Beiko:the other thing that we should probably consider is, is there some version of this for the cl clients? Because, if the El clients are running into issue issues, then
Tim Beiko:yeah, we? We probably want to wait for cl clients to also make sure they're like
Tim Beiko:set up with the same configs. But that might be a bigger lift.
Barnabas:Yes, here's already have this Api exposed beginning. Api.
Tim Beiko:Okay, amazing.
Tim Beiko:Okay? Then, yeah, it feels like we, we should definitely
Tim Beiko:should definitely do it on the El
Tim Beiko:And yeah, like, I guess, to Lucas's comment, like, it's not like a consensus change. So it's not like something we would add to definite, free formally. But I think it's maybe something we can just date
Tim Beiko:like we agreed to like not launch Devnet 3 until we have this.
Tim Beiko:But yeah, I I
Tim Beiko:I think we should give teams like maybe a couple of days to look into this and and finalize that decision on Monday. Does that make sense?
Tim Beiko:Okay, let's do that
Tim Beiko:any other. Yeah. Test. Definite issue. Sorry that people feel we should bring up here and discuss.
Tim Beiko:Okay.
Tim Beiko:then, next up we need to make a call around the Eip. 7, 9 0, 7 so there was a pretty big thread about this this week. I mean, it's been going for many weeks. But
Tim Beiko:yeah, I I don't know if
Tim Beiko:drag on, you want to give a context on your latest proposed change or
Tim Beiko:yeah, life science, either of you. Wanna give us some money.
draganrakita:Sure I can do it.
draganrakita:After interrupt. We have discussion, but changes need to be made on 7, 9, 0 7, and likely made Pr, that reduces code size to basically doubling it, whereas it was 10 times it introduced slightly more gas fee from
draganrakita:2 per board to 4 per board.
draganrakita:And the last thing was it basically introduced the case with the xt code size.
draganrakita:I think all clients are fine, was fine. With that change. Yesterday we had discussion how to implement the warming of the code size in the end. I think all clients are fine to remove it
draganrakita:for that thing to be permutation detail.
draganrakita:In general.
draganrakita:There are 3 Prs that needs to be merged. One is clarification of light, like client Pr, the patch that removes code, size load warming, and the last one is most clarification from Mario is to include the loading of the initial targeted by code when it is hit by transaction.
draganrakita:This was not where indefinite. 2. This this was not done.
Tim Beiko:Thank you.
Tim Beiko:Mike signed anything to add on that, or
Tim Beiko:it's okay. If not, then I guess there's yeah. 2 questions the 1st is.
Tim Beiko:are all the teams okay with the 3 Prs that Gabriel from basically posted in chat. So this, pr, 9, 9, 1 0. Then the addition that dragon made to it and then Mario's pr around large contracts. So if we went forward with this.
Tim Beiko:does anyone oppose, merging these 3 prs, and then having that be the final spec.
Tim Beiko:And then the second question is, should we make the code size, index, optional or mandatory.
Tim Beiko:I think optional was where
Tim Beiko:soft consensus was last time I I checked. But yeah, we should definitely get explicit agreement on this.
draganrakita:A Pr assumes that code size index is optional or basically implementation detail.
Tim Beiko:Right? Oh, yeah, yeah. And so, yeah, by, I guess by optional like.
Tim Beiko:not not in consensus, like, I think there's no design where we are actually making this like a
Tim Beiko:like a a part of the consensus. But
Tim Beiko:When we say the implementation detail, it's like
Tim Beiko:we still expect all of the teams to have something or so.
Allan | Offchain Labs:Yes.
Allan | Offchain Labs:help catch me up. On the rationale for reducing the contract code size limit to 48 kb. Representing arbitrum and also catching up on all the different threads, so I'm sorry if I missed it.
draganrakita:I think it's mostly to side with caution.
draganrakita:10 times increasing. The contract size seems too much, and with this aip
draganrakita:we are doubling it and preparing the work for further increase in the future. Hard folks
draganrakita:in future, hard Fork. We could just change the constant, and in the end we will have the bigger, bigger
draganrakita:contracts.
Allan | Offchain Labs:That's helpful. Thanks. So there's a path to scaling over time. But we want to start slow. I mean, doubling is not necessarily slow, but we very much would prefer the the full 256 kb, but understand that that's maybe not the safest, most scalable thing to do today, but very much in favor of it being included for socket, even at the 48 kb. Limit.
Tim Beiko:And I guess maybe just a bit of a sidetrack. But on this question, like.
Tim Beiko:Do you have a sense of the
Tim Beiko:distribution of usefulness like you know how many. When you say you want the 256 like, I assume this means, maybe I don't. Arbitrum can run everything in like a single contract. But then, like, yeah, what benefit do you get from? Like, you know? 48 versus, you know. Say, we doubled it to get the 96 like, are there some?
Tim Beiko:Some yeah, some some numbers, or some like sizes that are just like disproportionately useful.
Allan | Offchain Labs:Yeah. So so one of the big benefits to us is, that a lot of the the rest and C and C plus plus binaries that we run with stylus or the laws mentioned is just naturally larger. So we we would like to.
Allan | Offchain Labs:you know, add, you know.
Allan | Offchain Labs:certain crates that can blow past 24 kb, once they're optimized. So it would be ideal for us to be able to import more crates like that that, you know. Aren't, you know? Just hand rolled maths. There's also yeah. Other rest elements for the rest contracts on the arbitr stack that we would be able to move
Allan | Offchain Labs:on chain more and have a lot of performance benefits, too. So we're we're sort of capped right now. On how much of that we can
Allan | Offchain Labs:deploy on chain without having to, you know, spread it out or scattered across many contracts.
Tim Beiko:Got it.
Tim Beiko:Okay, I'm okay. So I guess I yeah, back to the
Tim Beiko:actual spec changes. So like, I think.
Tim Beiko:it seems like there's no objections on those 3 Prs. Then the question is, about the index. If we do leave it as an implementation detail to clients. As Oscar said.
Tim Beiko:we, we want to have we want to make sure we're not introducing new bottlenecks or or new issues. Even in the case where the gas limit increases. We haven't quite benchmarked this extensively.
Tim Beiko:but yes, Lucas, and seem to have an intuition, for, like what kind of bottlenecks would this cause. And
Tim Beiko:yeah, do you wanna maybe give more context on this.
draganrakita:Maybe I can respond. We will still have additional gas that if the bytecode gets code loaded
draganrakita:you will still have that initial gas that you need to spend
draganrakita:the while we why, we say the code size in this is optional is because this will not apply for the external code size
draganrakita:for external code size.
draganrakita:The bytecode is not going to be made warm.
draganrakita:It will be always cold. It will be cold after the call. That means that if the bycode is not warm somehow from other opcodes.
draganrakita:you will still have need. You still need to account for additional gas.
draganrakita:So worst case in this sense is covered.
Tim Beiko:Okay.
Tim Beiko:any other thoughts on this. Otherwise I would lean towards including it in Devnet 3. With these changes, I think. We will benefit from actually getting clients to try and implement this. We can also run, you know, large blocks and spammers on definite 3 or the definite. 3.
Tim Beiko:Version,
Tim Beiko:so, and to on, guys point like by optional, I guess we would leave it at the clients how they implement it. But then we should actually test these implementations and like.
Tim Beiko:large scale devnets. Yeah, I'm sorry.
Ansgar Dietrichs:Yeah, I mean to be clear. I didn't mean we should like. I don't think there's an option where at least not for Fusaka, where we would have an enshrined index in any sense meaning like an actual like state object that would be had a specified structure, and would be committed to or anything, because that's just too big of a lift. So the question really is, just, do we want to mandate that all clients have a version of a kind of
Ansgar Dietrichs:of a way to to always get the the contract size that is never worse than, say, loading a 24 kB contract?
Ansgar Dietrichs:Or do we basically even leave that choice up to the clients? Because that, I think, impacts quite heavily what what kinds of things we like performance? We're testing and and whatnot. So so I just I was really most asking for that decision. Like, do we do we? Do? We make it mandatory that there is some way of efficiently accessing code size or not.
Tim Beiko:Lucas.
Łukasz Rozmej:So, in my opinion, this is the other way around. We should firstly create some worst case scenarios, benchmark and target some kind of performance, and then see if a client can live without those index, the ones that don't have it, and if they don't, they need to implement it.
Tim Beiko:Yeah. So I guess that would be making it optional.
Ansgar Dietrichs:Right. But then maybe just one more point there, like I I do think then just the the point would be that normally all of. I agree with that process. But all of that would have to happen before I final inclusion decision into the hard phone. Because
Ansgar Dietrichs:basically, first, st you get some benchmarks. And then you decide, okay, do you need to have a man index or not to basically then hit the performance targets, but only once you hit the performance targets. Can you make the inclusion decision? We want to make the inclusion decision today. So that means we have to basically already be at basically 100% confidence that we will hit the benchmark requirements that we will eventually have. And the problems right now, we just don't have the data for that yet.
Ansgar Dietrichs:if we are also optimistic that we that we are very confident that we will hit them, we can do that, and then just worst case pull the eap, but it just feels very opinionated.
Łukasz Rozmej:Yes, that was my initial reservation against the Ap. And that we don't have any benchmarks for it, and that's why we were not happy with the next thing, the target with 2 xing. We are pretty sure we will hit
Łukasz Rozmej:decent numbers.
Tim Beiko:I would treat this like, basically any other dos vector in a way like we should, we should include it. And then, if we find in testing that there's like a dos issue or like a performance issue, then we can always remove it. But that's
Tim Beiko:that's true of every IP. And I think at this point, like the main thing we're bottlenecked on is
Tim Beiko:actually getting the clients to implement it and and seeing how that works. So like, if we want any chance of shipping this into Saka.
Tim Beiko:I I think we we basically have to include it. Leave the index optional.
Tim Beiko:and then, yeah, make a call based on the performance numbers and worst case, we will remove it if we if we don't feel that we we can actually
Tim Beiko:like, yeah, address those issues,
draganrakita:Just say we added new gas to mitigate that potential Ddos.
draganrakita:So.
Tim Beiko:Great.
draganrakita:Yeah, it's there.
Tim Beiko:Okay, and then when we'll need to see these new benchmarks.
Tim Beiko:I think once we have Devnet 3 up and running, and it works. In the happy case, then our priority should be to actually
Tim Beiko:do the stress testing. If we can do it in parallel, then great. But it does seem like
Tim Beiko:Devnet 2 is still struggling with some issues. So we we 1st need to get it implemented. Get it, live on Devnet 3, and then we should stress. Test it shortly after.
Tim Beiko:And okay, so
Tim Beiko:any objection to move forward with 7, 9 0, 7 indefinite 3. It's already specified, I believe, since the since the last call.
Tim Beiko:let me just actually double check that real quick, but
Tim Beiko:almost certain. Yeah. So it was specified on the last call. So I would just add it to definite 3 and flag that we are merging the 3 the 3 prs that that were at the agenda. So
Tim Beiko:that will be the final spec.
Tim Beiko:Yeah, Millen.
milen | Erigon:Yeah, hey? I just have a quick question. Every everything so far sounds good to me. But I was just wondering, do you guys think that there would be a definite 4 and a definite 5?
milen | Erigon:And if there is, I'm wondering.
milen | Erigon:and if we're gonna do all these performance tests and benchmarking. I'm wondering if it's worth
milen | Erigon:leaving the 256 kB
milen | Erigon:unchanged for Devnet 3, so that we can gather.
Tim Beiko:Right I would lean against.
Tim Beiko:I think we should do. 48. And we tried to have definite 3. Be the last def net, and to the extent, there's a definite 4. It's because there's a bug on definite 3 that requires like restarting the definite. But I think we should consider this like the final
Tim Beiko:final spec, and given the concerns around benchmarking and whatnot, I think. I think we do. 48 now and then.
Tim Beiko:and yeah, potentially for the next work, we consider some different design to get us to 56, or making the index mandatory, or something like that.
Tim Beiko:Yeah.
milen | Erigon:Okay. Cool.
Tim Beiko:okay, anything else on 7, 9 0, 7.
Tim Beiko:If not, then. Yeah, let's try to get these Prs merged in the next couple of days. So that we have this the final spec. And we can implement it.
Tim Beiko:Next up we had. We discussed this, I think, on the last couple of calls, but I want to finalize the the Max blobs for transactions in Bpos.
Tim Beiko:So right now they were set they were set up 12, and there was there was set at 12, starting at Bpo. One, and there was conversations about moving it back to 2.
Tim Beiko:yeah, I guess. Do we want to limit this back to 6 again? Move it to 9.
Tim Beiko:yeah. It would be nice to get to a final decision on this today.
FLCL:Yeah. I guess. The current proposal is to have it pn 6, right? But.
Tim Beiko:So which proposal? There was no Pr, I guess I know we discussed it. But like, yeah, I couldn't find like Apr or anything. So I guess
Tim Beiko:that's kind of why I wanted to bring it up again. Yeah.
FLCL:It would be cool to have a inform of Pr, I was asking about this in chat. Maybe it will appear later. This meeting
FLCL:but
FLCL:I guess another cause of not having this pair is because it's in kind of discussion.
FLCL:because we can go even 3 ways. 1st way is to
FLCL:keep for what we already implemented in the current form, and.
Tim Beiko:That's that's the 6, and then 12 for the vpos, as the eip States. Correct
Tim Beiko:by 12. What number do you mean like
Tim Beiko:per transaction. So when you say what's currently implemented, the Eip currently says sticks up to Osaka, and then Bpo, one Bpo, 2 have 12. So is that what the clients already have.
Barnabas:The Erp states that we're gonna use the Max value by default. If you don't re specify.
Tim Beiko:Okay, I see.
Tim Beiko:And so what the clients already have is they use this Max value by default
Tim Beiko:which is which goes from 6 to 12 in the 1st vpo.
FLCL:Yeah, I guess. this can be split into 2 discussions. 1st one is, how
FLCL:do we actually define this value. Is it a constant in a
FLCL:pure desk eap, and we will not change it in schedule.
FLCL:and whether it is a consensus, a value that affects consensus or just at the expo value.
FLCL:And after that we can decide about specific value. As far as a
FLCL:remember, answer post 6 for Vpr. I guess.
FLCL:But this is seems to me like the second part of discussion.
FLCL:So
FLCL:let me say a couple of parts about the 1st part I still think that it is quite convenient to have this video in both schedule, and to gradually increase it through the forks
FLCL:Should it affect consensus or not?
FLCL:Right now it it does not affect consensus. Everybody can build blocks with without with limit.
FLCL:defining just by how much blobs we can include in the block and
FLCL:the the initial idea was to limit how much one transaction can
FLCL:includable transition can contain blobs like single transaction.
FLCL:and I see that some clients support the idea is to have it as a text pool limit only.
FLCL:and the I wanted to hear more opinions about that.
FLCL:You guys have anything to say.
FLCL:Is it a taxable limitation for propagation, or we cannot include huge transactions into a block too.
Tim Beiko:Oh, yeah. Francesco.
Francesco:Yeah. Personally, I don't really see the point of making it a blood pool. Only thing I I think it should. We should make it.
Francesco:we should have in consensus as well. And the reason is, that if you're not going through the map pool like you're sending directly to to builder. I don't think this is much of any limitation like you can just split. Add multiple transactions, and split them that way. I I don't think it really like. The only thing that it does is that you cannot amortize more. But that's kind of a negligible thing that I don't think we should care about like beyond a certain point, it just doesn't matter. And yeah, and for.
Francesco:And you do get benefits from. I have any consensus that it's impossible to to kind of send a really large transaction that makes packing much harder. So I I just really don't see the benefits of having it only in the pool, and not in consensus.
FLCL:Okay, if you guys, anyone wants it to be textual. Only or could you raise your oh.
FLCL:opinion and otherwise. Zone, the question, yeah. Sorry
FLCL:no one. If so. The second question of whether we should place it in blob schedule or just in the product. Api. I right now, I have no strong opinion, because we always can switch back to
FLCL:what schedule settings if we decide to use them.
FLCL:Oh, we're changing this video
FLCL:but for me it seemed that it would be nicer, because it would prioritize, takes full changes towards scalability. And if we could
FLCL:like, keep in mind that we could increase it. Value from fork to fork, and spend some time on it. It would be better for text pool scalability with which we can.
FLCL:If we have this just as a constant, we can then
FLCL:like deprioritize in some sense this like improvements, potential improvements
FLCL:otherwise it would be very easy and flexible to change it in the future. If we will. Figure out that we can do this, we can make it 1224,
FLCL:72 in other value.
FLCL:So but the concern that it looks ugly in the blob schedule
FLCL:right, because you need to set value if you don't want to make it. No.
FLCL:I don't think. Yeah. I don't think the concern is just. It looks ugly. It's like we were literally talking about consensus issues based on fork id, because the blob schedule is a bit weird now. So I.
Tim Beiko:I I might be a bit low context on this, but like I really don't see a strong rationale towards making raising that number like I
Tim Beiko:I don't know if 6 or 9 is the right number. I I don't have a strong opinion on that, but I I don't see why we don't just like hard code it. And then, if people feel like it's insufficient, we just change it in the next real hard fork.
Tim Beiko:I I don't think the cost of amortizing beyond, like 6 blobs, is is crazy to ask of of roll ups.
FLCL:10 is like 10 times more than what base now uses. They use like one, and point.
Barnabas:Not in a single transaction.
Barnabas:They they don't care if it's in a single transaction or in.
Tim Beiko:Yeah, exactly. They have to pay what it's like, 21,000 gas difference, basically. Maybe a bit more, because they have to call like the contract. But like, I,
Tim Beiko:yeah, and.
FLCL:Oh!
Tim Beiko:And like, yeah, if the if the limit is, if the limit is 9 today, then like, yeah, maybe we just leave it at 9. We don't necessarily need to like we don't necessarily need to to lower it. I I don't have a super strong view there, but I guess
Tim Beiko:I do have a relatively strong view that we
Tim Beiko:this doesn't seem like we're a worthwhile place to introduce complexity.
FLCL:We don't need a lot of blocks in one transaction.
Tim Beiko:I guess, to your point about the specs
Tim Beiko:where this is maybe a dumb question. But, like, where is this value currently specified? Like? Is it in the? Is it in the blob extension eip from Petra that specifies the cap?
Tim Beiko:Sorry.
Barnabas:It's gonna be Po yet.
Tim Beiko:No, I mean but on my net now.
FLCL:And I I think it's just specified as a text pool limit in some implementations.
FLCL:And and the.
Tim Beiko:No, there is no limit on Mainnet today. Okay.
Roman:There is a limit which is the maximum you can have per block. Technically.
Tim Beiko:Could.
Tim Beiko:Oh, right? Right?
Tim Beiko:Yeah, yeah. Okay. So there's no transaction limit. Vip, only block. I see.
FLCL:Yeah. And I just wanted to mention about 9 which is another topic. Why, 9 is better, because, you know, do not need to take care of eviction of such transactions when Osaka happens. Because
FLCL:we had limit 9 before then it became 6, and you need to remove it from a transaction pool and take care of block building for this specific block, you know. Because
FLCL:we we had such case when we could build a block, we fixed it, but we could build a block with a big number of blocks in transaction, because we did not evict it.
FLCL:And yeah.
Tim Beiko:Yeah. So I guess the question then is like, yeah, do we?
Tim Beiko:It seems like, we probably do want a limit in consensus now. So we're gonna have to add this, no matter what
Tim Beiko:I guess I don't know on guard. What is the decision we made 2 weeks ago.
Ansgar Dietrichs:Well, I mean.
Tim Beiko:On Monday. It didn't seem it didn't seem super clear to people. Yeah.
Ansgar Dietrichs:No. 2 weeks ago, we said we moved the per transaction limit out of the Bpo specification just into the and set it to 6. And I mean again, that's just an arbitrary choice. We can totally make a different choice. But like I don't know, it's like.
Tim Beiko:Yeah, I guess I'm yeah. I'm fine with that. If we agree to that, then there's no objection. It just seemed on Monday people were still discussing off this call. But
Tim Beiko:yes, does anyone oppose this? And if
Tim Beiko:if not like, can we just open the Pr after this call?
Tim Beiko:Okay. The issue was that nobody actually made the change.
Tim Beiko:so does anyone want to volunteer to open those Cprs.
Tim Beiko:I guess anyone who's implemented peer peered us
Tim Beiko:on the El side.
Tim Beiko:Get someone do that. Pr.
FLCL:Let's ask in the chat, probably to to agree.
Tim Beiko:10 years.
FLCL:This and you do it 3 or 2
FLCL:yeah, I can. But I already did this. And maybe it.
FLCL:The details were not not obvious enough to decline it.
Tim Beiko:I'm sorry. Did did you actually have an open Pr, because I could not find one.
FLCL:No, no, I might block schedule changes. Okay, let me do this simply.
Tim Beiko:Okay, amazing. So yeah, so the Pr would be to remove this Max blob per transaction.
Tim Beiko:constant from the eip. 7, 8, 9 2 to add a cap in the pier. Peer cip for 6
Tim Beiko:and yes, sorry if this is not your favorite choice, but thank you in advance for
Tim Beiko:for making the Pr.
Tim Beiko:There was an other comment in the chat that came up by Lewis. Or sorry. No,
Tim Beiko:I forget who but as we were talking about keeping the specs simple for the vpo sorry, Gabriel said, that we should consider removing base fee update fraction from Vpos
Tim Beiko:and only have the target. And Max, because effectively, from Osaka, it's it's like a stable. So this would mean that if we want to change the base fee update fraction. We need another real hard fork.
Tim Beiko:The people think we should also do that change to make ppos simpler.
Tim Beiko:Barnabas says, yes, Gabriel says yes.
Tim Beiko:Is there some reason to remove the feature when we already have it? I guess it's just to limit the risks of consensus changes and consensus issues.
Tim Beiko:where is that specified? Here.
Parithosh Jayanthi:Well, the only kind of question is, if we ship Fusa, and we do the analysis, and we decide that we want
Parithosh Jayanthi:Ppo value that doesn't have the same ratio. Then we won't be able to right. So we kind of limit what.
Tim Beiko:Well, what?
Parithosh Jayanthi:We can choose in the future.
Tim Beiko:Well, when we ship from Saka we have to choose that value
Tim Beiko:right? And then what we're saying is that we would not change that value before the next quote real unfold.
Tim Beiko:Hard fork. Sorry. So
Tim Beiko:so we could ship. You know, Fusaka, we're Gonna say, these are all the Bpos. They all have the same ratio, and then for a future fork. Either we choose to change that ratio for all of the Bpos, or we choose to reintroduce this.
Tim Beiko:it's fine.
Tim Beiko:It it's fine to to leave it in. But like, yeah, it's just like another source of complexity. Yeah, on scar.
Ansgar Dietrichs:Yeah, I would. I would personally prefer to leave it in unless clients have that as a pain point specifically, that this this specific extra value has caused issues because it is very convenient to be able to to basically have that extra lever where, if we feel like, we want to get a little bit more throughput. But we, we are already at the maximum. The network can handle that. We can basically in principle, if if the data support supports that that we have a little bit more room to go, and just squeezing that ratio a bit more.
Ansgar Dietrichs:It just yeah. It feels like in the spirit of of of Bpos to to be able to have that configurable but.
Tim Beiko:Do we want this in the 1st iteration of Vp, like, do we think we're gonna well, I mean.
Tim Beiko:yeah.
Ansgar Dietrichs:Meaning. Do we want to use this Pre Amsterdam? Right? But because it could be that like, it's not in the 1st Bpo that comes with Fusaka, but it could be that we we then have a later client release. That's basically Bpo, 2, 3, 4, that that still comes. Pre Amsterdam, and I do think there's a chance we might want to do it in there. No.
Parithosh Jayanthi:Yeah, and also just adding onto that, we might run into this weird situation in the future when we do change it. Where clients then need to have extra logic that says, for Bpo, 1, 2, 3, use the base fee, update fraction from Prague, but for 5, 6, 7, use it from Amsterdam. And at that point you basically come back to just defining it in the blob schedule because you need that mapping between Bpo and Blob schedule. Anyway.
Tim Beiko:Okay, okay, I think this convinces me. So
Tim Beiko:I think we leave this as is. And if it does become a pain point, we can reconsider removing it.
Tim Beiko:And
Tim Beiko:so for now, okay, let's just stick with the previous decision. We remove the Max Blobs per transaction from the Bpo config, and we add a cap of 6 per transaction in the pure desk. Spec.
Tim Beiko:Anything else on peer to us or Bpo's?
Tim Beiko:Okay. Next up. Then there was an update on MoD. Exp, where Marson said that it still poses some issue performance wise at higher gas limits. And there's 2 paths to dealing with this. Either we do a bunch of client optimizations or we potentially just radically increase the price where we where we triple the price of MoD exp. So there was a pr for this.
Tim Beiko:I don't know if Marcin is on the call, and so do you want to give some more context, on on the work you've done.
Marcin Sobczak:Yeah, yes, sure. So. I think like our target after Fusaka is to be ready for 100 million cost limit. And unfortunately, with 8, 7, 8, 8, 3 in current shape and with current clients implementations that we can't do this. Because you can take a look at the graph. I I posted it it in issue of this meeting.
Marcin Sobczak:and Ref, never mind and bezel are per performing good enough but we have, and argon with worst modex cases. After repricing at 26 mega gas per second, when 33 is the minimum requirement for for going to 100 million gas limit.
Marcin Sobczak:And at this point we can, we have to try. We have a we have a choice to try to improve clients, or to increase modex pricing even more.
Marcin Sobczak:And
Marcin Sobczak:if we exclude modex and look at other bottlenecks, and then there are, of course, some clients, specific bottlenecks, but on protocol level the next blocker is easy recovery and easy mall, and they are performing at about 50 to 55 megabits per second, and we would like to avoid the situation when we reprise Modex, and it will become
Marcin Sobczak:a bottleneck again after Fussaka. So if you want to avoid it, we need it to perform at least at this level of 50 to 55 megabits per second. And right now we have 2 clients at 26, so they would need to double the performance.
Marcin Sobczak:And
Marcin Sobczak:why, there are so big differences between clients so in Ref. And never mind this, this client are using very fast library in Gmp. And it is because they are so fast and it might not be
Marcin Sobczak:not be a good idea to force our clients to to move to to the same library, and probably it's better for protocol in general to have it more diversified. But then the the question is, if it is possible to to move performance to be twice faster.
Marcin Sobczak:And if it is possible it's great, but if not, we need to increase
Marcin Sobczak:the the prices again. And
Marcin Sobczak:I pass 7, 8, 8, 3 in current shape, and it. It was designed to have the lowest possible impact on the calls. So in current form.
Marcin Sobczak:it's affecting only 38% of calls. And we already know the addresses which are affected. There is a great report made by Tony about the impact of of this, and all the edge cases are already already addressed.
Marcin Sobczak:So if we want to increase prices more, then we just need to do like a general price increase. So then, 100% of calls and 100% of users will be affected.
Marcin Sobczak:And if we will affect all users, then we can probably go pricey and just triple the price, because
Marcin Sobczak:everyone will be affected in a way.
Marcin Sobczak:So at the end.
Marcin Sobczak:Hmm, that
Marcin Sobczak:I left everyone with the question, what we want to do we can try to to improve gaff and argon, but it will require doubling the perf the speed of the worst case of modex, or we need to reprice modex more. But then all the users will be affected.
Marcin Sobczak:Yeah, thank you.
Tim Beiko:Thanks for sharing Milan.
milen | Erigon:Yeah. Hi, I just wanted to mention quickly on that note that we are
milen | Erigon:experimenting with improving the performance. For modex at the moment.
milen | Erigon:And it's without gmp.
milen | Erigon:but we probably need, like maybe a few more days, to actually see the outcome of this.
milen | Erigon:So if if, if, like, a few more days is is okay, then
milen | Erigon:we can provide some, input then on this.
Tim Beiko:Okay,
Tim Beiko:And then, yeah, I asked who would be most affected if we could.
Tim Beiko:if we were to reprice this and it seems like it's been hard to get some numbers out of
Tim Beiko:out of dune for like, what are the biggest users of this free compile.
Tim Beiko:Oh, matter! Labs seems to be one of them.
Tim Beiko:I guess.
Tim Beiko:Given. This is like a relatively
Tim Beiko:small change spec wise, and I expect we still probably have a couple of weeks before launching definite 3. Does it make sense to spend the next 2 weeks actually investigating this more deeply? And then making a final call before the definite 3, the definite 3 launch.
Tim Beiko:I guess. Okay. On guard. As a question like, are we certain we're gonna have another
Tim Beiko:acde before launching Devnet 3. I guess. Based on
Tim Beiko:the the reports of W. 2 today. I expect
Tim Beiko:we're probably not going to launch Devnet 3 this week
Tim Beiko:or next week. But I don't know is that is that potentially off?
Tim Beiko:Yeah, Felix.
Felix (geth):No, I just sorry, maybe. But
Felix (geth):off topic, I just want to say that, like within Geth, we are definitely investigating the performance increase
Felix (geth):in terms of just like improving the performance of the implementation. But I also think that it would be wise to just like slightly overprice the MoD. Xp, anyways, because, yeah, maybe we missed something or
Felix (geth):so might actually be a good idea to just go with the
Felix (geth):higher price if it makes no difference, after all. I mean, we have to see it can't be unreasonably like can't be priced unreasonably high, but if it doesn't make that much of a difference. We might as well just do it.
Tim Beiko:Yeah. And I guess
Tim Beiko:what we would want to figure out is, is there any application that breaks at a 3 x price from odd. Xp are there any applications that become kind of cost? Prohibitive?
Tim Beiko:And so it seems like Maris listed a few like matter labs coinbase smart wallet Eigenda. So maybe we can reach out to those in the next week.
Tim Beiko:yeah, get their thoughts. And potentially, we could also just finalize this on Acdc next week, even though it's not a Cl. Topic. But if we want to move fast and not
Tim Beiko:not worth delaying. Demo 3
Tim Beiko:That seems like a reasonable path forward.
Parithosh Jayanthi:Could we make a plan as to what the open questions are? And who's gonna be investigating them?
Tim Beiko:So I guess the one question I would have on the pricing is just if we if we reach out to like, you know, say, these 3 and potentially other large users that precompile asking them with a 3 x with a 3 x price increase
Tim Beiko:of this precompile. If it let if it led us to being able to raise a gas so that significantly make a difference for you.
Tim Beiko:I think that's like
Tim Beiko:something we can ask those 3. I'm happy to own that, I guess, on the library benchmarking. I'm less sure what the actual next steps would be.
Felix (geth):We were on it with the, with the with the library stuff like. That's the thing we.
Tim Beiko:Yeah.
Felix (geth):There's like changes being investigated. And I mean.
Felix (geth):yeah, we can in the other thing to know is that we only ever really worry about MoD exp in the context of like worst cases. So like worst case attacks, we're not really seeing that like blocks are being filled with the MoD exp right now. So the other thing we could do is kind of just like implement gmp, as a kind of optional back end or something like that. But it will. It will have some technical downsides. But it's something that we could do where basically, we will have the option of activating it at
Felix (geth):if we need to, or something like that. But I would strongly prefer to try to have at least like 2 implementations of this function
Felix (geth):somehow, like, if it's fine if it's Gmp. And one other one, I think that would be good enough.
Tim Beiko:I'm Anskar.
Ansgar Dietrichs:Yeah, on the on the question of like, basically reaching out to people or what to investigate. I
Ansgar Dietrichs:personally think if we are serious about scaling, which I think we are then
Ansgar Dietrichs:coming up like in Glamsterdam, at the latest, and then the fox. Afterwards we will probably have to make very
Ansgar Dietrichs:at least we will have to be comfortable with starting to make decisions that are a bit more breaking.
Ansgar Dietrichs:Some use cases, or basically just in general, a bit more disruptive, because that just comes with the territory like we will have to change the evm a bit more in general, and the execution system. I feel like this is a very mild case. If we already have concerns here, I feel like that. The entire kind of project seems doubtful. So I, personally would actually say, we should just go ahead and make this decision as a bit of a just
Ansgar Dietrichs:getting used to settling the tone that basically people have to expect that occasionally prices change and prices change in like mildly disruptive ways, and there's no way around it. And that's just the cost of
Ansgar Dietrichs:actually going to higher throughput. So I would personally just prefer to make make that decision today.
Tim Beiko:Okay,
Tim Beiko:let's do some. And then, yeah, we can see if we want to do this and commit to it now. But yeah, some.
Som | Erigon:Question to get actually, have you guys shipped the
Som | Erigon:improvements in a release? Or are you planning to move
Som | Erigon:Release it, because Arizon and I think
Som | Erigon:get had initially gotten some improvements with knock. But the latest libraries for Ec. Stuff isn't really audited fully.
Felix (geth):Hmm, so yeah, there was a problem with the. So we disabled it again. But I think it's
Felix (geth):I have to actually check if we if we chipped.
Felix (geth):enabling it again. So basically, we enabled it for a short time. Then we disabled it because of some like bug
Felix (geth):and then. So now we have to check it back. If it's like.
Som | Erigon:Yeah. So the issue was, some kind of encoding on the 1st bite or something. But.
Felix (geth):Yeah. Yes.
Felix (geth):Okay.
Som | Erigon:Yes, the point I'm trying to make is
Som | Erigon:enabling that because you disabled it, you know you had one reason to. There might be more reasons to disable it. If you don't go for the audit. So chasing performance may have security issues just like this. And
Som | Erigon:it's only that we saw in the perf net that we were able to get these performance gains with the switched library that we are now discussing modex but otherwise would we would be discussing
Som | Erigon:the Ec. Precompiles on this call.
Som | Erigon:So maybe it's worth revisiting that as well. Which would mean,
Som | Erigon:repricing may just be the way to go if you want to bank on the battle tested.
Som | Erigon:Libraries we've been using in the Evm for for so many years, and not really
Som | Erigon:be enthusiastic about switching them all just to fit the same cost for those.
Felix (geth):That's actually a good point, especially with Canarq. So basically, your point is that all the clients use Canarq. Now for this, for these preconfers or.
Som | Erigon:I just get an arrogant. But the point is,
Som | Erigon:Ju, just because we saw the performance improvements. I don't think we're in a position to
Som | Erigon:make releases in the next 2 weeks on that. And that would mean that it's
Som | Erigon:not battle tested. Even if we do you know, even if we take the risk, which is kind of big? So I would say.
Som | Erigon:If you want a higher limit just raise the prices. Assuming
Som | Erigon:the bad performance of the libraries we have been using over the years which you know, for easy add. The performance, I remember, was like
Som | Erigon:13 mega gas.
Som | Erigon:So if we are not comfortable, say by the next devnet that we want, which you know. By the way, I'm not because, you know, we have to do some internal analysis on our side as well. We have made some releases since then, but none of them have this connect switch
Som | Erigon:and even if we are able to get some performance gains with more decks.
Som | Erigon:I'm not sure we should just
Som | Erigon:not reprice anything and just claim that you know the performance is great. So now we are good to go. So repricing should be the way to go
Som | Erigon:for Fussaka.
Tim Beiko:But I don't know who iphone is, but.
Kev:Oh, sorry I forgot to rename. Yeah, I was just gonna say that I think that
Kev:Gaff and probably Aragon rely on Ganak already, just because of the Kg precompile.
Som | Erigon:It's the audit covering those. And the easy stuff was different.
Kev:well, to do the Kg precompile, you need sort of a curve underneath, right? Like Bls. 12 freight one.
Kev:So like it's it's the same like,
Kev:yeah, it's like the same code.
Kev:It's just that we have a library on top of it for Kg, precompile.
Tim Beiko:Okay, so.
Tim Beiko:but I guess yeah, based just on the previous comments. Like, if if we don't feel confident in in relying on the libraries, at least. Now,
Tim Beiko:like, I guess. Yeah, is there any downside? Is there any significant downside to accepting the the.
Tim Beiko:the the price increase now and
Tim Beiko:again, if our if our confidence really increases that we don't need to do this, we can always walk it back. But just
Tim Beiko:in terms of finalizing the specs for Fusaka, I would.
Tim Beiko:I would probably lead towards
Tim Beiko:I would probably need towards moving forward with the repricing and having that indemnant 3.
Tim Beiko:Yeah. So I guess any objections to including that. Pr to 3 x MoD, dxp gas price.
Tim Beiko:Okay, then, let's get this merged. I'll also reach out to the 3 projects we listed to. Just see if they have any kind of concerns that come up. After this. But let's assume we're moving forward with this. And we'd include this change for Defnet 3.
Tim Beiko:Okay, I think this was the last Fussaka issue to cover today. Anything else before we move on.
Tim Beiko:Oh, Spencer actually had 2. So okay, we agreed to change the Blob base cost in 7 9, 18 on the last acde,
Tim Beiko:7, 9, 18.
Tim Beiko:did anyone open that pr.
Tim Beiko:if not, is anyone. Can anyone just make that change? Okay, Francesco is, gonna do the the
Tim Beiko:7 9 18? Pr, thank you.
Tim Beiko:and then, for 7, 9, 5, 1 repricings.
Tim Beiko:Does anyone have context on this one? I actually don't quite remember this one.
Tim Beiko:Yeah, does anyone have context on the 7, 9, 5, 1, the 7, 2, 1, the the r, 1 curve repricing.
Marius:I don't have much contact. No one is picking up. I can.
Marius:I can say that I think the last benchmark we did.
Marius:It felt like it was also underpriced compared to other pre compiles, and we should also consider repricing it.
Marius:Think the number we kind of
Marius:look that was 2 x price.
Marius:But yeah, I've kind of low contacts on this as well.
Tim Beiko:Okay?
Tim Beiko:So yeah, I was, gonna say, if we don't have more data to prove it's safe lower, we should just 2 x the price.
Tim Beiko:this.
Tim Beiko:Does anyone have an objection to that?
Tim Beiko:If not that thing, then yes, we should just move forward and and hopefully get to a final pricing scheme today.
Tim Beiko:so does anyone want to open a Pr
Tim Beiko:to 2 x the price of that one.
Marius:Let's do it.
Tim Beiko:Okay, thank you.
Tim Beiko:Okay.
Tim Beiko:Any other Fusaka related issues people want to bring up.
Tim Beiko:Okay? Then, moving on to Glamsterdam, so we've had many different headliners being proposed for for Glamsterdam. The deadline for the proposals was June 20, th and I don't think that we've seen any new proposals since then, at least, I I haven't
Tim Beiko:so I think we've
Tim Beiko:we're pretty good in terms of freezing the like proposals for to Amsterdam headliners. But
Tim Beiko:originally we said that we would make a final decision 2 weeks from now. That does seem quite premature. So I I want to ask client teams like.
Tim Beiko:what's the amount of time you think we need to actually review this have, like a proper discussion around the different candidates, headliners? My senses. We need at least a month potentially more. But
Tim Beiko:yeah, how the client teams feel about this?
Tim Beiko:Yeah, Andrew.
Andrew Ashikhmin:Yeah, I don't speak for Aragon. I don't think we've collected Aragon's point of view, but personally, I think we should go for the block access list. It helps a lot with parallelization, especially in the worst case, and I think parallelization is crucial for achieving a scalability of ethereum.
Tim Beiko:Got it? And yeah, I guess to Luke's comment, like, yeah, I think we should consider the the proposals being closed. And it's more a question of like.
Tim Beiko:how much time do people need to actually review this? And how many discussions we want to have on on Acd about it?
Tim Beiko:and my instinct is like we probably need at least like
Tim Beiko:2 calls or something like and
Tim Beiko:and I expect we could probably spend a big chunk of the next call on this.
Tim Beiko:but I, yeah, I this, this assumes that client team actually have time to start looking into this.
Tim Beiko:yeah, before the next. The next calls.
Tim Beiko:and yeah, it's possible that the next 2 weeks are spent on like Devnet 3. So I,
Tim Beiko:if if we, if we assume that that it meant, you know, like July 17, we finalized them at 3. Then, like on the 31st of July and the 15th of August. We would like spend time looking into these headliners, at least for the for the
Tim Beiko:for the el side, and I think this also gives us
Tim Beiko:enough heads up to like reach out to the rest of the community. And get their thoughts on this.
Tim Beiko:so yeah, I guess maybe. Yeah. This is my proposal is that we we kind of
Tim Beiko:focus on them the 3 in the next call. So July 17.th And then the 2 calls after that. We. We try to sort through at least the El side of the headliners, and then teams can start start reviewing them.
Tim Beiko:you know. In the meantime. We can obviously discuss them on these magicians. And if there's stuff that comes up we can do so on these calls. But we can kind of
Tim Beiko:proactively mark these 2 calls as as when we would discuss it, when we would want community input to come in by and and whatnot
Tim Beiko:And then the okay, miss question. I think we would want to only sort out all the other eips once we've actually chosen the the headliner. Because otherwise. Yeah, it's kind of hard to make decisions about the small features if we don't know what the big feature is already.
Tim Beiko:And
Tim Beiko:yeah. So just to be like, really explicit. So in terms of the schedule like July 17, th in 2 weeks, we would just focus on them the 3 in Fusaka, wrapping that up and then, like the 2 main calls we would use to discuss the El Headliners would be August 31st and
Tim Beiko:oh, sorry. July 31st and August 14, th
Tim Beiko:And yeah, on that note. And Nick, so you had a comment about forecast, do you? Wanna
Tim Beiko:you want to give a quick overview of it.
nixo:Sure happy to. So Mark and I have been working on this resource. It's forecast.org and basically it just shows the main benefits of every eip, and also how stakeholders are affected. And we would love
nixo:input from any any interested parties in the Eip. We already got most of the Eip authors to look over, except, I think, except for
nixo:one eip. But yeah, we would love feedback on that. Or if anybody has ideas for additional features that might be useful to help compare across these. There's also a Fusaka page, but we would like to focus on Glamsterdam just to be a good resource for people to look at the headliners and really understand
nixo:what those headliners are.
Tim Beiko:Yeah.
Tim Beiko:thanks. And yeah, this is a really cool tool. So if you have feedback on it, please reach out to Mixo or mark, and they will keep improving it. But they already have all the different headliners for the that have been proposed listed there.
Tim Beiko:Okay. And so the
Tim Beiko:for the other eips in Amsterdam. I think we should wait, like, I said, to to have a headliner before we make a call on them. So Guillaume had proposed this, adding a code chunking eip to Amsterdam but then we also have Cfi, a bunch of eips for Amsterdam really early on
Tim Beiko:that were mostly vertical, related. So my proposal would be that we move both those vertical related eips, and also the code chunking eip and any other eip that wants to be proposed as a not headliner just to the Pfi list, so anyone can open a Pr. We can start tracking them. But we don't quite make a decision about them yet. And then, once we actually have the decision on the headliner, then we review this like long.
Tim Beiko:long tail of of smaller vips, and and decide which ones can fill in.
Tim Beiko:I guess. First, st the people generally agree. This makes sense, and then second.
Tim Beiko:second, like, is it okay to move the previously Cfi vips from like the old process back to Pfi, because I I don't think we actually add pfi. When we move those to Cfi.
Guillaume:Which which Ips are we talking about like the the.
Guillaume:Ones.
Tim Beiko:I posted the Pr. It's more than 2. It was state 4, 7, 6, 2. The statelessness gas cost changes
Tim Beiko:6,800 the vertical, 1, 6, 8, 7, 3. Pre image, retention, 7, 5, 4, 5, vertical proof, verification, precompile, and 7, 6, 6, 7 raised the cost of hash functions. So all of these were like Cfi before we actually had
Tim Beiko:efi kind of status and
Guillaume:The pre compile one. I think it should be withdrawn or abandoned because I thought it was actually 4, 7, 6, 2. Yeah. Makes no sense in Glamsterdam, 6,800 should be withdrawn, so no need to move them anywhere the Hashing one. I don't think it's mine or mine or my teams?
Guillaume:Yeah. Did we cover them all.
Tim Beiko:So yeah, stateless gas cost change. I mean, if you wanna just look at the Pr, if you if you think it's fine to just remove them all. Just leave a comment on the Pr. And I'll do that.
Guillaume:Okay, yeah. I just saw you here. Okay, I can leave a comment. But yeah, most of them are need to be gone. And one of them, like the 4, 7, 6, 2
Guillaume:needs to be saved for later.
Tim Beiko:Yeah, okay, perfect. Yeah.
Tim Beiko:And then, yeah. So for guille for your next eip. Then I would just, I would just open a Pr. Against the Amsterdam Meta eip. Add it to the Pfi list, and then once we're ready to discuss those after the the headliners, we'll discuss it then, and I'll be the others people can obviously start discussing it Async in the meantime. But
Tim Beiko:yeah, this allows us.
Guillaume:Sorry you mean 2029, 26.
Tim Beiko:Correct. Yeah.
Guillaume:Okay.
Tim Beiko:Yep,
Tim Beiko:And then yes, there was one last question about the deadline for pfi and small vips. We also had a deadline for this, but I think
Tim Beiko:I I didn't. Wanna set this given this revised date. I think it's fine to discuss this in the next 2 weeks or Async. But I we should have a deadline, it should be after we've chosen the headliner. So
Tim Beiko:so so yeah, like, I don't. I know when we want to have this. But I
Tim Beiko:yeah, I think a month or 2 after the headliners were chosen.
Tim Beiko:and so I don't. I think it's fine to wait for the Pfi deadline for the next call. We've agreed on like when the headliners should come.
Tim Beiko:And then on the point of multiple headliners. Historically.
Tim Beiko:we've never succeeded at that. So I would have a very strong bias against it. But it's possible that, like there's exceptions here. But the whole point is saying, like, what is the most important thing we wanted to fork. And what would you want to like? Build the fork around? And the only time we ever tried to do this with 2 things was the original version of Petra, and I went pretty porty, so I
Tim Beiko:I I think we should try to stick to one as as much as we can.
Tim Beiko:Yes, if we aim for a quick, small fork, we'll get a regular sized medium time fork.
Tim Beiko:Okay? So just to recap. Yeah, headliner discussions focused on or focused on the July 31st and August 14th call. We'll figure out the deadlines for the
Tim Beiko:for for the other the other stage of the process after
Tim Beiko:and then we can move these other vips to either pfi or remove them if they're no longer relevant.
Tim Beiko:Anything else on capsdam.
Tim Beiko:Okay? Then Matt had some history. Ex fiery updates.
Tim Beiko:yes. Do you want to give some context on the error file.
lightclient:Yeah, sure. So there's 2 quick things I want to touch on. The 1st is this error, e-file format, which I linked to on the Pm. Repo.
lightclient:I will share a link here as well.
lightclient:Basically the motivation for this is the error. One file format. We sort of designed this several years ago, with the intention that arrow one would always and only be for the information that was before the merge, and we had thought that we would go for the post merge data, using this file format that already existed on the consensus layer, which was just error.
lightclient:And over time of the last year or so. We've kind of realized that
lightclient:maybe it makes sense for execution layer and consensus layer to have different file formats.
lightclient:If you're an execution layer, and you were trying to bootstrap an archive node. You don't necessarily want to download all of the Beacon state data, and whatever else that the error file might have that, you know, the consistent layer file might have that allows them to do debugging. And so when we were in Berlin a few weeks ago, we sat down with some of the people, and we talked about what an execution! Only error file would look like.
lightclient:and it looks very similar to how era one looks like. With a couple notable exceptions, I'll just give you the footnotes of it. But the specification will go over in detail the things that changed the most important things that changed is that instead of storing the values per block sequentially meaning storing the header, followed by the body, followed by the receipts
lightclient:we now store all of the headers, all of the bodies, all of the receipts. This allows for us to do to respond to range queries
lightclient:more efficiently for syncing.
lightclient:We also changed the receipt format because most people don't actually store the 2718 receipt format. And so we've stored it in like a more optimal way.
lightclient:And then we've added a proof format which is kind of optional for error E, but allows.
lightclient:if included, for anyone, to verify any block within the error E file against some historical root in the consensus layer. So it still kind of gives this like good verifiable property.
lightclient:So the area E file. This is kind of like my proposed specification. I would love to get some feedback on this over the next couple weeks. Basically, what we want to do now is that we've we've kind of done this pre-merge history, expiry and clients support this.
lightclient:and we'll talk about like defaults in a second. But we also want to continue expiring history, and we're working towards rolling history. Expire. This is kind of the golden standard, the thing that we, you know, once we achieve this, and we can say that like history expires.
lightclient:kind of finished. But before then there's still a lot of data between the pre-merge history and the moment when Rollops began to use blobs. So
lightclient:Eric E.
lightclient:Is kind of the the one thing in our way from really
lightclient:going from pre-merge history expiry to expiring up to the Cancun hard Fork.
lightclient:So that's kind of why I'm like trying to get feedback on this and iterate on this pretty quickly is because the faster that we can get sorted out, the faster we can generate the files the faster we can start having people serve and store these files, and the faster we can begin expiring history post merge up to Cancun
lightclient:and potentially before. But basically, I just want to get agreements on this file format. And then once we agree and we generate the files for the history it's up to clients to kind of decide what they're comfortable with. If clients don't feel comfortable pruning history beyond the merge. That's fine. I know some clients are really
lightclient:are really hoping to do this sooner than later, so we want to make sure that it is going to be possible for them to do that as soon as possible. So my goal is by the end of July. We agree on this area e format. And in parallel, we're kind of working on implementation. But
lightclient:the expectation is that once we agree on this file format, it shouldn't take more than a few weeks to complete the implementation. Generate the files, share the files, and we could kind of say, All right, if clients want to start expiring up to Cancun. Then that's okay. It's their decision.
lightclient:So that's era E files. Are there any questions or comments on that?
lightclient:See? Storm asked if receipts are optional right now, receipts are not optional in the error. E file format.
lightclient:Okay.
Tim Beiko:White.
Tim Beiko:We have so many error formats.
lightclient:This is the yeah. Maybe I kind of like glossed over this. But this error format is the one to rule them all for the execution layer. So arrow one
lightclient:we I mean we we. It came up with Era one when we were in Austria several years ago.
lightclient:and, like I said at the time we felt that error. One was just this one thing we needed to do to then unlock execution clients to use error files. But over time we realized that the error file just wasn't quite the right fit for what the execution layer needed. It's not the execution layer can't even generate the error file itself by itself because it needs the consensus layer data as well. So what we want to do is we want to migrate to era E over a period of time.
lightclient:So eventually, when clients are.
lightclient:you know, implemented error E, they can begin to deprecate area one, and move off of that file format.
lightclient:Well, arrow one
lightclient:kind of refer to Eth one. And so it's sort of weird that it would also refer to
lightclient:era post merge, too.
Tim Beiko:Oh, yeah, aside from the naming convention.
Tim Beiko:any other questions.
Tim Beiko:Okay, so
Tim Beiko:yeah, questions around the receipts. We can probably discuss that, I think where's the best place to talk about this?
Tim Beiko:Do you think.
lightclient:I think there's a channel called History Expiry in the R. And D. Discord.
Tim Beiko:Okay.
lightclient:That would.
Tim Beiko:So.
lightclient:Yeah, there is. So I think that's a good place. Also. Execution. Dev, I read that channel just tag me anywhere.
Tim Beiko:Okay, so let's at least have the conversation around the receipts
Tim Beiko:being optional or not. And
Tim Beiko:yeah, when would we need to make a final call on this.
lightclient:I think we have 2 more execution layers of meetings
lightclient:Acds before we should, so not the next one but the one after we should probably be wrapping up any discussion and kind of say, this is the format.
Tim Beiko:Okay?
Tim Beiko:And I guess this kind of brings us to our your last point around like dropping pre merge history by default.
Tim Beiko:when should we do that? Do we want to couple this with Fusaka? Before that? Or, yeah.
lightclient:Yeah. So
lightclient:there's a blog post going out this this week or early next week. I've been in touch with all the client teams about this, so most are aware. But we're going to kind of announce that this partial history, expiry, aspect of history. Expiry is is possible now, and in Berlin a couple weeks ago. I mentioned that because of the work that everyone's done around implementing E. 69 implementing the era, one format that
lightclient:I felt comfortable, saying, it's okay for clients to start making it a default to not download the history.
lightclient:I think Baysu, in the latest release, now makes a default
lightclient:for snap guns. Yeah. So I think some clients are beginning to do this.
lightclient:I just wanted to get a temperature check on if people still feel it's okay, or
lightclient:and also here, like which clients are doing this or intend to do it, and just getting a rough idea of what people's timelines are.
Tim Beiko:I'm rest, Aragon. Never mind anyone.
Tim Beiko:Some topics on this.
Andrew Ashikhmin:Yes, so we are making a release tomorrow that supports it, and that I be. I think it's enabled by default. Please correct me if I'm wrong. But yeah, I think we are dropping them by default.
Tim Beiko:Great, neither mind. And Russ.
Tim Beiko:And then the lines ready. Okay? Awesome.
Tim Beiko:And yeah, that. But oh.
Tim Beiko:okay. Roman checking, but should be able to support it. So great. That's if people could just confirm that on the history expiry channel as well in the next day or so, that'd be great.
Tim Beiko:but yeah, it seems like we should be able to make this a default across all the clients quite soon.
Tim Beiko:Sorry. Do you have anything else at times.
lightclient:I was just gonna say that it is kind of clients decision. I think it is okay to do this. But
lightclient:we're fortunately past the point where we need to move in lockstep. And that was kind of a big goal that I mentioned in Berlin is that we're trying to
lightclient:figure out the things that require group agreement and moving together, and that was doing a 69 waiting until after we stopped relying on receipts for generating the merge genesis. So that is all complete. And then for the error E, we all need to sort of agree on this file format. But once these types of things get done, then it's
lightclient:on the clients to implement it at their convenience, and I know that, like not, every client has the same bandwidth at the same time. And so that's kind of why it's okay for you to make a release, to drop the history when it makes sense for your client.
Tim Beiko:Okay, I think we could wrap up here anything else before that?
Tim Beiko:Well, thank you. Everyone. Yeah, we'll talk to you all on Monday's testing call. And I'll share a summary of of all of this call and the action items in the chat a bit later today.
Tim Beiko:Yeah.
lightclient:All right, thanks, all.
Andrew Ashikhmin:Thank you. Bye-bye.
jochem-brouwer:Bye, guys.
Łukasz Rozmej:Bye.
Marius:Nice.
Chat Logs
00:01:57
Roman:most likely also fork id related
00:02:25
Tim Beiko:Replying to "Is it Tim again?"
On a more serious note, the changes should all be reflected here: https://eips.ethereum.org/EIPS/eip-7600
00:02:37
Barnabas:Maybe easier to list those that did not have issues
00:02:52
Gabriel Trintinalia | Besu:Besu was not calculating forkdId correctly. We fixed it
00:03:01
potuz:Prysm issue was localized to the fork transition and it's resolved, added Spec tests for them. didn't affect anything after that fork, restarting the nodes fixed it too
00:04:02
Barnabas:💯we should test this
00:04:28
spencer-tb:Think this was Danno’s proposal: https://eips.ethereum.org/EIPS/eip-2364
00:04:41
Trent:Carson please stay muted 🙏
00:04:53
Gabriel Trintinalia | Besu:eth_config 🙂
00:05:05
Gabriel Trintinalia | Besu:https://eips.ethereum.org/EIPS/eip-7910
00:05:39
spencer-tb:Replying to "https://eips.ethereu..."
My bad! Yeah I sent wrong link! Thx
00:06:23
Luis Pinto | Besu:There’s a PR for best AFAIK
00:06:55
Ameziane Hamlat:Replying to "There’s a PR for bes..."
https://github.com/hyperledger/besu/pull/8417
00:07:03
Gabriel Trintinalia | Besu:strong support it as well
00:07:46
Barnabas:anyone opposed adding this to devnet 3 scope?
00:08:01
Barnabas:CLs already have this
00:08:04
Parithosh Jayanthi:There’s already a cl config
00:08:08
Parithosh Jayanthi:*cl api config
00:08:13
Łukasz Rozmej:7910 is non-consensus, can be implemented in the background
00:08:37
Barnabas:I can gatekeep ELs on this :D
00:08:58
Barnabas:sgtm
00:09:37
Gabriel Trintinalia | Besu:EIP-7907: In Besu, we have two databases: the state trie and the Flat Database. The Flat Database stores the codesize directly within the account, allowing it to be retrieved without requiring a second access.
We are fine with the proposed changes:
PR 9910 – Reduce the code size limit, increase the cost per word, and fix the EXTCODESIZE issue.
CODESIZE Warm Read Removal (Draft) – Remove the warm read cost for CODESIZE.
PR 9955 – Account for large contracts at transaction entry.
00:10:49
Ansgar Dietrichs:If we keep 7907 in Fusaka, can we please make an explicit decision on whether the code size index is optional or mandatory for Fusaka rollout?
If mandatory, we need to have agreement around timeline and testing of the index
00:11:50
lightclient:nope!
00:13:19
Ansgar Dietrichs:optional means that clients need to be comfortable with worst case performance of 100M gas blocks without the index present. I don’t think we have the benchmarking basis for that tbh
00:14:12
Łukasz Rozmej:potential bottlenecks on IO, jumpdest analysis, memory growth
00:14:57
Justin Florentine (Besu):will you be able to leverage 48 before 256?
00:16:28
Marius:Do you need 256 on mainnet?
00:16:45
Marius:Replying to "Do you need 256 on m..."
Or only on arbitrum
00:18:06
Allan | Offchain Labs:Replying to "Do you need 256 on m..."
We’d prefer to mirror mainnet exactly, rather than deviate from the exact implementation
00:18:29
Ansgar Dietrichs:wait this was not a decision on the index
00:18:34
Ansgar Dietrichs:Replying to "wait this was not a ..."
so is it optional?
00:18:50
Justin Florentine (Besu):client detail, no size in state
00:18:55
jochem-brouwer:I'll prep the perf test
00:18:59
Gabriel Trintinalia | Besu:@jochem-brouwer were you doing that on devnet-2, no?
00:19:02
jochem-brouwer:Yes
00:19:46
Allan | Offchain Labs:Replying to "Do you need 256 on m..."
It’s certainly possible for us to try the larger limit ourselves, but best case scenario is mirroring mainnet exactly!
00:19:48
Justin Florentine (Besu):so performance testing requirement
00:20:14
draganrakita:Replying to "wait this was not a ..."
Nethermind/geth will have its own index
Reth/besu will add field to the account.
Erigon is going to add it to bytecode table (they have ability to read only part of value)
00:20:22
iPhone:@Allan | Offchain Labs do you have more details on the impact of going from 24 to 48 to 96 etc?
00:20:55
iPhone:Replying to "@Allan | Offchain La…"
Is it the bigger the better and the impact starts to taper off at 256 or is it just the bigger the better?
00:21:31
Justin Florentine (Besu):i think we can make the call, we do leave the door open for a client shipping late.
00:21:58
Ansgar Dietrichs:well it’s the only EIP in Fusaka that is a plausible new DOS vector
00:22:05
Gabriel Trintinalia | Besu:Replying to "i think we can make ..."
Shipping later before fusaka 🙂
00:22:28
Ansgar Dietrichs:can we have an agreement for by when we need to see these benchmarks?
00:22:32
jochem-brouwer:I'll add those perf tests to EEST as well as benchmark so every client can test it isolated (obv. on a super small state relative to mainnet)
00:22:56
Allan | Offchain Labs:Replying to "@Allan | Offchain La..."
Bigger is generally better! i can pull more examples, but even a simple Poseidon hash crate blows past 24KB once optimized. More complex crates and precompiles need more headroom to work with
00:23:14
jochem-brouwer:Devnet-3 needs the big contracts (12k) in the prestate but I think we will get this in genesis
00:23:34
Ansgar Dietrichs:okay then let’s just make sure we communicate to community that there is still some risk 7907 doesn’t make it into Fusaka
00:23:41
Justin Florentine (Besu):Replying to "@Allan | Offchain La..."
a distribution curve would be fun to see, an example of a sweet spot that opens up the most inclusion
00:24:10
Barnabas:hopefully not
00:24:15
potuz:hopefully not!
00:24:23
potuz:Replying to "hopefully not"
jinx
00:24:30
potuz:Replying to "hopefully not"
second week in a row that we agree
00:24:33
potuz:Replying to "hopefully not"
there's something wrong
00:24:41
jochem-brouwer:Do 48. 256 KiB w/h mandatory code size index is a big nope. Can pull 3Gib+ from disk
00:24:46
Justin Florentine (Besu):yeah, we're already a week "behind"
00:25:24
Ansgar Dietrichs:Goal for Glamsterdam should definitely be to find a good way to raise the code size limit further (or at all, in case we need to pull 7907 from Fusaka)
00:25:24
draganrakita:Replying to "Do 48. 256 KiB w/h m..."
Don’t having index does not mean that size is not going to be saved somewhere else.
00:25:32
Tim Beiko:https://eips.ethereum.org/EIPS/eip-7892
00:25:34
draganrakita:Replying to "Do 48. 256 KiB w/h m..."
Index as a separate table.
00:25:36
Gabriel Trintinalia | Besu:EIP-7892 –maxBlobsPerTx -> No strong preference, but the priorities are ranked as follows:
Keep in the BPO schedule and make maxBlobsPerTx mandatory.
Already implemented across clients.
No compelling reason to move it to the PeerDAS eip.
Move to PeerDAS EIP with a 9-blob limit. If moving is necessary, prefer maintaining the current Prague limit of 9 blobs per transaction, unless there’s a good argument to reduce it.
Move to PeerDAS EIP and limit it to 6-blob per transaction
00:26:04
draganrakita:Replying to "Do 48. 256 KiB w/h m..."
This is really a misconception here
00:26:15
Allan | Offchain Labs:Replying to "@Allan | Offchain La..."
Let me see what I can do!
00:26:16
Łukasz Rozmej:Replying to "Goal for Glamsterdam..."
First assess if it is really needed to rise further?
00:26:17
Ansgar Dietrichs:I thought decision was last acde to set it to 6 and not touch in BPOs?
00:26:21
Barnabas:@FLCL your time to shine
00:26:25
Marius:6
00:26:53
Gabriel Trintinalia | Besu:Haven’t seen any PR
00:27:09
Tim Beiko:Does anyone support >6?
00:27:12
Ansgar Dietrichs:Replying to "Goal for Glamsterdam..."
I mean long term there should not be any cap on code size, e.g. once we chunk. should just charge proportionally
00:27:31
Luis Pinto | Besu:Replying to "Goal for Glamsterdam..."
Would be good if offchain labs could show a distribution curve as @Justin Florentine (Besu) suggested of where is the sweet spot
00:27:35
Barnabas:EIP states that we use the max by default
00:27:50
draganrakita:Replying to "Do 48. 256 KiB w/h m..."
For example:
Nethermind/geth will have its own index
Reth/besu will add field to the account.
Erigon is going to add it to bytecode table (they have ability to read only part of value)
So nobody is going to load full bytecode but its size first
00:27:56
Francesco:The one thing I am strongly against is using max by default
00:27:57
milen | Erigon:Replying to "Do 48. 256 KiB w/h m..."
Agree with Dragan - we are able to read the size without loading 256kb of code and without storing the size anywhere - already mentioned this several times
00:28:29
Ansgar Dietrichs:Replying to "Goal for Glamsterdam..."
it feels like status quo bias to want to keep any cap long term. we don’t have a cap on how much ETH you can have in your account. or on how many keccaks you can use.
00:28:47
potuz:Replying to "Goal for Glamsterdam..."
This is the right question as Lukasz points, there's only indications from teams shipping on L2 AFAICT, doesn't make sense to me to add a possible DOS on L1 without any evidence of the need on it, if the only argument is an L2 trying to keep the diff minimal to the L1 client, the L1 client can make this constant configurable or easier to maintain, but risking L1 does not make sense
00:29:25
Gabriel Trintinalia | Besu:Today the limit is 9, right? what is the reason to reduce it?
00:30:14
Barnabas:not a fan of txpool limit only
00:30:29
Barnabas:that would open up a bunch of attack vectors still
00:30:48
Parithosh Jayanthi:^+1, its gonna end up via the mev workflow then
00:31:13
Ansgar Dietrichs:Replying to "Do 48. 256 KiB w/h m..."
yes fair, terminology here is imprecise. when I talk about an index, what I personally mean is “a way to access the size of a contract’s code that is at worst as slow as reading a full 24kb contract” (because that is today’s worst case, and what you get charged for)
00:31:35
potuz:+1 Francesco's point, and rollups we've talked about didn't mind the reduction as well
00:31:52
Tim Beiko:Replying to "+1 Francesco's point..."
Reduction from 9 to 6?
00:32:14
Barnabas:Replying to "+1 Francesco's point..."
yes
00:32:23
Barnabas:Replying to "+1 Francesco's point..."
currently you can send a single tx with 9 blobs in electra
00:32:40
potuz:Replying to "+1 Francesco's point..."
I'd say even less, but yes 6 is fine, and I asked a few for 3 and they seemed fine as well.
00:32:40
Tim Beiko:I personally would lean towards the simplest possible solution (hardcode at 6 or 9 and only change in “real” forks)
00:32:43
Barnabas:Replying to "+1 Francesco's point..."
clients would need to impl logic to kick out invalid txs at fork transition
00:33:14
Ansgar Dietrichs:Replying to "Do 48. 256 KiB w/h m..."
that also means the index is not necessary for existing contracts btw, because they are all guaranteed to be 24kb or less. so can start the index for only new contracts above 24kb after the fork
00:33:29
Gabriel Trintinalia | Besu:Replying to "I personally would l..."
No objections to this
00:34:04
Francesco:Replying to "+1 Francesco's point..."
@potuz I am not sure that reducing so much would be fine if a rollup needed many more txs per slot, because you have to navigate the mempool rules around queuing up multiple blob txs, which are more strict
00:34:07
potuz:Replying to "+1 Francesco's point..."
There's no need for this as you check for inclusion at packing, and those txs will have to be anyway bumped by the rollups that sent them. Eventually they'll be pruned even if no one bumps them
00:34:09
Marius:Replying to "I personally would l..."
Yep this
00:34:19
Justin Florentine (Besu):Replying to "I personally would l..."
same yep
00:34:32
potuz:Base doesn't care, Arbitrum does
00:34:35
draganrakita:Replying to "Do 48. 256 KiB w/h m..."
Yes, and we will leverage that. By making a optional account field we don’t need to touch older accounts.
00:34:35
terence:I dont think anyone posts more than 6 blobs per tx today right? I quickly scanned through blobscan. I will check dune now
00:34:41
potuz:Rollups that actually have contract logic do care
00:34:50
potuz:Base posts to an EOA I believe
00:35:00
terence:I think all the op stack chains post to an EOA
00:35:55
potuz:there's no limit now
00:36:04
spencer-tb:It’s not specified by tx on the EIP. Only block
00:36:17
Gabriel Trintinalia | Besu:for the same reason we should remove baseFeeUpdateFraction from bpo, and have only target and max
00:36:50
Tim Beiko:Replying to "I personally would l..."
I would support that too!
00:36:59
Barnabas:is that a big deal to add verification for this?
00:37:13
Luis Pinto | Besu:Replying to "Do 48. 256 KiB w/h m..."
I don’t even get the basis for charging cold/warm for code size. Some clients pull it with the account so it’s not async computed in extcodesize. Today the cost of loading code and code size is “hidden” in account loading costs. But I can live with extra charge for code size access
00:37:15
Ansgar Dietrichs:I feel like this should be time boxed. we already made a decision on this 2 weeks ago, it’s not obvious that there is a real need to fully have this discussion again now
00:38:00
Barnabas:issue was that nobody made the change
00:38:03
potuz:Replying to "+1 Francesco's point..."
Oh I was replying to @Barnabas, yes @Francesco I agree, this I know used to be a major pain point for Arbitrum's batch poster. I expect this to become worse again with Fusaka when we increase the blob trhroughput to the point the mempool has to start sharding
00:38:31
Ansgar Dietrichs:we can also choose to do more than 6 as the hard coded limit, if people prefer that as a compromise
00:38:36
Ansgar Dietrichs:Replying to "we can also choose t..."
9 or whatever
00:39:21
Łukasz Rozmej:@FLCL just preferes limits in BPO ;)
00:39:35
Barnabas:Replying to "@FLCL just preferes ..."
and now he is being made to remove it lol
00:40:19
draganrakita:Replying to "Do 48. 256 KiB w/h m..."
@Luis Pinto | Besu I do agree with this (and for reth is overhead), but nethermind expressed concern about this, and it is always better to be extra cautious.
00:40:33
Barnabas:yes!
00:40:38
Gabriel Trintinalia | Besu:yes yes
00:40:42
Parithosh Jayanthi:Is there some reason to remove the feature when we already have it?
00:40:48
Francesco:Replying to "+1 Francesco's point..."
I think it’s the main argument for 9…
00:40:54
Ansgar Dietrichs:wait where is that specified?
00:41:02
Parithosh Jayanthi:Replying to "wait where is that s..."
In the BPO config
00:41:03
Barnabas:in blob schedule
00:41:04
Tim Beiko:Replying to "wait where is that s..."
https://eips.ethereum.org/EIPS/eip-7892#execution-layer-configuration
00:41:24
Ansgar Dietrichs:Replying to "wait where is that s..."
and where would be the alternative specification that would make it programmatic?
00:41:44
Justin Florentine (Besu):new client norm: configs for users, other configs for pandas
00:44:06
Marius:Yes, make it as explicit as possible
00:44:34
Tim Beiko:https://github.com/ethereum/pm/issues/1601#issuecomment-3031588014
00:45:03
Tim Beiko:https://docs.google.com/presentation/d/1mpW32f8xEWoxQBtatPdx06AFJCbOJRXC4-f26Zlk_s8/edit?slide=id.g2e0b483c83e_0_0#slide=id.g2e0b483c83e_0_0
00:46:19
Tim Beiko:Who would be most affected if we 3x the ModExp gas price?
00:47:18
Ansgar Dietrichs:tripling in this case does seem reasonable, but I think we should generally not make these decisions based on “there is a // 3 in the spec that is easy to remove”. if the metrics were to indicate x2 or x2.5, we should do that instead
00:47:21
Luis Pinto | Besu:+1 on lib diversity
00:48:00
Marius:Replying to "Who would be most af..."
The problem rn is that dune seems to have a bug and we can't get great numbers from them
00:49:08
Marius:Replying to "Who would be most af..."
Pwel said ecc
00:49:08
Ansgar Dietrichs:Replying to "tripling in this cas..."
but generally agree that we should raise it and accept affecting all precompile users.
00:49:10
Łukasz Rozmej:Replying to "tripling in this cas..."
So qeustion is do we want to reprice it again soon? Otherwise what is the target we want to go?
00:49:18
Marius:Replying to "Who would be most af..."
https://etherscan.io/address/0x0000000000000000000000000000000000000005/advanced#internaltx
00:49:35
Sophia Gold:gmp is effectively load bearing for a lot of computing. It's so commonly used I don't think it's a big deal for all clients to depend on it
00:49:58
Ansgar Dietrichs:Replying to "tripling in this cas..."
x3 in this case is probably reasonable. I would be fine with any value that makes us confident it won’t be a bottleneck before Glamsterdam
00:50:00
iPhone:Replying to "Who would be most af…"
What’s ecc?
00:50:20
iPhone:Probably people using RSA for 8192 bits?
00:50:22
Marius:Replying to "Who would be most af..."
Matter Labs
00:50:29
Łukasz Rozmej:Replying to "tripling in this cas..."
with 3x we could go over 200Mgas (without slot restructurization)
00:50:55
iPhone:Replying to "Probably people usin…"
I’m not convinced that there are a lot of people doing this though
00:51:03
Ansgar Dietrichs:what’s the devnet-3 timeline, are we certain we will have another acde before its launch?
00:51:09
Parithosh Jayanthi:Can we make a plan as to who is investigating what?
00:51:12
Parithosh Jayanthi:i.e what are open questions?
00:51:17
iPhone:Replying to "Who would be most af…"
Can we ask why they are using it?
00:51:25
iPhone:Replying to "Who would be most af…"
And what bit sizes?
00:51:30
Marius:Replying to "Who would be most af..."
Coinbase Smart wallet
00:51:58
Ansgar Dietrichs:Replying to "tripling in this cas..."
right, let’s do 3x then I’d say
00:52:06
Ansgar Dietrichs:Replying to "tripling in this cas..."
we can always make it cheaper again in Glamsterdam
00:52:33
Marius:Replying to "Who would be most af..."
Eigenda avs
00:52:47
Marius:Replying to "Who would be most af..."
I don't think any of these will break
00:53:04
Marius:Replying to "Who would be most af..."
But they might be a bit more expensive
00:53:23
Marius:Replying to "Who would be most af..."
I think it will be negligble
00:53:30
Justin Florentine (Besu):Replying to "Who would be most af..."
i'm fully ok with breaking a business instead of breaking the network 🙂
00:53:35
Ansgar Dietrichs:do we know what portion of their overall gas these people spend on this precompile? I would guess it’s a super small fraction. can’t imagine a 3x price is a major hit for them
00:53:36
Francesco:Replying to "Who would be most af..."
They will also benefit from gas limit increases like everyone else
00:54:02
Barnabas:main modexp user not gonna say: “sure increase the cost”
00:54:32
Tim Beiko:Replying to "main modexp user not..."
Well if we tell them that’s the blocker to 100M gas, they very well might!
00:54:42
Tim Beiko:Replying to "main modexp user not..."
Eigen, Coinbase and Matter Labs all want a higher gas limit 😄
00:54:54
Daniel Lehrner (Besu):Replying to "Who would be most af..."
We can’t expect people to deploy immutable contracts when we break those afterwards. Breaking existing contracts should only ever be a last resort against attacks.
00:55:06
Toni Wahrstätter:Replying to "Who would be most af..."
I did an analysis here:
https://github.com/nerolation/eth-7883-analysis/blob/master/eip7883_comprehensive_analysis.md
00:55:27
Francesco:Replying to "main modexp user not..."
Yeah, I doubt even the biggest modexp user uses it enough for the downside of higher modexp gas cost to outweigh the upside of gas being cheaper in general
00:55:57
Ahmad Bitar | Nethermind:Unless we have at least 3 different implementations, having less than 3 wont be beneficial
00:56:43
Tim Beiko:We can agree to 3x the gas cost for devnet-3 today and worst case walk it back if ther are major issues from that
00:59:36
Ansgar Dietrichs:The downside here is super asymmetric:
if we raise cost 3x, we slightly inconvenience a small % of users
if we don't raise cost, we risk not being able to deliver meaningful extra throughput to all users of the chain
seems like a super clear cut case, even if we are unsure whether that 3x price is necessary
01:00:15
Felix (geth):again
01:00:24
Ansgar Dietrichs:Replying to "The downside here is..."
so “making sure we need it” should not even be a priority here - a plausible chance we need it is good enough for this decision
01:01:13
Marius:We've been fuzzing gnark for a few years now, I feel pretty comfortable with it. The issue we found was just in marshaling code
01:01:23
Justin Florentine (Besu):Replying to "The downside here is..."
this reasoning sounds objectively neutral to me
01:01:38
jochem-brouwer:Antwoord verzenden naar "The downside here ..."
Also regarding repricing, just a thought, if these gas limits are hardcoded then people could indeed state things break, but this could thus also be used to take this gas pricing "hostage". I think it is clear gas prices might change and we should ship the rather aggressive 3x so we can raise the general gas limit (indeed for all users)
01:02:26
Francesco:+1, clearly we’re anyway nearing the end of gas limits being able to be hardcoded and expecting they won’t break
01:02:41
spencer-tb:For 7918, during the last ACDE, I think we agreed on changing the BLOB_BASE_COST from 2**14 to 2**13 for devnet-3. Is this still the case, we need a PR?
I think there was also 7951 repricing considerations for devnet-3 too. Is this still the case?
01:03:20
potuz:Replying to "Unless we have at le..."
client diversity always requires at least 2 to hopefully avoid finalizing a bad block and at least 4 not 3 to avoid one client stoping finalization.
01:03:20
Francesco:I can do it 😄
01:03:52
Gabriel Trintinalia | Besu:which one?
01:03:58
Tim Beiko:https://eips.ethereum.org/EIPS/eip-7951
01:04:13
Gabriel Trintinalia | Besu:I thought we would double the price?
01:04:51
Ansgar Dietrichs:if we don’t have more data on this, we should just 2x
01:05:04
Ansgar Dietrichs:Replying to "if we don’t have mor..."
again, better safe than sorry
01:05:41
Ansgar Dietrichs:we can aim to have all these prices more precise and with less safety buffer in Glamsterdam
01:06:21
nixo:nope
01:06:39
Som | Erigon:Replying to "We've been fuzzing g..."
It's assuring, but not enough, i think, I am no auditor myself. We need an audit sponsored by EF :P I am happy to proceed after that
01:07:01
Justin Florentine (Besu):1 month was my instinct too
01:07:11
Łukasz Rozmej:IMO too many headliners already proposed
01:07:12
Ansgar Dietrichs:I think it’s fine to extend the decision (not proposal!) deadline.
Always good to have the original plan around fastest possible Fusaka, but clearly we are not on track for that
01:07:25
Łukasz Rozmej:now it is just the art of trimming
01:07:30
Tim Beiko:Replying to "IMO too many headlin..."
Wait for all the other EIPs!
01:07:35
potuz:Replying to "We've been fuzzing g..."
We have at least 5 different clients using an unaudited crypto library for hashing 😅
01:07:45
Łukasz Rozmej:Replying to "IMO too many headlin..."
TooManyEIPsException
01:07:54
nixo:rather than 1 month, think we should aim for some equal # of ACDEs and ACDCs?
01:08:06
potuz:Replying to "We've been fuzzing g..."
which was only fuzzed by the EF for a couple of hours
01:08:14
Ansgar Dietrichs:if we think next call is still about devnet-3, then we probably need 2 calls after that tbh
01:08:17
jochem-brouwer:What about EIPs which are not proposed as headliner but as extras? How does this process work?
01:08:26
Parithosh Jayanthi:Replying to "We've been fuzzing g..."
The hash tree one?
01:08:39
Sophia Gold:We should make sure there's time to draw in attention from outside just core devs and researchers
01:08:48
Justin Florentine (Besu):great idea, i think 2-3 calls per layer feels right. should also do some impromptu breakout rooms
01:09:31
nixo:maybe a good time to mention that Marc & I have been working on https://forkcast.org/upgrade/glamsterdam as a resource to compare across headliners. Would love feedback on things people might find useful
01:09:37
Francesco:Replying to "We should make sure ..."
Also from core devs and researchers 😅
01:09:38
potuz:Replying to "We've been fuzzing g..."
yep, it's used by us, caplin, Lodestar, Teku, Nimbus
01:09:51
Ameziane Hamlat:Just to be sure related to ModExp, we’re taking about 3X on top of https://eips.ethereum.org/EIPS/eip-7883 , correct ?
01:09:56
Ansgar Dietrichs:“these 2 calls” can you clarify, does that include the next call already?
01:10:05
Tim Beiko:Replying to "“these 2 calls” can ..."
It does not
01:10:37
Ansgar Dietrichs:sounds like a good plan.
01:11:09
jochem-brouwer:forkcast... this name is genius 😍
01:12:10
Som | Erigon:Replying to "We've been fuzzing g..."
I fuzzed and didn't find a pre image of a hash doesn't make the hash a good one
01:12:22
Tim Beiko:https://github.com/ethereum/EIPs/pull/9970
01:12:31
Tim Beiko:https://github.com/ethereum/EIPs/pull/9970
01:12:47
Ansgar Dietrichs:I think it’s fine to not be super strict about general EIP discussion though, they can already be relevant for headliner discussion.
fine to say we only make decisions once headliner(s) is locked in, but discussion should be possible
01:12:48
jochem-brouwer:Just for clarity is there a PFI deadline already?
01:13:03
potuz:Replying to "We've been fuzzing g..."
yeah, agreed, but the point remains, that using unaudited crypto libraries across Ethereum is something that has already sailed
01:13:44
potuz:Replying to "We've been fuzzing g..."
at any rate, fuzzed and did a differential fuzzing against established libraries does make the hash good
01:14:06
Justin Florentine (Besu):Glamsterdam PFI deadline was june 20, right?
01:14:14
Ansgar Dietrichs:Replying to "Glamsterdam PFI dead..."
just for headliners
01:14:19
Tim Beiko:https://github.com/ethereum/EIPs/pull/9970/files
01:14:26
Justin Florentine (Besu):Replying to "Glamsterdam PFI dead..."
ahhhhhh LFG then bring 'em on
01:14:26
potuz:Replying to "Glamsterdam PFI dead..."
^^
01:14:35
Ansgar Dietrichs:Replying to "Glamsterdam PFI dead..."
general EIPs will still have 2-3 months I’d expect
01:15:05
Ben Adams:Replying to "Glamsterdam PFI dead..."
Denied for headliners become smaller EIPs ;)
01:15:11
Ansgar Dietrichs:do we want to set some preliminary general PFI deadline for Glamsterdam already? can always extend it a bit, but just to give people a heads up
01:15:28
Justin Florentine (Besu):Replying to "Glamsterdam PFI dead..."
see, thats how we get EOF back in
01:15:36
Ansgar Dietrichs:Replying to "do we want to set so..."
could set it to 2 months from now initially
01:15:39
potuz:Replying to "Glamsterdam PFI dead..."
Changing the slot time is just a constant change in the spec :)
01:15:44
Łukasz Rozmej:Can we choose multiple headliners?
01:15:57
Ansgar Dietrichs:Replying to "Can we choose multip..."
there are no rules, we can do anything
01:16:04
Justin Florentine (Besu):Replying to "Glamsterdam PFI dead..."
not sure which joke is scarier tbh
01:16:26
Barnabas:“quick small fork” 😂
01:16:41
Barnabas:can we do a nice big fork?
01:16:42
Ansgar Dietrichs:fwiw I think one headliner for CL and EL each is fine
01:16:43
Justin Florentine (Besu):1 for the EL, 1 for the CL?
01:16:45
jochem-brouwer:big el fork? :)
01:16:55
potuz:Replying to "Can we choose multip..."
We can rewrite the EIP to include two in one
01:17:12
Ahmad Bitar | Nethermind:One headliner for el and one for cl?
01:17:15
potuz:Replying to "Can we choose multip..."
I'm happy to add FOCIL to ePBS
01:17:16
Ansgar Dietrichs:Replying to "fwiw I think one hea..."
ePBS or shorter slots for CL, BALs for EL
01:17:18
Justin Florentine (Besu):so suggesting ePBS + BAL won't get me banned?
01:17:33
Ansgar Dietrichs:Replying to "so suggesting ePBS +..."
not from my heart
01:17:42
Tim Beiko:https://hackmd.io/pIZlxnitSciV5wUgW6W20w
01:17:46
Ben Adams:Replying to "so suggesting ePBS +..."
BAL is a small EIP ;)
01:17:50
lightclient:https://hackmd.io/@matt/eraE/edit
01:17:54
Barnabas:Replying to "so suggesting ePBS +..."
epbs + focil + bal + gas to 200M 😄
01:17:56
Som | Erigon:Replying to "We've been fuzzing g..."
It's assuring, yes, if that's okay enough. Because gnark screams that it's not "fully audited". The last audit was years ago and maybe some smart contract wallet depends on it.
Releasing it would be the "test on prod" auditing. But I can proceed if Geth does it
01:18:10
Justin Florentine (Besu):Replying to "so suggesting ePBS +..."
don't tempt me i really want focil
01:18:12
Ahmad Bitar | Nethermind:ePBS for cl and EOF for el ;)
01:18:31
Ansgar Dietrichs:Replying to "so suggesting ePBS +..."
I personally think focil in H-star is fine, if we manage to ship that in H2 2026
01:18:51
Som | Erigon:Glamsterdam: The Big Beautiful fork
01:19:10
potuz:Replying to "so suggesting ePBS +..."
it'd be great if we get EL folks to gauge the invasiveness of EL EIPs... doesn't need to be here, it can be on private messages for me lol, but I want to know which ones are actually invasive. PureETH didn't look so invasive to me, and then Cayman told me it was
01:19:16
Łukasz Rozmej:Replying to "Can we choose multip..."
BAL+ePBS+FOCIL!
01:20:02
Storm Slivkoff:are the receipts optional?
01:20:23
Gabriel Trintinalia | Besu:Replying to "so suggesting ePBS +..."
can you define invasiveness of EL EIPs
01:20:34
potuz:Replying to "so suggesting ePBS +..."
@Ansgar Dietrichs The one reason I propose FOCIL+ePBS is that I believe shorter slot times cannot be done in the same fork as FOCIL, and if we don't include FOCIL and shorter slots in the G fork, then surely people will want shorter slot times in the H fork and that will delegate FOCIL for later. By the way, the same argument to have ePBS before shorter slot times I think applies for FOCIL
01:20:59
potuz:Replying to "so suggesting ePBS +..."
@Gabriel Trintinalia | Besu Invasive as in it needs substantial changes to critical parts of code
01:21:23
nixo:Replying to "Can we choose multip..."
i dunno how serious you all are but isn’t the point of the headliner format to reduce the complexity and scope of a fork?
01:21:30
thomasthiery:Replying to "so suggesting ePBS +..."
I agree, I’ve heard multiple times that shorter slot times wouldn’t practically be combined with any other EIP basically
01:21:52
Ansgar Dietrichs:Replying to "so suggesting ePBS +..."
@potuz that's a reasonable argument, I'd be open to considering ePBS + FOCIL as a package, but it does seem quite heavy
01:22:08
potuz:Replying to "Can we choose multip..."
FOCIL I think it's special: 7547 was included originally on ePBS and we removed inclusion lists only to make it so that ePBS doesn't touch the EL. IMO they should both be the same EIP
01:22:09
Francesco:Replying to "so suggesting ePBS +..."
Seems pretty crazy to me 😅
01:22:20
Ahmad Bitar | Nethermind:Replying to "Can we choose multip..."
@nixo i guess you are new here :p
01:22:33
Barnabas:why do we have so many era formats?
Cant we just have one to rule them all?
01:22:39
Justin Florentine (Besu):Replying to "so suggesting ePBS +..."
ePBS, FOCIL, BAL seems like it adds up to 1.5 headliners per layer
01:22:50
Kev:Replying to "why do we have so ma…"
Just one more
01:23:19
Barnabas:Why can’t we just keep iterating without making a whole new name?
01:23:38
nixo:Replying to "Can we choose multip..."
y’all are just too collaborative and wanna include everybody’s thing
01:23:45
Tim Beiko:era1.1
01:23:50
Barnabas:just call it era
01:23:53
potuz:Replying to "so suggesting ePBS +..."
@Francesco yeah,it's scary, but to me it seems scarier to face the shorter-slot EIP eventually without having force inclusion
01:24:03
lightclient:that name is taken lol
01:24:07
Storm Slivkoff:not sure that everyone would want receipts
01:24:09
jochem-brouwer:its time for a new era
01:24:11
Barnabé Monnot:Replying to "so suggesting ePBS +..."
oh this is the comment box where we pitch our favourites? then 6s slots for 6lamsterdam 🙂 and BAL for EL
01:24:56
Barnabé Monnot:Replying to "so suggesting ePBS +..."
@potuz what do you mean? shorter slots gives twice the CR, how does this mean that force inclusion is required?
01:25:25
potuz:Replying to "Can we choose multip..."
differently than Pectra, these are really major things that we all want anyway, I think every one of us want better slot pipelining, forced inclusion and censor resistance and shorter slot times. I do not think we are trying to include things because of including others peoples EIPs, these three are major objectives that we do want. Unfortunately we can't all at the same time
01:26:09
Gabriel Trintinalia | Besu:Besu has enabled it by default on its new release for new snap nodes
01:26:56
potuz:Replying to "so suggesting ePBS +..."
\sim \infty \gg 2
01:27:24
Marc:Nethermind ready to drop history
01:27:33
Roman:checking with the team, but we should support it
01:27:58
Gabriel Trintinalia | Besu:Besu last release also increased to 45M by default
01:28:07
potuz:Replying to "so suggesting ePBS +..."
I think shorter slot times will kick out a lot of nodes (even Fusaka does) like CSM operators like myself. I believe these EIPs do explicitly affect negatively CR
01:28:24
Barnabé Monnot:Replying to "so suggesting ePBS +..."
2 > 1 ;)
01:28:59
Barnabé Monnot:Replying to "so suggesting ePBS +..."
@potuz the goal is obviously not to do it in a way that kicks out nodes
01:29:22
Ahmad Bitar | Nethermind:Replying to "so suggesting ePBS +..."
Cant do that qithout pipelining
01:29:25
Kev:Replying to "so suggesting ePBS +…"
6lamsterdam — I see what you did there @Barnabé Monnot