Mario Vega:Awesome. Thank you so much. Yeah. Welcome everybody to acdt number 45. Today's July 21, st
Transcript
Mario Vega:we have a couple of items in the agenda. And 1st of all, as always, Fussaka updates, is the 1st thing to to address.
Mario Vega:I think definite 3 has not gone. Live at this point. But we can start with.
Mario Vega:there was an East release. So I think we can start with that. If that's okay. Spencer, are you?
Mario Vega:Yeah, Spencer, do you want to give an update on the East release?
spencer-tb:Yeah, sure. So and we released a yeah, a feature release.
spencer-tb:And for devnet free just last Friday.
spencer-tb:And basically the changes within the release include updates to the gas prices of and the modex
spencer-tb:and the curve Clz, which I guess we'll chat about later.
spencer-tb:and the blog base fee cost change for eip, 7, 9, 1, 8, and
spencer-tb:the transaction gas limit reduction for Eip 7, 8, 2, 5,
spencer-tb:and the release also includes new tests for the Max blob per tx limit, added to the pure daft IP,
spencer-tb:and and also removes all the tests for Eip 7, 9 0, 7. Yeah, I guess
spencer-tb:we might have another release based on the end of this call. But yeah, let's see, let's see
Mario Vega:Thank you. Thank you. On the Dominitory side. I don't see one of us
Mario Vega:in the call parry. Do you know if there's any updates? Yeah.
Parithosh Jayanthi:Yeah. So there's mainly 2 things left we do have a Pr from Spencer for testing hive. So as soon as have a branch for us. Ideally. The branch name is Fusapnet 3 it should pick up all the images, and we should have hive tests running kurtosis should be running as well. I'll PIN a version that people can test out, but we haven't received client images from all the clients yet.
Parithosh Jayanthi:And there are 2. Main, yeah, 2 main prs that still need to be like, we need to sort out ideally today. The 1st one is on the builder specs, and the second one is on engine. Get blob. C. 3.
Parithosh Jayanthi:I think those are the main points for devnet 3. If all of this is true. As soon as we have client images, we're ready to launch ideally in 2 to 3 days.
Parithosh Jayanthi:So before Acde.
Mario Vega:Awesome great. Regarding the builder specs. There was comment.
Mario Vega:That was made by Bharat, I think, is that is that relevant to the discussion. I'm not sure if
Mario Vega:if if they are in this call.
Mario Vega:but we can touch upon that topic later. If that's okay or do you want to go now?
Parithosh Jayanthi:Wherever, wherever you want to schedule it.
Mario Vega:Alright. Cool, cool. Okay. Thank you.
Mario Vega:Anything else regarding Fussaka, or then the 3 house clients implementations coming along. Does anybody any anybody from any client team wants going to give an update
Mario Vega:best who is ready pending. Get blocked between.
Mario Vega:Get is also ready except except for the config endpoint. Red has a branch.
Mario Vega:Get underscore, config and get blobs between.
Mario Vega:Aragon is also ready without get blob. Cp. 3
Mario Vega:lighthouse is ready. But coming back to yield clients. Anyone anybody from? Never mind here that wants to give an update.
Mario Vega:Never mind, Brady. Okay.
Mario Vega:Cool.
Mario Vega:Lighthouse ready. Okay? And anyone from the rest of the cl clients who wants to give an update on readiness.
Mario Vega:Anybody from from Teku
Mario Vega:and Justin made the comment that there's not that many changes, for fuzeka losar is ready. Okay.
Mario Vega:just missing. Builder. Api. Okay, thank you.
Mario Vega:Alright. It seems like, I also granting is ready. Okay, it seems like most clients are ready, and
Mario Vega:it's looking good. I think there should be any blockers for the next 2 weeks.
Mario Vega:Sorry the next 2 days.
Mario Vega:Alright cool.
Mario Vega:Next topic is gas limit testing updates Barry for this. Do you know who the person with context is?
Parithosh Jayanthi:Yeah, I can go here. So one of the I guess biggest updates is that we've been. We've had all the client releases made for 45 million or most of the client releases made for 45 million.
Parithosh Jayanthi:And enough validators have updated that roughly. A few minutes ago we had the 1st 45 million gas limit blocks on Mainnet. So congratulations everyone that's definitely good news.
Parithosh Jayanthi:That being said over the weekend we were working on puff devnet 2. And we had this one weird issue with Bezu, where the image with the wrong MoD X. Pricing got pushed onto the performance tag. And as a result, we've had non finality for the last one or 2 days. The issues core issues, mostly a config mistake.
Parithosh Jayanthi:But we're still trying to sync up bezoo and figure and just ensure that it isn't anything else. And in the meantime we are working on getting finality back up there.
Parithosh Jayanthi:Other than this. There's been a couple of other work streams. So we have a new sync testing tool. It's called syncor. And the 1st run of syncs of all the nodes are going on now. So in the next couple of days we should have a good baseline metric. For how long it takes to sync.
Parithosh Jayanthi:There's been a lot of work by Carlos from the stateless team to try and get us all the metrics we want with the State plot network. So puff devnet 2 is almost at 2 x mainnet state as well. So we should be able to run the sync or tool against it and get sync information for 2 X Mainnet State. We have a new Rpc testing tool as well.
Parithosh Jayanthi:and Rpc testing tool just is so far a proof of concept. We're gonna start reaching out to
Parithosh Jayanthi:node operators to try and get a sense of what workloads they have so that we can benchmark them against all the clients, and then make a preliminary report, for this is how clients perform at 36, or well at 45 million and then we should have stronger Rpc benchmarks as well for the future.
Parithosh Jayanthi:I think that's everything on the gas limit side. Maybe Camille has something else to add.
Kamil Chodoła:Yeah. In meantime, we are working on extended gas benchmarks, opcodes, benchmarks.
Kamil Chodoła:For now we focus quite a lot on all modex because of some additional repricing which were made, and to ensure that it is fine. But yeah, this is like, from benchmarking point of view, it's almost accomplished, and we are moving all of our sources now to
Kamil Chodoła:all of our forces, now to stateful testing, which is like unexplored ground right now, where we had a Johan with who made some tests on Perfnet. But we want to make it fully reproducible in the same way as we do with Opcodes
Kamil Chodoła:already in contact with his team. We had a very nice discussion last week, and right now we are trying to summarize that with, together with Martin from our team to to make a document on how? How the full integration of of opcodes benchmarking with Es should work moving forward.
Kamil Chodoła:And what is the end goal for that we have some ideas. We want to test as much as possible right now on top of Mainnet, or even Bloatnet State.
Kamil Chodoła:And yeah, this is like current goal. And hopefully, next few weeks we'll have much more extensive tests, which will give us much more insights from from this point of view, because computational side seems like is already quite well covered. So we can focus on something which will bring much more value. And then we'll start exploring more edge cases.
Mario Vega:Thank you. Marcian.
Marcin Sobczak:I would just like to say that Tony prepared
Marcin Sobczak:about modex changes and network impact. So just based in on the chat. There is nothing surprising like after free xing the price, 100% of calls are affected but there are like great insights on the chat so and take a look.
Mario Vega:Thank you.
Mario Vega:Alright. I think there was a question regarding the get blocks. B, 3. Readiness.
Mario Vega:But before that I think it's just a nice
Mario Vega:that. We discussed blotnet. I think there was one person that wanted to discuss this. I think it's a good place to start discussing that C. Peris. Are you in the call?
CPerezz:Yep.
Mario Vega:Do you want? All right? Yeah, yes. Let's let's yeah.
CPerezz:Sure. Yeah. So I I'll be very quick. We are approaching 2 x main net state in Blobnet. And ideally, we want to rerun syncing tests. And we want to start also trying to run compaction testing to see how much we can stress
CPerezz:adding and removing state. And how does it play with compaction? In order to be sure, we can reach 100 million gas limit safely. And for that we needed some metrics implemented by teams. So far, I'm gonna comment. The ones that we are missing or for the things that we haven't heard such that maybe they can get this ping and and they can update or or give us some some feedback.
CPerezz:From syncing we are missing any information from Besu and Aragon.
CPerezz:And from never mind, I know they are reporting healing from blocks not in Grafana, and wanted to basically know if there's any way to get that from Grafana, as getting data from from blocks is
CPerezz:a lot harder and requires a lot more integration for for the tooling that I mean, we would prefer to not spend the time on so maybe Camille or Ben can say something about
CPerezz:never mind. And maybe there's someone from baseline that can basically say anything about their metrics.
Kamil Chodoła:From that reminder. I think that this should not be a huge thing to to add a metric for healing, so we'll try to push for for that metric.
CPerezz:Opia. Thank you.
CPerezz:A 1 million.
milen | Erigon:Yeah. So I responded, last week, and I've added all the metrics for Aragon. So they're in the Grafana
milen | Erigon:already.
CPerezz:Okay.
milen | Erigon:Including including including Syncing.
CPerezz:Compaction, tool.
milen | Erigon:We don't really have this concept of.
CPerezz:Okay. Fair. Enough. Yeah.
milen | Erigon:We have the metrics that are analogous to that.
milen | Erigon:Yeah.
CPerezz:Okay. Awesome. Thank you.
milen | Erigon:And actually, yeah, they've been quite helpful already. I think we've spotted a few issues. So
milen | Erigon:this, this effort is quite useful.
CPerezz:Thank you. Don't want to be so insisting. But if at some point you reach some conclusions on the issues you saw, please reach out such that we can lock all of them.
milen | Erigon:Yeah, we're we're still looking into it. But I will definitely update you with like a summary. Once we figure out what's happening.
CPerezz:Thank you.
milen | Erigon:Yeah. No worries.
Mario Vega:Machine.
Ameziane Hamlat:Yeah, thanks. On pesos side, we do have the matrix on sync.
Ameziane Hamlat:but it seems they are like removed when we start the node. So we need to check our implementation, to be sure that the metrics are are persisted, because I see we have them on few nodes, and we don't have them on other nodes. So we need to. We need to double check. We do have some metrics on compaction.
Ameziane Hamlat:But
Ameziane Hamlat:so so what's the the kind of metric we are looking on compaction. Is it like the the impact in terms of time, or in terms of.
CPerezz:Yeah, I just send a link to a Hackmd which basically has the summary I will update on now. But for a quick description in compaction. We need to start and end time. And we want also to get I/O performance when we are and when we are not in compaction especially best, worst and average. Read and write times for each block for every
CPerezz:operation that basically removes or stores stuff into interstate into the dream. So insertion, removal type basically.
Ameziane Hamlat:Okay, yeah. So start and time compaction. We we do have them. But we have them like under a set of set of metrics that we we don't usually enable, because they have some overhead like a lot of metrics. So we need maybe just extract that one outside, like the the set of those metrics. And and we'll double check the the rest of the matrix, and we'll update.
CPerezz:Awesome. I'll get in touch offline to to follow up. Thank you very much.
CPerezz:That should be it for, blonded Mario.
Mario Vega:Alright. Thank you.
Parithosh Jayanthi:Mention if clients could. Please make sure that all the metrics changes are pushed to the performance branch, because that's what we're running on the block net.
Mario Vega:Thank you. Awesome. Yeah. Going back to the get. Blob. dB, 3. I see role. Do you want to add some context to this question?
Raúl Kripalani:Yeah. I think in in general like this, Els have most of them have implemented the the Api sales have nothing to do here, and in general, I'm seeing some favorable reactions in the chat to just merging the spec change so that Els can merge their implementation branches and move on. I think that's what I would propose, and we can close this topic.
Mario Vega:I see Dustin the main counterpoint. Do you want to, Dustin? Do you want to expand on this in any way?
Dustin:Sure. Yeah,
Dustin:So
Dustin:I understand. And I agree, very based on, you know, as as best as I understand where this is going that get Bob 3 3 is is ultimately something like it is ultimately probably what we want.
Dustin:What I fundamentally disagree about is entwining this with the Fusaka fork, because essentially, as I have have written, but obviously this is a weirdly threaded environment. So I'll summarize here and to say, like the Els can can merge what they want, and it's and it's and it's great. I I hope
Dustin:that if we that that at some point the Els do, if we are moving in this direction, do merge such such a Pr.
Dustin:Where I I would distinguish here, though, is that
Dustin:treating it as part of Fusaka, it is effectively, not from my perspective, if it's not been tested in a very similar way as the rest. And we have recent experience with, you know, simple seeming things that were not tested.
Dustin:and they didn't go very well.
Dustin:And so
Dustin:that that that's sort of the the gap or gulf here for me is the idea. Can I just shove this last minute thing in and don't worry about it. It's like we can't rely on that.
Dustin:We, Nimbus can't rely on this. I can't speak for other cls, but like, yeah.
Raúl Kripalani:Yeah, I think the operative point here specifically for me is that we did wanna make sure that while people while peered as and in general, blobs are are in the refactors. There are fresh for people. They just get this particular change in so that we don't have to context, switch it later and
Raúl Kripalani:incurring the coordination overhead, of getting releases of Els out and doing an off cycle engine. Api change, and so on. And and yeah, this this, as as we all know, v. 3,
Raúl Kripalani:is not exercising Fusaka's code part specifically, this is more of kind of like an A. A, I would say, smart way of like trying to offload a context switch from the future, which is gonna be coming so that we can just get this work done when it's a simple thing that it's actually, I agree with you. It's simple.
Raúl Kripalani:I am. I'm not very privy to what happened in in Holeski. I wasn't. I wasn't there at the time. But in this particular, in this particular case we have the guarantee that this path is not gonna be used. And what if in consensus from consensus? So I don't see how it could have an destructive impact?
Raúl Kripalani:But yeah, other than that I would. The the thing that I've proposed is is creating some hive tests so that we can test this separately. Directly with with that test suite.
Mario Vega:Thank you.
Dustin:But okay, okay, so what? What I would, what I would would right like
Dustin:this is why we question, is that kind of, as Marius is just saying in chat is like, there's there's
Dustin:hmm!
Dustin:If it's Glamsterdam, then there's no
Dustin:rush to get into Fusaka by definition, if yeah.
Dustin:But clearly it's not. But clearly it's not right, because otherwise that that this coordination problem would would doesn't really exist. You can coordinate in Amsterdam around Amsterdam
Dustin:so that that either it is not meant to be in Fusaka, and therefore this is a pointless push now, or I mean again, clients can merge what they want, but from a spec perspective, I don't really care deeply what Pr is best you merges, or something like that, I mean, I hope they're good Prs, but like from from like as far as get 3 but in terms of including in a spec or or not what I would.
Dustin:What I do care is is this considered to be part of of Fusaka or not? And what I would argue is that it should not be given that we are running into like the spec freeze and the last devnet.
Dustin:and no testing, and that that to me, just doesn't work
Dustin:like that. We cannot consider anything like that to be part of for soccer as a spec.
Raúl Kripalani:Right.
Raúl Kripalani:I mean the I think the rationale here, and just to kind of like explain for everybody. The the facade slash, glam, stam slash in the middle. Sort of like thing here. That. Yeah, it's this. V. 3 won't be consumed for Fasaka, but we aim to consume it through optimizations and the cl and the cl, and specifically the peer to peer layer before Glamsterdam. So that's what kind of like creates the extra coordination challenge midway.
Raúl Kripalani:And the the bet that we're taking here is that by doing this now we'll remove X-ray for everybody later. And it is done and given that this operation is not consumed in any way.
Raúl Kripalani:Because it is exposed only through the engine. Api. The engine Api is privileged, and it is only consumed by the Cl. If the Cl. Does not consume it, which is agree, it's it's not part of the Fosaka spec for the Cl. So it's not gonna be consuming it. Therefore there is no risk here. Other than possibly the implementation risk
Raúl Kripalani:which is what we are aiming to test by hive tests, and
Raúl Kripalani:I think that is sufficient testing.
Matthew Keil:I I think the thing that's being missed here, though, is that there is risk. And it's from a process perspective. You know, the the biggest issue we had in the last work was, get last thing in, get last thing in. It's not going to get used. It's just a minor change, and I think this sets a precedent of trying to sneak things in under the wire
Matthew Keil:when it's not going to get used. And to speak to Dustin's credit. I mean that that feels like just it. It makes the process messy. And that really is the biggest concern. It's not so much whether it gets used or from a technical perspective. But I think if we want to be able to ship
Matthew Keil:hard forks on regular schedules, and we want to get used to that. This. That's how that's how releases are done, at least on our team. And I know they were done in the web. 2 world is that you have a hard date. Specs get in by that date. If it misses it, it's in the next release. And because there's always going to be this incremental one more thing, and that that to me, is the biggest issue here, not so much the complexity or the
Matthew Keil:how it gets rolled out, or or even the merit of the feature.
Mario Vega:I I absolutely agree. So. I think, this is contentious enough to not be further discussed in this call. I think at the very least. I would defer this discussion to acde
Mario Vega:if we're not sure if we're gonna implement something in in Infozaka. I don't think this is the place to discuss it.
Mario Vega:But yeah, that's my opinion. Pari.
Parithosh Jayanthi:Yeah, maybe to play the contract. Let's say we don't include it right now, and we assume that it's going to go down the approach of get blobs. We want
Parithosh Jayanthi:assuming we have a single el as well as cl implementing this in the future, and we deploy it asynchronously on the network. Would that still work out for us long term? Or would we then be locked until Glamsterdam, before we can actually make use of this feature.
Parithosh Jayanthi:Also note that we have this we have this other concept system. We have a Bpo fork. So there's sort of another sync level between Fusaka and Amsterdam that we never had in the past.
Parithosh Jayanthi:Ideally, we're not making any code changes there, and it's only Bpo. But if let's say, guest as well as lighthouse, make a release with using this feature, and that, would the Bpo fork would imply that every guest and lighthouse node on the network has implemented this feature. Would they then be able to use it? Or is it a useless feature until the whole network uses it.
Raúl Kripalani:Yeah. So from the perspective of the optimization that we're planning, this would be at the Cl level. And basically clients that are supporting the gossip, sub partial messages feature that uses the partial blobs return from the El would be able to
Raúl Kripalani:use this optimized path when reconciling columns with each other. Essentially. So basically, the goal here is to minimize the band superfluous bandwidth usage here by
Raúl Kripalani:that would be incurred by transmitting columns that include cells for blobs that deals already have because they are in the elm pool. And that's the that's the goal here. So basically, this is being shipped as a as an extension, and that extension on the gossip sub level is discovered and then used only if both clients are are supporting it, so this can be shipped.
Raúl Kripalani:As an optimization implementation level optimization that has no potential. That's the way that we planning it. Would be having no or at least envisioning it would be having no spec changes necessary.
Raúl Kripalani:On the on the sales side of things, and the idea was to have the Els ready to support this from from the get go.
Mario Vega:Francesco.
Francesco:Yeah, I just wanted to say that, I think in
Francesco:sure, when he was last week. I don't know. Last Thursday we, he said, and this has been going on for really like a long time, that we would make a final decision today. And I think we should really stick to that like, if we cannot make a decision, then let's just default to not doing it. If we otherwise. Yeah, let's try to make an explicit decision. We don't need to spend all the rest of the ball talking about it, but it would really be good to just end this today. I think.
Parithosh Jayanthi:Yeah, I think if the consideration is on the testing front, we're happy to acknowledge or commit to adding some testing bandwidth from our side to make this happen. I'm guessing the testing teams also. Okay, with that. But yeah, I don't want to speak for the process decision, of course, but if it's purely about testing, and that we agree that no Cl would roll out any change in the future without going through the regular testing process. Then I think we can accommodate that from the testing side.
Mario Vega:Yeah, I mean, we can do it definitely. The problem is that we don't have it exactly now. So I don't know how much is gonna delay. I would I would. I would love
Mario Vega:rather to have this test already for definitery. But that's not the case.
Mario Vega:So yeah, I'm not. I'm not confident.
Mario Vega:we we're gonna have sufficient testing for definitely, in my opinion.
Raúl Kripalani:So just just one more thing to note here the decision ends up being not to include this. Then I think we need a decision on what's gonna happen with the version? That's on master right now, which does introduce a schema change that Cls would need to support which I don't know if they have an implementation change already, for my my understanding is that they they don't.
Mario Vega:Is there a pr. For for this? Do you have a link.
Raúl Kripalani:This is merged in master, but, as far as I know, no Cl has implemented it. So this, this Pr that we're discussing the one that includes gets Bob v. 3 would revert reverts that change on master to the behavior that cl's implement today, and then adds the V 3 endpoint.
Mario Vega:Does any cl have any input on that? Do we know if it's like implemented.
pawan:We haven't implemented it.
Mario Vega:Is that the case for all other Cls.
Matthew Keil:We have not either. We're just using v. 2 as it is.
Manu:Time for prison. We haven't implemented it.
Dustin:Same, for Nimbus have not implemented it.
Matthew Keil:I mean that in and of itself feels like that makes the decision, at least for now.
Matthew Keil:But yeah.
Parithosh Jayanthi:Maybe expanding on Francesco's point. So this would imply that we stick to get blobs v. 2. And we basically don't do anything with get blobs. V. 3. Right now
Parithosh Jayanthi:for a sec.
Parithosh Jayanthi:The right reading.
Mario Vega:That feels like the safest way, and the correct reading at the moment.
Parithosh Jayanthi:Yeah, maybe someone can respond to the message Kapria mentioned as well get blouse. V, 2. Allowing partial responses or not.
Raúl Kripalani:It would be a no, it's an it would be. It would go back to all or nothing. Get block speed 2. Which is prior to merging the Pr. That I just linked in the chat.
Mario Vega:Sounds good. Okay? So then, just to summarize, get balls, be 2 with all or nothing, and it's going to be reverted in, master, and we're going to stick for that
Mario Vega:on devnetary.
Mario Vega:All right.
Mario Vega:Great thanks. Everyone.
Mario Vega:Yeah, I think. The next topic. If that's if that's okay, unless there's any any other opinion.
Mario Vega:Next topic to discussion is a point brought up by Mikhail
Mario Vega:regarding the usage of safe blocking the engine. Api response. Michael, do you want to expand on this.
Mikhail Kalinin:Yeah, thanks. Hi, everyone.
Mikhail Kalinin:I will not go much into the details of the Confirmation rule. It has been already announced before.
Mikhail Kalinin:Just give a brief context. There is a Pr, there is a paper with the Confirmation rule algorithm. There is a Pr open at Pr to the consensus tax which implements this algorithm. And recently, we did work on a slightly modified version of this algorithm, which is
Mikhail Kalinin:more efficient computationally wise and easier to implement.
Mikhail Kalinin:And currently recently, the
Mikhail Kalinin:there is a pro project started a week ago on prototyping this algorithm in lighthouse. So there is a work towards having the Confirmation rule delivered to Mainnet. And
Mikhail Kalinin:One of the things that's we need to decide is how how we will actually provide this confirmed block
Mikhail Kalinin:to to the, to the blockchain data consumers, and historically it was supposed to be
Mikhail Kalinin:the safe block was introduced.
Mikhail Kalinin:and was supposed to be set to something closer to the head that we think that is confirmed. So basically, it was supposed to be set to the confirmed block. But this work.
Mikhail Kalinin:Yes. But
Mikhail Kalinin:there was no actually, the algorithm that would provide this data. And we, we used justified.
Mikhail Kalinin:or some clients use and realize justified block for for the safe one and yeah, should. And and the main question is, should we
Mikhail Kalinin:actually overload the save block and to use it for
Mikhail Kalinin:to pass the confirmed block to it. Or should we introduce a new block tag to engine Api Json or Pcpi
Mikhail Kalinin:which what we use for for the confirmed bulk.
Mikhail Kalinin:So I don't know. Also, the
Mikhail Kalinin:One of the question is
Mikhail Kalinin:obviously block is actually used by data consumers. Can we figure out, can we get this information or not?
Mikhail Kalinin:And maybe it is somehow used by the clients? And yeah, all these questions need to be.
Mikhail Kalinin:all these things need to be considered to make this decision.
Mikhail Kalinin:So yeah, that's that's about it. I don't know if people have any opinion here and
Mikhail Kalinin:and want to express it now, or should we move this discussion to
Mikhail Kalinin:probably discord to some other venue? So much open to your suggestions.
Mario Vega:Thank you. Yes, Terrence, you have an opinion.
terence:Yeah, thanks for the questions. I guess I'll answer a few questions in line. So I think, like, if the concern today is for disparity. The disparity already exists today. Right? Because prison is already passing unrealized. Justify for safe block cash. But I think there are other clients that's passing by justify. So there is this disparity here today.
terence:and then, on the presume side, I have a fast Confirmation branch. I have been testing it since couple of days ago, just because I think there is some renewed interest on fast confirmation.
terence:And what I ended up doing is that I added a client flag on the prism side to allow the node operator to specify whether they want
terence:fast confirmation or unreal is justified or justified, or some future algorithm to be passed as the safe block patch. So this ends up to be a client flag on the prism side that people can use.
terence:and in terms of consumer. I guess I can answer for arbitral micro software just because I have a little idea how it works
terence:they use safe block hash to essentially allow layer to to consume layer, one message. So when when a batch poster post a batch.
terence:or when someone submit a message from layer, one to layer 2, or when layer 2 learns a layer, one block price that delay is essentially the safe block cache. So today's unrealized justify, but with the same block cash they will they? They they should be able to consume the message in the optimistic case in under 30 seconds. So that's 1 use case in terms of
terence:what the plan you say block hashes for prism. We don't use it for anything internally. It's except for passing it to the El, and I cannot answer for the El. So yeah, someone might want to answer. There.
Mikhail Kalinin:Great thanks a lot, Terrence. And you've mentioned that our bedroom use is safe. It means that if we
Mikhail Kalinin:start passing the confirmed block fast confirmed block instead of justified it, could affect their security models right.
terence:Exactly. But that is a note, operate this choice that is basically to be specific, that that is the sequences choice. They have to make right. So there's 1 thing I have been essentially testing is just to make sure there's no reorg. There's some there to accept, reorg. They don't really like reorg and stuff like that. So for them a reorg will be pretty bad. So I've been testing I
terence:I don't want this to be like a I miss a software, but on my end, if there's a reorg that happens. But yes, if there's a reorg, then
terence:the sequence of where we work.
Mario Vega:Thank you. Marius.
Marius van der Wijden:Yeah. So as I, as I kind of wrote in the chat, I think we are significantly underutilizing safehood.
Marius van der Wijden:It should be like the default thing when when people are building applications that are like they don't like need finality, but that can rely on this pseudo finality.
Marius van der Wijden:And I think for that to make safe hat really useful, it should be as as soon as possible.
Marius van der Wijden:And so, as far as I understand this new rule,
Marius van der Wijden:would be much faster than the than the than the justified and so
Marius van der Wijden:I do. I do like the idea of giving the node operator
Marius van der Wijden:control over what the safe head should be depending on on their use case. And yeah. So I I think
Marius van der Wijden:if I would like to CC alls.
Marius van der Wijden:implement this new fast confirmation rule.
Marius van der Wijden:And yeah, I guess from the, it is a mostly Cr only change.
Marius van der Wijden:It doesn't really impact the eo, we will mark
Marius van der Wijden:whatever the Cl. Tells us is safe, we will mark that as safe for for the Rpc, so, yeah.
Mario Vega:Thank you, Miguel. Where do you want to take this conversation? I it sounds like it should be to the execution. Apis a modification. There, at least.
Mario Vega:Do you think opening a Pr would be the proper follow up?
Mario Vega:Or how do you feel.
Mikhail Kalinin:Yeah, it's a good question. If we decide to to reuse safe then basically, as Mario said, it's it's mostly CEO side. It's mostly a kind of
Mikhail Kalinin:all the work. Actually, what would happen on sales side? We don't need to change anything on El
Mikhail Kalinin:if we? If we do make this decision, then probably there's not much to discuss.
Mikhail Kalinin:But if we want to debate at it, I don't know. If we decide? Yeah, yeah, probably.
Mikhail Kalinin:Let's try to follow up and discord on this.
Mikhail Kalinin:I'm mostly interested in. Is there anybody that think that we should not touch safe and change its semantics.
Marius van der Wijden:The only.
Mario Vega:Yeah, no, thank you. Yeah. I'm sorry. Maurice.
Marius van der Wijden:Yeah. The only thing that I can think of is like big Rpc providers.
Marius van der Wijden:Who would like to expose them? That to the users to justify to the users.
Marius van der Wijden:But
Marius van der Wijden:I don't know. I think it would be their decision what to what they will mark as safe then
Marius van der Wijden:and right now, if they run 2 cls.
Marius van der Wijden:there might be a difference between what they mark as safe already, so
Marius van der Wijden:it it could also be flip flopping, depending on the load balancing so. But I think this is for the big Rpc. Providers to figure out.
Mario Vega:Alright. So I think if we can follow up this up on discord, and I think bringing this up to Acd would make definitely make it reach a bigger audience that needs to have a say on this. And opinion.
Mario Vega:does that sound? Okay.
Mikhail Kalinin:Yeah. Sounds good. Sounds good.
Mario Vega:All right. Perfect.
Mario Vega:Yeah, thank you. Yeah. There are 2 topics left. One is the builder. I think there was some discussion in the chat. But Bara was the 1st one to bring it up. Do you want to expand on this.
Bharath:Yeah, I mean, so I think we raised it. There seems to be consensus and client devs on the semantics of the Pr. And on the
Bharath:like under the timing, in the sense like just to give a tld around the Pr. We're introducing new V 2 api in the relay
Bharath:which basically doesn't. Return the execution payload and the blobs right? This is barely for like scaling and network bandwidth. So as we increase the number of blobs, and we're also like different seems to be broadcast on the semantics, that is.
Bharath:the Api returns like a 2, 2, not 2
Bharath:success. If the if the blinded block which is sent is valid, and it publishes the block in an asynchronous fashion. So that's there. So I'm raising it here to 1st of all, understand if there are any concerns about it. Secondly, if there are no concerns we are planning like this probably should be something we can target for like Devnet 3
Bharath:so we're currently implementing that in the flash bots like Mev boost relay. And hopefully, we can get that live for net 3. So and like, hopefully, we can test it with the clients implementing the V 2 Api, so yeah, just putting on the stage like there are any concerns related to that.
Bharath:and stuff.
Mario Vega:Any other context? Pari, do you? Do you have any context on this
Mario Vega:regarding we should like introduce it in Devon tree or not, or I feel like it's like very close to.
stokes:Yeah, I I think we should merge it. There's work underway to have this change in the web stack and everything. And then, yeah. I'll just move forward.
Mario Vega:Okay, thank you.
Mario Vega:Sounds good.
Mario Vega:And yeah, the last 2 topics are,
Mario Vega:I think. Clc, I think that's that's that's 1 of the the last topic, and also the block has 60 million. If we want to touch upon the topic today. So the 1st one is that the Cl set up code was bumped to 5.
Mario Vega:And Rakita, do you have context on the
Mario Vega:if I understand correctly, there's data that shows that it might be unnecessary. But if you want to expand on that.
draganrakita:Yeah, physically, at least in my mind previously. Clc is very similar to any other bitwise operators.
draganrakita:instructions of codes. So it was changed for me. It was bumped to be more similar to the move.
draganrakita:It was bumped from 3 to 5 gas. It's not that big of the deal. We can always reprice it in the next half fork. But
draganrakita:I have created few benchmarks to check that hypothesis, and it seems Clc. Is even.
draganrakita:It deserves even lower gas than tree, so I would like, if to see if clients are open to changing this, to to be back to the tree gas.
draganrakita:I shared those benchmarks inside the okor dev chat in discord.
Mario Vega:Thank you.
Mario Vega:Yeah.
draganrakita:I'm not sure if clients have an appetite for this change.
Mario Vega:Yeah, I think the main problem is that we are very close to
Mario Vega:finalizing. So I don't think a roll rollbacking. This change is like really a possibility at this point.
Mario Vega:I don't know if everybody still feel the same way.
Mario Vega:But that's my opinion.
Mario Vega:Yeah.
draganrakita:Yeah, it's basically one. Characters don't even line from 5 to 3.
draganrakita:I'm up to changing it. I'm not sure if anybody else is.
Mario Vega:Yeah, to raise Marius's point. regarding benchmarks.
Mario Vega:it feels like dragon mentions that he has benchmark for this. Is that correct? Or
Mario Vega:do you have this for all the clients? Or is this just rep.
draganrakita:There is bytecode that can be found in repo.
draganrakita:But the fastest batch project I could do is basically from our evm.
draganrakita:So I did it in the code. And I did it in the code speed. That basically shows amount of the
draganrakita:time spent on every upload.
draganrakita:And I compare this output that I got from the outputs, from the different topcodes, and it is more similar to other bitwise opcodes.
draganrakita:So it seems that Batchpark is correct. Now there are different limitations and different
draganrakita:depending on implementation. You will have different execution.
draganrakita:but either way seems correct to to use tree gas here.
Mario Vega:So just to summarize. I mean, I think this change was done a week or 2 ago
Mario Vega:in regards of keeping things safe right? Because we don't really have much benchmark, that many benchmark for every single client team. So if I understand correctly, your benchmarks are only for red, so we would need to do a deeper like analysis on benchmarking for the rest of the clients before rolling it back. In my opinion, so I would echo Maris on this that we don't
Mario Vega:want to change it, because it's very late in the process. But if anybody else feels opposed to that, just please
Mario Vega:speak up from the other El clients would be nice to hear. Yeah.
Ben Adams:I mean, it's very simple to change. I mean, just revert the previous pr that increased it.
Ben Adams:But don't feel any particular way on it.
Mario Vega:Yeah, the the change is not the concern. I mean, I think that the change is super simple even in the test is simple, but I think benchmarking is the main problem that we have now, and we don't have.
Mario Vega:and up benchmarks for this from the East Side. We're working on benchmarks, but we're not quite ready, because the framework's not
Mario Vega:fast enough to deliver the benchmarks yet.
draganrakita:We didn't even have benchmark that pushed it from 3 to 5.
draganrakita:The data that I have shows that it's even less than 3.
draganrakita:But either way, it's not big of the deal. The main thing is, we have Cls included.
draganrakita:So if clients are not up to to the change, it's fine to have it. 5.
Mario Vega:Yeah, I was still in to leave it as is on 5.
Mario Vega:But yeah.
Mario Vega:open. I think I think we should leave it for for dignity. And yeah, consider it for for Dumpster, for reduction.
Mario Vega:Kev for your question. I'm not sure for the answer to be honest.
Mario Vega:Yeah, okay, Marius.
Mario Vega:So you're saying like, it's 5 times yeah.
Mario Vega:it's 5 times worse than ad. Right? Do you want to expand on that on get the site.
Marius van der Wijden:Yeah, I literally just did this in the last 2 min. I I wrote a benchmark.
Marius van der Wijden:and from what I can see it is.
Marius van der Wijden:do we have one benchmark for adding 64 Byte
Marius van der Wijden:and and that is like 5 times faster.
Marius van der Wijden:Then cl, z, and even the multiplication is like.
Marius van der Wijden:at least 4 times 4 and a half times faster than than clc.
Marius van der Wijden:so maybe there's something weird with our clc implementation.
Marius van der Wijden:But yeah, it seems like.
Marius van der Wijden:at least for us. It's not in the same vicinity as the other codes.
Marius van der Wijden:But, as I said, I I wrote the benchmark just now. So maybe there's something wrong with with my benchmark. But I would like to.
Marius van der Wijden:Yeah, I would would love it if we had some
Marius van der Wijden:if we had like a full benchmarking suit for this, and I think that is.
Marius van der Wijden:feels like an oversight that we don't have this right now.
Mario Vega:Yeah, I agree. So how this I think the main question right now is benchmarking. I think we can work on that this week
Mario Vega:and do benchmarking against all the clients.
Mario Vega:and I would lean towards changing the gas price upwards instead of downwards. So I feel like leaving it as 5 is the correct decision at the moment, and then we can, after the benchmarking, we can decide on whether bumping it because of security concerns
Mario Vega:rather than just lowering it. Now.
Mario Vega:does that sound fine by everyone?
Mario Vega:All right.
Mario Vega:Cool. Yeah. We only have 5 min left. I think if I'm not, if I didn't miss anything from the from the chat. I think the last discussion is or at least was brought up, is the 60 million gas question at the moment. I don't remember who posted the message. But do you want to expand on the
Mario Vega:whether we want to go on that today or not?
Kamil Chodoła:It was me actually, just wanted to, maybe brought the discussion, as we already hit 45 and 60 is not a matter of any further eaps, at least, for now we do not know about anything which we need to be repriced to hit 60
Kamil Chodoła:before Fusaka. We know about some optimizations needed to be made by some real clients.
Kamil Chodoła:But maybe anyone is having any doubts or anything like this to to see, or at least make any kind of temp check if we
Kamil Chodoła:should try to to reach it before Fusaka, or there is anything else which anyone have in mind
Kamil Chodoła:against that.
Kamil Chodoła:for sure. What we know right now is that we need to optimize a little bit more modex libraries in go implementations. But this is a ongoing work, and we have a lot of benchmarks around that.
Kamil Chodoła:So yeah, so we know how how much we need to improve around modex.
Kamil Chodoła:But yeah, except of that, there is not much. Things which feels like are any risky.
Marius van der Wijden:I don't.
Marius van der Wijden:Oh, maybe the receipt stuff, because.
Marius van der Wijden:like, if I remember correctly, the receipt stuff breaks around. 72.
Marius van der Wijden:My goodness, a million gas clocks.
Kamil Chodoła:And last recall, it was 85.
Marius van der Wijden:Oh, oh, okay, then,
Kamil Chodoła:Kuwari also mentioned that here.
Marius van der Wijden:But with the with the with the
Marius van der Wijden:with the refund bump, you can probably get that down right by like 20%.
Marius van der Wijden:That's valid. Yeah.
Mario Vega:Ben, do you want to add something or.
Ben Adams:Yeah, I was just gonna say that the receipts is the blocker on getting to 100. It's not not a problem for 65.
Kamil Chodoła:So generally, I put that in a chat. And
Kamil Chodoła:even we have those few minutes additionally, but just wanted to throw a topic. And maybe we can think about it throughout the week
Kamil Chodoła:and get back on that and add it to our agenda next week to to discuss and see.
Kamil Chodoła:because at least. Personally, I don't see any like big blockers. Instead of some general performance improvements
Kamil Chodoła:to to reach it before actually, Fusaka will come in place and solve some of these issues.
Kamil Chodoła:which would be nice because we still don't want to probably go in one big jump between 45 to I don't know 100, after addressing modex repricings.
Kamil Chodoła:would be nice to have something in in meantime.
Kamil Chodoła:and 60 feels like a good stop which we can
Kamil Chodoła:pretty safely achieve prior to that.
Mario Vega:Alright. Thanks thanks for bringing it.
Kamil Chodoła:Growth is also a good point from from Marius, which is being worked on.
Mario Vega:Yep, perfect. Yeah, I think I think it's a it's a it's a nice topic to bring up.
Mario Vega:I think next week we can be
Mario Vega:well, maybe not today. But in the in the coming weeks we can have more more information on this. But it's nice for it to be brought up so we can have it in the back of our minds.
Mario Vega:No need for a decision right now.
Mario Vega:Cool. Okay. Any other topics. We only have 1 min, but if there's anything like alarming that we have to race right now.
Mario Vega:please speak up.
Mario Vega:Otherwise I think we can wrap it up here. Alright thanks everyone.
Mikhail Kalinin:Thanks, so much.
Dmitrii Shmatko:Care about.
Antoine James:Thank you. Everyone.
Marius van der Wijden:Thanks. Brett.
Chat Logs
00:00:54
Parithosh Jayanthi:notes.ethereum.org/@ethpandaops/fusaka-devnet-3
00:01:41
Mario Vega:https://github.com/ethereum/execution-spec-tests/releases/tag/fusaka-devnet-3%40v1.0.0
00:01:41
Ben Adams:Is the modexp x3 in devnet-3?
00:01:56
Marius van der Wijden:Replying to "Is the modexp x3 in ..."
Y
00:02:06
Parithosh Jayanthi:Replying to "Is the modexp x3 in ..."
Yes dev3 is ideally spec freeze
00:03:19
Parithosh Jayanthi:https://github.com/ethereum/execution-apis/pull/674
00:03:27
Parithosh Jayanthi:https://github.com/ethereum/builder-specs/pull/123
00:03:27
stokes:builder specs PR is ready to merge unless anyone has a question today
00:04:04
Gabriel Trintinalia | Besu:Besu ready, pending getBlobsV3, with have a PR for it ready
00:04:09
Marius van der Wijden:Geth: ready (except the config endpoint)
00:04:10
Roman:reth has a branch minus eth_config & get blobs v3
00:04:22
milen | Erigon:Erigon ready without getblobsv3
00:04:27
pawan:Lighthouse is ready too, fixing some performance issues
00:04:41
Ben Adams:Nethermind ready
00:05:13
Saulius Grigaitis | Grandine:Grandine seems ready
00:05:13
Justin Traglia:On the CL spec side, not much has changed for Fusaka; alpha.3 is still the latest release. There’s been a considerable amount of work for EIP-7732 and EIP-7805 the past week.
00:05:15
nflaig:Lodestar is ready, just missing v2 builder api
00:06:19
Raúl Kripalani:since most ELs have getBlobsV3 ready and there's nothing to do for CLs, should we go ahead and merge the PR?
00:06:23
Gabriel Trintinalia | Besu:What about getBlobsV3? is it happening?
00:07:15
Raúl Kripalani:EL devs can you react here if you're good to merge the getBlobsV3 engine api spec change?
00:08:19
Saulius Grigaitis | Grandine:Does this test tool test only happy case?
00:08:32
Parithosh Jayanthi:Replying to "Does this test tool ..."
Rpc testing tool? Yes, its a benchmark tool
00:08:51
Parithosh Jayanthi:Replying to "Does this test tool ..."
Sync test tool is also happy case for now, since we are missing this data for 2x mainnet or significantly larger state
00:19:29 Marcin Sobczak: EIP-7883 ModExp Comprehensive Analysis Report:
https://github.com/nerolation/eth-7883-analysis/blob/master/eip7883_comprehensive_analysis.md
EIP-7883 Entity Impact Analysis (Updated):
https://github.com/nerolation/eth-7883-analysis/blob/master/eip7883_entity_analysis.md
00:12:07
Kamil Chodoła:Nethermind - will report issue and want to add a metric for that
00:12:37
Parithosh Jayanthi:Can you guys please post metrics updates async on chat when its included?
00:12:41
Parithosh Jayanthi:Ideally in the performance branch
00:12:42
Dustin:Replying to "EL devs can you re..."
it doesn't really matter if it's merged, if it's not tested. if it's not tested in a devnet-like environment it doesn't exist in a guaranteed way in Fusaka, from at least a Nimbus CL perspective
00:13:46
Ben Adams:Replying to "Ideally in the perfo..."
All our branches are a performance branch ;)
00:14:17
CPerezz:https://hackmd.io/boZCC4eNR66zN3m9VDYFWQ
00:15:55
Dustin:Replying to "EL devs can you re..."
I don't care how simple this looks, etc, this is how Holesky died
00:17:02
Kamil Chodoła:All the changes to "performance" branches are automatically populated to op-codes benchmarking, perfnet and bloatnet so make sure to update it regularly (with experimental perf changes + rebasing to master whenever needed)
00:18:43
Francesco:At the point when CLs (say in 6 months) want to introduce it and use it, it would be tested, no?
00:19:19
Dustin:Holesky's changes were simple too
00:19:21
Dustin:so simple
00:19:42
Marius van der Wijden:We can't do an off-cycle release, if we don't ship it in fusaja releases, we will only merge it in glamsterdam
00:20:24
pawan:Replying to "We can't do an off-c..."
Why? That’s how we did it for GetBlobsv1
00:20:34
kasey:Replying to "At the point when CL..."
I think the concern is that if ELs release at Fusaka with this API, we would need to test with versions of the EL released at fusaka. CL releases that flip the switch to use this wouldn’t know if they are running against a tested EL pair.
00:21:52
pawan:Replying to "We can't do an off-c..."
Also, to note, this is for an unproven optimization. getBlobsV1 was prototyped and first made sure it worked before all clients eventually implemented it
00:22:01
Marius van der Wijden:Replying to "We can't do an off-c..."
Hmm I guess. I think requiring el and cl updates at the same time between hfs is very messy
00:23:57
Francesco:We should not defer discussion, we said last time we would make a decision
00:23:58
Csaba:BPOAALB (BPO And A Little Bit)?
00:24:03
Francesco:And it’s been going on for weeks, we should just make a decision
00:24:12
Francesco:Replying to "And it’s been going ..."
(months?)
00:25:54
Dustin:If ELs ship getBlobsV3 now, and then at some point between now and when it's needed, those tests do happen, that can work, in pure testing consideration terms.
i.e. they're not trusted yet, but it might be, retroactively, later
00:26:30
Dustin:I agree regarding process considerations though, this is ... messy
00:26:42
Parithosh Jayanthi:Yeah lets make a decision today please
00:27:04
Matthew Keil:Agreed.... If there is not consensus it needs to be postponed
00:27:42
stokes:afaik process wise we should be ok, we should just make a decision today
00:27:49
Dustin:And, importantly, testing process with the first Fusaka-related versions of each EL, not the current versions
00:28:46
Francesco:Right, I think the “don’t merge” decision should actually be to do getBlobsv2 as the CLs have it now (as in the PR) but not getBlobsv3
00:29:56
Raúl Kripalani:so revert this? https://github.com/ethereum/execution-apis/pull/671
00:30:00
stokes:Replying to "so revert this? http…"
yep
00:30:02
Gabriel Trintinalia | Besu:getBlobsv2, allowing partial response or not?
00:30:27
Gabriel Trintinalia | Besu:all or nothing, okay
00:30:32
Manu:Replying to "getBlobsv2, allowing..."
Prysm: currently all or nothing
00:30:44
stokes:we want v2 to have the behavior in any world moving forward
00:30:46
Matthew Keil:Agreed Mario
00:31:59
Kamil Chodoła:Maybe a bit to early as 45MGas just hit but shall we more openly discuss 60MGas increase and what we need to do to achieve that even before Fusaka?
00:32:17
Parithosh Jayanthi:Replying to "Maybe a bit to early..."
Sure, depends on what section of the call its appropriate for
00:32:51
Marius van der Wijden:I think safe head should become the default for most applications that currently use finalized
00:33:31
Parithosh Jayanthi:Sorry for the out of band msg, but what’s the opinion on the builder PR? https://github.com/ethereum/builder-specs/pull/123
Can we merge it? Or any open discussion topics?
00:35:55
pawan:Replying to "Sorry for the out of..."
Do all relays/mevboost support v2 already? How do we check support for v2 before calling it?
00:36:41
Parithosh Jayanthi:Replying to "Sorry for the out of..."
@Bharath ?
00:37:03
Bharath:Replying to "Sorry for the out of..."
We have work undergoing in the flashbots relay to implement the v2: https://github.com/flashbots/mev-boost/pull/809
https://github.com/flashbots/mev-boost-relay/pull/746
Which should hopefully be done soon
00:37:36
pawan:So when we implement it, do we call v2 by default and fallback to v1 if some particular error?
00:38:00
Bharath:Replying to "Sorry for the out of..."
Other relay operators like Ultrasound and Titan are aligned with the v2 APIs. We will reach out to them to ensure that they have implemented it.
00:38:20
Bharath:Replying to "Sorry for the out of..."
For devnet-3, we will get the v2 api implemented in the flashbots relay so we can test it over there
00:38:34
Francesco:16-32x faster 😄
00:38:34
pawan:Replying to "Sorry for the out of..."
I’m not clear when we start using it. Is it when fusaka activates?
00:38:48
Bharath:Replying to "Sorry for the out of..."
yes
00:38:56
Bharath:Replying to "Sorry for the out of..."
The v1 will be deprecated with Fusaka
00:39:01
Bharath:Replying to "Sorry for the out of..."
And v2 should be used.
00:39:32
pawan:Replying to "Sorry for the out of..."
Sounds good, will get this done today
00:39:50
Bharath:Replying to "Sorry for the out of..."
We will implement with the flashbots mev-relay and meg-boost. We can’t test it out with other clients cuz their code is closed sourced anyways.
00:39:59
Bharath:Replying to "Sorry for the out of..."
We should aim to get it for devnet-3
00:40:12
Bharath:Replying to "Sorry for the out of..."
I mean relays*
00:40:15
Bharath:Replying to "Sorry for the out of..."
Not clients
00:40:26
terence:I think the current safe block hash definition is vague enough such that CL client (node operator) can be passed (ie. justified, unrealized justified.. fast confirm...)
"safeBlockHash: DATA, 32 Bytes - the "safe" block hash of the canonical chain under certain synchrony and honesty assumptions. This value MUST be either equal to or an ancestor of headBlockHash"
00:40:59
Bharath:Replying to "Sorry for the out of..."
Hope that’s clear.
00:41:40
Marius van der Wijden:We should discuss with rpc providers though tbh
00:42:30
Dustin:also, SSZ is fine, but doesn't 123 as-is mean that there's no real "scaling" concern with JSON anymore?
00:44:04
stokes:Replying to "also, SSZ is fine, b…"
it removes the main bottleneck for sure
00:44:57
nflaig:Replying to "also, SSZ is fine, b..."
the response was never a concern at least for me but network failures trying to submit blinded block to relay because you can't fallback at this point to local block
00:55:18 Ben Adams: CLZ is a single stack opcode like NEG; so much lighter than MUL
Only issue is timing
00:45:45
Marius van der Wijden:Why don't we have real benchmarks for this yet?
00:46:10
Dustin:Replying to "also, SSZ is fine,..."
yes, none of the currently proposed changes fix that though @nflaig
00:46:18
Marius van der Wijden:I would prefer not to change it, very late in the process
00:47:06
spencer-tb:Could it be < 3 (not a heart) in Glamsterdam? If so then I think we should wait until then!
00:47:15
Dustin:Replying to "I would prefer not..."
at least, if it's changed, then make sure every EL by first testnet has implemented it uniformly
00:48:20
Ben Adams:Replying to "Could it be < 3 (not..."
potentially repricing a lot of opcodes in Glamasterdam; so could fit there
00:48:49
Raúl Kripalani:to close the loop on getBlobsV3:
closed the PR
opened one to make V2 all-or-nothing again, in case ppl here want to review quickly
00:49:04
Marius van der Wijden:Our opAdd: 8ns opCLZ: 48ns
00:49:05
kev:How do we know 5 is safe?
00:49:42
Dustin:they all sound arbitrary
00:49:49
Ben Adams:Replying to "How do we know 5 is ..."
you could examine every byte individually and it would still probably be faster than MUL
00:51:16
nflaig:Replying to "also, SSZ is fine, b..."
no, but my point is that ssz on the api was never meant to make the response faster as we already knew for long time that relays delay the response anyways artifically
00:54:01
Parithosh Jayanthi:~85M I think?
00:55:23
jochem-brouwer:Marius point about the refund is a good point, because you can have effective gas limit 20% higher if you max out the refunds
00:55:30
Ben Adams:Replying to "~85M I think?"
yeah want eth/70 for fusaka so receipts won't be problem after
00:55:37
Csaba:Doesn't the limit depend also on CL CPU usage changes?
00:55:39
Marius van der Wijden:I would also like more data on state growth for 60M, hope that bloatnet can help us there
00:55:57
Parithosh Jayanthi:Replying to "Doesn't the limit de..."
For post peerdas? Or what do you mean?
00:56:18
Parithosh Jayanthi:Replying to "~85M I think?"
Isn’t it already included?
00:56:33
Ben Adams:Replying to "~85M I think?"
on plan 🙂
00:56:39
Csaba:Replying to "Doesn't the limit de..."
Exact. PeerDAS changes CPU
00:56:40
CPerezz:Replying to "I would also like mo..."
One step at a time! 🙂
Getting to 2x mainnet for now and gathering EL client’s info to come up with as many cases as possible. Any deadline in mind?