All Core Devs - Execution #149

Transcript

Heat [Music] [Music] up here. Heat. [Music] Heat.

[Music] [Music] Heat. Heat. [Music] Heat. Heat.

[Music] Heat.

Heat. [Music]

Tim Beiko: Good morning y'all. [Music] Good morning.

Okay. Okay. Thanks, Puja. Um, welcome everyone to Awkward Dev 149. Hopefully YouTube is working. Um, if not, this is being recorded and um, I can I can upload it after. But um, yeah, a lot on the agenda today. Um I think high level trying to figure out what Shanghai looks like is probably the main thing. Um and there's been some uh bunch of work on the EOF side on the 4844 side. Uh so you can share some updates

on that. And then there were a lot of other EIPs that wanted to be considered for Shanghai. Um so I told all those people to show up today. Um so there's four main ones. Um, Micah, you also had this agenda item about just talking about the fact that uh running a node is getting uh more resourceheavy and and um that we should address that. Uh so we we can talk about that as well before um the the Shanghai inclusion conversation so that you know we we have that context assuming we get through all of this in less than 90 minutes. Um, Mikuel had a quick engine API uh, proposal that he wanted to discuss. Um, and I think one

thing that would be valuable is then talking about how we approach DevNets for Shanghai. Um, if we have a good feeling for for for what's likely going into the fork. Um, and then there are a few other topics. So, uh, mostly just uh, how we think about sunsetting Robston and potentially test nets more generally. um and some updates on execution specs and the tests uh generated for the execution layer. Um I guess to get started uh last Friday there was an EOF call. Um does anyone who was there want to give a quick update on um sort of what was discussed and where things are at uh with EOF right now?

Matt Nelson: Tim, you broke up a little bit there. I don't know if that was just Sorry.

Tim Beiko: Yeah, I was just saying um does anyone who is anyone here who was on the eof call uh last Friday and and want to give a quick update on on where things are at with that?

Danno Ferrin: Was I the only one there that's on this call?

I was there. your first cup. So sodo it's game of

Danno Ferrin: um so a lot of it so circled around the debate of big eof versus little eoof. Um one of the big takeaways is we're going to target the ethereumjs testn nets shandong and we're going to try and target big eof as our first and

preferred approach to ship eof. um Shandong um is a test net. Uh Tim wrote up a document showing that it's kind of on a parallel track. It depends on everything in Shanghai may or may not includes deposits or not for the test net. But in essence, Shanghai is is the most important what's driving the release which is deposits and the other features which would be um 4844 which is parallel to the EOF big EF changes um depend on Shanghai and the premise being if we can get things proved and shown working on Shangdong and tested and all the clients implementing it then we can move it into Shanghai if it's early enough and if it's not early enough it moves out to Cancun. So that way um

we've decoupled development and validation of shipping it from whether it's part of Shanghai. So the discussion about deposits could be on a separate track. Um all we included in big Shanghai was just relative jumps and function functions. We did not include um the uh stack verification um because that's still kind of in beta. So those are the only two big things we added into EOF. Um but those do um change the nature of what the EOF container looks like. And because there was a desire to only do one major change in the next x number of years, um we want everything that's in efig from everyone on the call speaking for the people on the call. So

let's just do it in EF big and ship it as soon as it's possible.

Lightclient: I don't know if I missed this part, but I thought stack validation was part of EF big. like it's listed on the epsilon eof list.

Tim Beiko: So on the call I think they said it was just not quite ready for implementation.

Danno Ferrin: Um and the thing about stack validation is if you do everything else you can still write code that validates the stack and you can still get the benefits of linear compilation with a subset of stuff. Um the validation API would just reject stuff that didn't match that. So um that can be added later. And the real issue is it's not um particularly specified uh in the specification way. It's only has

a reference implementation. So I think that's what's holding that one back.

Lightclient: I don't know. I mean what do you mean it's not specified? There's the EIP. I've mostly implemented the EIP at this point.

Danno Ferrin: The specification specification says is you know check the stack height of each instruction. For something that's uh deterministic and repeatable there would need to be an algorithm to find that this is what you do. And the algorithm that is in the reference implementation is actually not linear. It's like order n squ or something. And so there's better stuff. So it's not quite ready to ship would be the conclusion.

H

Lightclient: okay. Uh yeah I I don't know what the like timeline of making it ready to ship. It felt like to me that this is something that we can like resolve relatively easily. like all the other E efs have like some small changes that need to be made just now that we're under this assumption of bigger eof and those are things that are straightforward whereas you know if we don't ship the stack validation we do have to increment another EO version since it would be possible to deploy contract code that stack overflows um whenever you do a call

Martin Holst Swende: Uh can I just make a question here u to

dump it down a bit? Uh so whether or not stack can overflow or not from I'm I'm thinking from like pure EVM perspective that's that's a pretty uh ne negligible check. Is it important from like other uh other points of views such as you know verifiability and and analysis.

Danno Ferrin: So if done right stack validation can allow for per Greg Kovven um linear compilation time to transpile it to something like machine code. Um so if you have if you can prove that and that also provides a subset that then if you have stack validation tools like

solidity and ule can only create um eof can only create EVM code that can be linearly done and it gets rid of a lot of compiler bomb attacks for people who are going to try and jit it. Um it's you know Java's perfected some of this and brought it into their compiled process and they've got the same rules on their JVM. really there's like a whole section on their spec about that and that's I think one of the reasons why I'm go ahead

Martin Holst Swende: no for any for any compiler they can always validate the spec right so what is enforcing stack validation on contract deployment which only makes a difference on runtime or well if you analyze live code on the

blockchain right

Danno Ferrin: if you reject yeah if you're going to be rejecting Um yeah that doesn't validate

Martin Holst Swende: are we going to reject stuff that doesn't validate or are we not going to validate um from my perspective as like having ahead know building the EVM uh I think the performance gain of knowing that the stack cannot be overflown is negligible. So therefore I'm wondering is there some other aspect to this problem where where this actually makes a difference.

I

Danno Ferrin: I kind of can concur why I don't think it has to be in um the epsilon folk who are writing it. Um I think that was Powell um he he kind of agreed that it wasn't quite done yet as far as the EIP. Yeah, there's a skeleton of a specification out there. There was reference implementation but it's you know he he seemed to feel agree that it wasn't done done and was happy with it slipping out.

Okay,

Lightclient: that's fair. I think that it's just like you know one additional thing that a small amount of work could make make it so that it's ready and we could avoid having you know this immediate thing that we might want to make a version change to in the future.

Right.

Danno Ferrin: The train door is not closed on big eof, but that's not what we're focusing on right now. If a finalized algorithm comes in that is linear and specified, you know, that's that's what is needed to move it forward. And I think that's what he's working on, right?

Tim Beiko: Like it's it's it's possible to add this to EOF devets basically if it gets ready um before before Shanghai, right?

Danno Ferrin: Yeah. Or whenever big ships, right?

Tim Beiko: Yeah. Um Andrew, you've had your hand up quite a while.

Andrew Ashikhmin: Um yeah, we briefly touched it um on Friday, but I would like to highlight that one important uh task for the big EF is support and solidity. So that would both verify that um that the EF makes sense and we can compile solidity contracts into it and also ensure that there will be some real contracts in production because like I would like to avoid having it only as a theoretical uh thing that nobody uses and yeah to my mind that's another thing like not not only implement it in all the L clients but have it like full good good production level implementation and

solidity. Yep.

Danno Ferrin: I I concur. It does have small EOF support which is relatively simple. So the big EOF splitting into functions is not a a small compiler change.

Lightclient: So I mean if we're going to hold EOF to the standard, I think we should think about holding other EIPs to the standard. And I don't think that historically we have required a production level solidity implementation for things and I generally I generally feel that uh a commitment from the solidity team that this is a good thing that they plan to implement it is usually usually suffices.

Andrew Ashikhmin: Uh the problem with that is that what kind of um reiterating Marus's concern is that if we have some like if we accept your that will be in the standard forever and then solidity commits to to to supporting it theoretically then it turns out that because of some quirk of the EIF as is they cannot fully support it and blah blah blah. So we'll have to have a new version of your but the the the intermediate version uh stays there forever. So that that's to my mind that's a very important change to the EVM. So we need to have sanity checks on it. One of the sanity check. So I I see

solidity support not as something not not as an extra but as a sanity an an essential sanity check.

Martin Holst Swende: Can I just um um so I mean Alex Basi isn't he both very involved in the EO off and very involved in solidity. Yes. And I think I don't know if he or Chris one of them is is like the head of the solidity. I think I may be wrong here. Um which to my mind kind of speaks that yeah the solidity team are probably very well uh you know first aware in this

proposal.

Tim Beiko: Yeah. And the I believe Daniel is Yeah.

Andrew Ashikhmin: I would say I would say that just awareness well at least that that's my position that awareness is not good enough uh like a a working compile compiler into eof without dynamic jumps is like to to my mind at least it's like a a requirement before releasing it to the

mainet we

Marius van der Wijden: kind of need it for testing anyway so I would also really like to Yeah.

Tim Beiko: And I think yeah, so I I posted this in the chat, but generally I think the the perspective was there like uh

they support it like the the the first few EOPs didn't affect them much. The the second ones obviously require more work, but they seem generally um yeah, supportive, although it's not clear like it's easy for them to to support it. So, um, we can definitely talk with them about it more and and, um, yeah, I don't know that any one of them is on the call right now. Respond to the comment

like

Micah Zoltu: made a bit ago that we don't uh hold other EVM changes. I think the difference here is that those other EVM changes are usually really small and everybody's quite confident that Solidity will have no problem implementing them. whereas this

change is quite substantial and there is non-trivial risk that solidity will not be capable of implementing this reasonably. Um, and so getting Solidity this one first gives us that confidence that oh no, there's no there's no hidden gotchas or unknown unknowns anymore. Like it can and has been implemented solidity there. There's it mitigates all that risk.

Lightclient: Honestly, I was referring to 1153 whenever I mentioned this.

Micah Zoltu: Oh, which one's 1153?

Lightclient: This is transient storage.

Danno Ferrin: Oh, okay. How does this kill 1153? I'm missing that.

Lightclient: Well, if we're going to require Solidity to have the implementation done in a production manner, there's no implementation in of 1153 and Solidity. It doesn't seem like there's intention of making an implementation in the near future.

Moody Salem: Well, they got it. I mean, I don't want to speak for them, but they did say that if it's approved and goes in, they will implement it.

Lightclient: Um, right. But now we're saying that we're not going to approve things until it's implemented.

Danny Ryan: So I think there's a level of complexity that there's concern about on this other one. Um if there's a similar level of complexity concern on 1153, then I would

also maybe block on it, but I don't know if that's uh the perception here.

Martin Holst Swende: Chris right Eastern did express concerns about the complexity on level 53. Unfortunately, it's not on the call.

I guess

Moody Salem: I mean there it's also implemented in Viper um already. So it's a bit strange just index on 1153 is already in Viper T and T load.

Danno Ferrin: It's much simpler than the container and getting rid of dynamic jumps.

I mean I

Micah Zoltu: to be clear I I don't uh feel a need to has to be solidity but I I do kind of agree that we should see some compiler implement it successfully and so if 53 is implemented by Viper for me personally that kind of meets the bar of this has been proven that there's not a bunch of unknown unknowns that we need to worry about anymore. Right.

Tim Beiko: So I think and you know we we don't have to make a final call about eof or 1153 right now. I mostly just want to make sure everyone sort of knows where things are at. Um it probably makes sense to move on given how much time we we spent on this already. But at a high level, client teams are working on implementations for uh these four EIPs uh that we listed earlier. So uh

the two original ones uh 3540 3670 and then the addition of 4200 4750. Uh the other one for stack validation um we have some implementations but it still needs some work and then solidity support is obviously an open question. Anything else anyone wanted to share on eof okay. Um, I guess the next one I'd like to get a quick update on uh is just 4844. So, I know there was a call uh this week for that as well. So, um yeah.

Does anyone here who was on the call want to share a quick uh update on on where things are at?

Protolambda: I can give a short update and others can chime in if I miss anything. So on Tuesday we had an44 implementers call. I believe the defet version 3 is on track and we are targeting end of November so after Thanksgiving. I believe the last crypto APIs have been merged. But then there's some open discussion on whether or not to uh share the pre-ompile implementation as a whole as a shared library to not

have to do the decoding of the points on the client side or like in the EVM implementation rather than in the crypto library. And then I um believe Tren is tracking the open P2P uh changes on the consensus layer. There are some optimizations we can make there. Specifically the branching part of the fork tree where we can have many different beacon blocks. We have something called beacon block by root to fetch blocks on the existing beacon chain. And we may want an equivalent of that to fetch blobs. And

then there's some discussion or whether uh or not to couple the um beacon block and blob fetching with this by root method. And I believe those are all the the big updates. Also the EIP was updated with um some parameter changes which are still in discussion. and then going into the test net and with the further testing of mainet performance of call data and so on. I think we got the data to decide on the parameters for

for44

Danny Ryan: and specifically I think the blobs by root is a blocker and the rebase on

Capella is a blocker. Blobs by root I think generally has consensus and I expect to be merged soon. Um although there might be a finer point around how deep you serve those requests and then the Capella updates that are blocking the rebase being finished. We're going to wrap up today.

Tim Beiko: Thanks. And I think also like on the last call when we discussed this uh we mentioned trying to like uh iron out the final sort of design uh PRs and the EIP.

I believe these have all been merged. So like the the the fee market changes have all been merged. Um and there's was a PR also to change the output of the pre-ompile. I'm not sure if it's been merged or not, but that might be the only outstanding PR on the E side. Um that affects the actual spec. Um I don't know is Anscar here? Um I'm here. Yeah. Do you do you just want to get a quick update on just the the PRIP itself?

Ansgar Dietrichs: Uh, sure. So, at least uh last evening I haven't had it. I only woke up for ACD, so I haven't had a look at, but I I don't I um the pre-ompile output change was not yet merged, but it's it's it's ready to merge. Um right now um because of a small issue with the EIP repository every um PR to the EIP uh not only needs um author approval but also um an EIP editor to actually merge it. Um so it's a little bit slower but basically there are um three um PR at least that that I was involved with. One is just a small uh change to so that the the pre-ompile um the point evaluation pre-ompile it used to only take basically return like

just basically it just used to revert um if if it was invalid or not revert if it was valid um but not return any values um and now it was it's supposed to return the um degree of the um of of the polinomial and also the modulus um of the field. Um so that's change one that's b that's that's ready and just needs to be merged. Um then there is a second change just to um decrease the um throughput uh of uh 444. Um I think basically everyone agreed that if we at least as long as we still optimistically targeting um Shanghai for 4844 we would want uh to start with lower throughputs

just so we don't have to to worry about um node load and network load. Um, so that's still pending. And then there's a third one which is um basically um a bit more open for discussion on whether or not we would want to introduce a minimum um price for for blobs um lower than the higher than the the theoretical minimum of basically one one way per per blobcast. Um that one is unclear whether or not people end up wanting to even do that, but that would also just be one constant change in the IP. So that's that's the three spec PS that basically I I have a view on.

Tim Beiko: Thanks. Um any other questions, comments on 444? Okay, I think yeah. So the next thing I think it probably makes sense to to cover is uh Micah, you had uh a comment in the agenda addressing sort of the increasing operational costs of running a node. Um, do you want to take a few minutes and maybe walk through what you see as the issue? And um, Yep. Sure.

Micah Zoltu: Uh, so the to preface I I'll give a short little spiel to set the stage.

My my hope here is that we can walk out of this with um a more consistent vision on kind of what we're what we're trying to build. I I feel like it's it's kind of uh fracturing a little bit. And so u I don't I do have a personal opinion on what I want but I would rather see us be consistent on what we all want rather than any particular stance. So I think right now if we round to the nearest integer about 0% of users run their own node and when I say users here I mean people who are using Ethereum to do something that might be buying and selling NFTs or trading tokens or whatever. Um this means that about 100% of users are using centralized services like Infura and Alchemy and whatnot. the many of those those centralized services are actively censoring right now like

today. They censor people from a number of countries that really could use cryptocurrency and they also censor a number of tools that are really good for privacy and stuff like that. And so we have a this kind of censorship problem and it's been slowly growing over time and uh during that time as it's kind of slowly kind of built up we've been focusing a lot of our effort on scaling and at the moment there there's lots of lots of blockchains out there that focus on scaling. BSV, Swana, you know, they focus on scaling and they prioritize that over censorship resistance, meaning people being able to actually run a node. And so I feel like 4844 is is kind of another step in that direction that we've been on where we're prioritizing

scaling at the cost of censorship resistance. In the case of 4 4844, this comes in the form of 4844 is is going to increase the storage cost requirements of running a node and the network cost requirements of running a node. if this um EIP to change it uh 5863 or sorry if this PR to change its throughput and that helps a little bit but it is still strictly an increase. So 4844 is going to decrease the number of people who are capable of running their own Ethereum node from 0% to a smaller 0%. Um we do have some stuff on the backrunner that's been working on very slowly with the vertical tree statelessness history expiry state xbury. Um these these things have been worked on for quite a while. Um but we keep prioritizing other things over them unfortunately. And so they're taking a very long time to

actually come to fruition and make it onto Ethereum. And during that time you know the the size of the state continues to grow the throughput continues to grow. gas prices or gas block gas limits have been increased a couple of times I think over the past few years right um and we just keep you know keep kicking this can down the road and I think that at some point we need to stop and ask ourselves do we want a high scalability blockchain or do we want a censorship resistant blockchain that people can actually run themselves and if we choose that we want the censorship resistant blockchain people can run then I think we need to take steps to say you know anything that makes that situation worse we should wait on until we have solved the problem of making it so people can actually run their own nodes whether

that's light clients or pipers portal network or state xree or history xree or statelessness or vertical trees or whatever that looks like um there's lots of options here but I think that if we continue to not make the choice to prioritize those things we're going to continue to make the choice to prioritize scalability and that scalability comes at a cost and we're paying the cost every time we do it and it's a little bit at a time each time right so a this 4844 it's going to decrease or increase the operational cost a little bit. It's going to decrease number of people who can run their own node a little bit and this is the same as almost everything before you know increasing the block gas limit. It increases that operational cost a little bit and these little bits just add up over time. So what I'd like to see see

us decide is, you know, do we want to kind of make the assertion that yes, we understand that we're sacrificing censorship resistance for scalability and that's an intentional choice we're making and we do plan on fixing it, but not today or is we want to focus on censorship resistance today and sacrifice scalability and make that trade. Um, so yeah, like like I said, I I have a personal preference. I'm sure everybody here knows what that is, which is I care priority primarily about sensor persistence. But I'd at least like to see us kind of agree that we care more about scalability today than we do about that little bit of extra sensor that comes with 4844 and similar things. So that's my spiel. Um I'd love to spend some time talking about it, but I know we've got limited time, so I'll let Tim take it from here.

Tim Beiko: Thanks. Yeah. No, I think that was uh yeah, I appreciate all the all the all the context there. Um yeah, let's just use the hands to go through the comments on this. Um so Andrew, you were first.

Andrew Ashikhmin: Um yeah, uh from my perspective, we can do both. U we we can try to um like to my mind scalability is important and uh we can reach better network participation with light clients version two or three whatn not. uh but I would like to to to comment that uh we to we we to my mind we can achieve both if we concentrate on uh fundamental like

fundamental improvements uh so I would uh for instance in in argon we we are still working on snapshot thing syn think and then it it'll allow us to support things like history expiry or like to be precise more precise eo for fours uh but uh and from from but our capacity is limited. So I would rather avoid uh tweaking gas schedule or trying to optimize gas schedule things like uh 1153 which uh which uh things that don't contribute either to scalability or censorship resistance because uh they uh

they bog us down and we are not able to concentrate on making fundamental engineering improvements.

Thanks. Uh, Ensgow.

Ansgar Dietrichs: Yeah, I just wanted to say that um I generally appreciate kind of Micah's sentiment. Um, I I think in our general course makes sense kind of being pragmatic and in compromising. I think we have a good long-term um road map where the end state will be one where it will be very uh cheap and easy to run uh your own local nodes and that is absolutely important like I would I

would 100% agree on that like in the long run the current situation would not be acceptable um but I do think that it is sensible to to be willing to compromise to some extent in in in the short run for practic reasons and I think we're decent at this. I think for example with the current gas limit there's a lot of headroom that we could have right now of increasing this and we're not and I think and that's the right choice. Um and then also with something like4 it is explicitly designed to have constant cost for not operators. So there's no growth which is the main problem with all the other um load. Um so I think I think that makes a lot of sense. I would agree that say for for fours um a lot of people want this to be dependent on a fully decentralized

uh history provider system being live um before we would move forward with this. I think this is a big mistake. I think we could we can literally like once it's implemented and I mean as we just heard of course clients would need some time but but I think once it's implemented I think we should just move forward with it um because it would be the the biggest gain for for node operators. Yeah, basically my point is I think Ethereum's course of being a bit dramatic in the short run, but we're having a very strong vision for the for the long long run. Um, makes sense.

Uh thanksgar.

Dankrad Feist: Yeah. So, my first comment is like um I wonder in some ways if this is the right forum to discuss this because this seems

about like the strategic direction of Ethereum. So I feel like um the right place to take this is the community and not a call of like the engineers. Um but um but since Mik brought it up, I do want to comment on it and I think like my first most important comment is I think like um the current um the the resource consumption is not currently the main reason why people don't run Ethereum nodes. It's UX of all kinds. Um it is of course the state um itself that you have to download that but which UX problem but like this I think 4844 is so marginal in terms of like no for for for

node operation at the moment. I mean it's will be very different when when we once we have full statelessness that I just don't see it as relevant. I don't I don't think it changes much for people who run nodes. Most people don't run nodes because it's so much more convenient to use one of the centralized services. Um, and not because they can't run uh run a Raspberry Pi. And the like the other argument here is like so what is decentralization, right? There's both like running a node, yes, but there's also using Ethereum. And right now like the cost of using Ethereum is typically much much higher than the cost of running a node. Um and that excludes much more users than the cost of running a node which mainly is a UX problem as I mentioned. So like I find I find it

weird and I think like Mika is like in a very like I mean I think already the Ethereum community if you see it on a global scale is um is on quite uh um a strong position towards decentralization like very very few other chains if you look at them are like care as strongly about decentralization as we do which I do care like I mean I'm working on many projects to make this better. Um but but the the arguments like that Mika just brought are like in the absolute extreme direction even within that community.

And so like I feel like like we have to be a bit more pragmat pragmatic here and prioritize people actually being able to use Ethereum.

Tim Beiko: Thanks. And um yeah, Martin was saying in the chat basically the same thing with regards to the UX being the blocker rather than necessarily hardware requirements. Um yeah, you had to jump. So I just wanted to share that.

Um, Lucas, uh, I have a question because, uh, my knowledge of L2 is limited, but would 4844 actually increase censorship resistance because not you don't you not only would have to censor like native Ethereum transactions, but also those blobs which

will might be kind of hard to censor because um, they they are they don't have like a fixed uh, structure. Sure, that's the question. I don't know the answer.

Micah Zoltu: I think it just it moves the opportunity for censorship to the L2 itself. So if an if an L2 is strongly anti-censorship enter anti-ensorship and they implement whatever is necessary to make that actually happen, um then I I I suspect that the blobs, like you say, kind of makes it opaque instead of transparent.

And so when someone, you know, adds just an L2, it's blob to the chain, it's much harder to notice that L2 is maybe doing something that is sanctioned or working with someone from a country that's not allowed to use Ethereum or whatever. Yeah, exactly. And now when we having multiple L2s, we increase the censorship resistant because you would have to sensor on all of them, right? Etc., etc. to be actually sensoring. Yes. And um this is I would say that as I I'll leave my comments to the end.

Tim Beiko: So if anyone else wants to say something, is your hand still up from the previous?

Oh no, sorry. Anyone else have any thoughts they want to share on this before Mic closes closes things? Okay. Uh mic up please.

Micah Zoltu: So there's a couple of responses to a couple of those the comments that were made there. Um so engineering is a finite resource. While we can theoretically work on multiple things in parallel and we we do u engineering resources that are put to other stuff is engineering resources that aren't being put towards censorship resistance stuff and that includes things like UI UX like someone someone could be building and never mind actually is to be fair working on their packager thing that packages uh beacon and execution layer

together. Um, but you know, for every engineer they have implementing 444, that's an engineer that's not doing something like that, whatever that that other thing is. Um, and so I think that we we need to consider that this isn't just like 444 specifically, this is anything that is not addressing the problem is taking away those resources that could be addressing the problem. Um, the other thing that I wanted to comment on was that I'm not, this is minor, I'm not super convinced that the costs are prohibitive. Um, I think for certain use cases, like if you're living in a third world country, you're probably not going to use Ethereum to buy your coffee. Um, but maybe you could with a payment channel. Um, but you might be okay to receive your salary every every two weeks um, via the crypto via Ethereum. And the fees are not so

high that I think that's prohibitive, especially if it's just ETH. Um, and then the last thing for the L2 situation, I I generally agree that 4844 um has potential to kind of, you know, help L2s along and if L2s are censorship resistant, that helps them become censorship persistence. The problem is is we currently have no L2s. Um, if you define L2s as something that actually gets a security from Ethereum and is not sensorable. Currently, every single L2 that is live except for one, which has no zero users, is centralized in some way, like it's got admin keys or back doors or whatever. And so I'm I'm hesitant to lean on the oh we make L2s better and then all of a sudden our censorship problems go away because currently no one is built actually building or has no one has actually

built and launched I should say an actually censorship resistant L2 and you know it's this has been like this for what a year or two now and they keep saying they're going to and no one does and so it's concerning to me to rely on that as a solution to this problem.

Tim Beiko: Thanks. Um I think you know one thing that's like probably quite doable is you know the everything that was mentioned around like the UX of running the node. Um like sure it does also require engineers to build this stuff but it feels like it's probably more parallelizable because we don't necessarily need core client devs to do this type of work. Um, so that's, you

know, probably something that's like worth exploring more like are there different dev teams or contributors that can help with this specific problem that are sort of adjacent to client teams and and not basically, you know, we're not as resource constraint uh constraint on them. Um, anything else on this topic? Okay. Um, next kind of big thing is, uh, there were a couple more EIPs that people wanted to discuss with regards to Shanghai. Um, there's four that kind of got uh, mentioned. Um, so high level, we

had the self-destruct one, 115 53, the transient storage, the BLS pre-ompile, and then um, uh, EIP2294. I'm sorry I I don't have the the title off the top of my head. Um we can just go through them quickly in in in order. Um so is uh is Jared here? I know Jared was looking into the self-destruct IP. Um I don't think he's on the call. Does anyone have an update on the self-destruct EIP?

Andrew Ashikhmin: I'd like to make a suggestion about the self-destruct EIP. Um maybe we can u list it as um CFI for Shanghai because we are considering it. And uh to my mind a good thing would be to have a blog post on uh on Ethereum uh about that uh about self-destruct that uh we are seriously considering it and if any and that that dev developers who rely on this functionality should uh should basically start screaming and uh uh highlighting their use cases and then then we can uh think about mitigations

because if if that there was one one pine contract but if if that that one is dead if nobody screams then maybe it's not a big deal. If maybe we might uh disable certain contracts but if they are dead anyway then why not?

Micah Zoltu: So so there there currently is one at least one person who is screaming like they're doing exactly what you want. We we announced that we wanted to do this and they are screaming saying this is going to break my thing. Uh oh.

Andrew Ashikhmin: Oh, can you is there a blog post or something? Uh actually check what's the the details of their smart contract and if there are potential mitigate. Oh, okay. I see the link. Okay.

Yeah.

Micah Zoltu: Okay. I mean one option is if if this is the only person that screams and this is and we do some research, we find it's the only one. I mean there is the option of just an irregular state change to fix that one um as a potential workaround. And I think I think we asked them and they said they would be fine with that. Um I might be mixing up my AIPS though.

I'm

Marius van der Wijden: I'm not fine with having an irregular state change to fix.

No, but if I understand correctly, that person is also uh I don't think we need a state change for this. He just uh like he's creating uh contracts and then self-destructing them in the same transaction. We don't need to actually change the state. That's uh we just need

to make sure that when self-destruct is being called during the during a contract creation then um it still works as it used to basically. So there there are path around doing something as radical as a state change.

Micah Zoltu: Are are you sure this is the guy that's or the person who I thought their their self-destruct was in a different transaction from the create?

Yeah, I didn't check. I know I know of a guy called Rob M. He's working for some I forgot the name of the thing. Uh yeah, I'm on mobile right now, so I can't check the the link you sent.

Micah Zoltu: And this person's name is is Rob something else, so it feels likely it's the same one we're talking about. Maybe I'm just misunderstanding what his contract's doing.

Well, if that's not the same person, then we have two people screaming, but um yeah. Okay. Uh thanks for pointing that out.

Tim Beiko: So, does any I guess does anyone disagree with the idea of like announcing to the community that this is something we're considering and having some sort of like outreach, you know, both telling them to like post on ET Magicians, but then also, you know, maybe having some calls or

whatever where we can discuss this and like understand what what breaks and and whatnot um does anyone think like we should not do that? Um if not um so I Ensgar had some comments in the chat about like moving this to CFI is probably premature um and we we might want to like wait until we have a final spec to do that. Um, so I think you know what I would probably recommend is um, yeah, quote unquote being louder. Um, I I I don't know if like an EF blog post is the right way.

Um, but definitely like at the very least we can reach out to like a bunch of projects. Uh, Matt says he was looking at the list of uh, all the contracts that sort of could be affected by this. um we can then reach out, you know, to those contract creators if if we can find them. Um so I think it is, you know, it is possible to do more on the outreach side than we've done. Um yeah. Oh, sorry. Yeah, Jared said that. But yeah, I I guess yeah, is there some objection to just doing that and uh then potentially updating the EIP with, you know, with with changes? Um,

and I don't know if this means we can do it for Shanghai or not, but at the very least we can signal that we are going to be deprecating the self-destruct. Um, and and try to accommodate um, yeah, accommodate as many of the like edge cases as we can. Okay. Uh, no objection. So, I I I'll take some time to to look into that and like uh yeah, follow up offline with with Jared as well to to try and reach out to all of the the contracts that are uh that are affected.

Um okay, next up is 11:53. Um so we have uh I believe a couple of the people who've been championing on champion it on the call. Um, Moody uh or or Sarah, do either of you want to give a quick update about where things are at with 1153 and and um yeah, we can go from there.

Moody Salem: I think Mark from optimism is

just

Mark Tyneway: here.

Cool. So, um real quick, what is 11 what is EIP 1153? It adds two new op codes in this concept of transient storage. So there's T-store and TLO. And basically what transient storage is is it's very similar to storage but it is in memory. Um the two op codes work exactly the same way as STO and SLO. um except they they write into this transient storage in memory and this um the the storage only lasts for the duration of a transaction. You know it persists between call frames which is different than regular memory and it's namespaced by accounts just like storage and both

of these op codes 100 gas. So let's talk about the benefits that it provides. So um one common use case would be using it for re-entry locks and let's look at like the data for unis swap v2 if uni v2 is using transient storage for its re-entrgency lock. So today on mainnet between 1 to 2% of all the gas used is the unis swap v2 router and this uh the the re-entry lock has been triggered 26.7 million times in the last year and with um you know 2100 gas per sled

load and we assume that there's an ETH price of 1,100 and a gas price of 50 GU that would uh you know switching to transient storage in instead of using regular regular storage it would save users 3 million um USD per or 3 million per year and not only would it save users money but it would also just save you know disk lookups like the hardware itself. Um we can also think about you know if we designed some sort of dex aggregator or amm from scratch that uses transient storage um a lot of the accounting itself can be

moved internally instead of having to do the accounting externally in contracts updating their storage. So for example we can look at um in unis swap v3 um trades that are um that contain more than one swap. So, they're kind of like multihop uh token trades. Um, in the last year, there's been 2.1 million transactions um with an average of 2.26 swaps per transactions or per transaction. So what this basically means is um we can remove calls and s stores

um from these intermediate um you know uh tokens and we can do all that accounting kind of like internally and if we kind of naively look at UNISO v3 using kind of this sort of style um we could have saved users like um you know 1.15 million um dollars in the last year. And that's just looking at UNISOP V3 like if you kind of really think um from first principles and design a DEX aggregator or an AMM using this style um you know we think that we can make it extremely cheap to kind of do like these multihop uh token trades.

Um, another thing is that the storage refund accounting is pretty complex and requires developers to do weird hacks in kind of setting values to from um being set to unset. And it kind of is this like leaky abstraction. So we think that um you know if we can convince people to start using transient storage instead we can start cleaning up the tech debt and moving away from the kind of these like hacks that developers have to do to save gas and another interesting benefit is and there wasn't consensus on this in Bogotaa but I do believe that if self-destruct is banned then when trying

to paralyze execution um you only need to rely on the storage slots being touched. So if people start moving to a world where they use more transient storage instead of storage especially for re-entry locks then I do believe that we will be able to paralyze more execution and we understand that adding additional features to the EVM will um result in like all of the ecosystem needing to upgrade their tooling. Um, for example, like there's like a lot of formal verification stuff out there that will need to be upgraded and kind of take this new feature into account.

Um, but it's like not that different from storage. So, um, it shouldn't be like it shouldn't break all the existing tooling in like a really crazy way. Um, and just note that EOF will also require the tooling to be upgraded. And kind of as a final note, 1153 has already been implemented in Basu, Nethermind, GE, and EthereumJS. And there's a comprehensive integration test suite in the Ethereum test repo, and all of them pass it.

Tim Beiko: Thanks, Mark. Mark, sorry. Um, okay, Andrew, you had your hand up for a while.

Andrew Ashikhmin: Um, yeah, I think in general it's a good EP, but uh I see it as an example of a of gas schedule tweaking. So, which might be okay, but we need to weigh costs versus benefits. If it's something trivial like warm coinbase, sure, that's a a no-brainer. It's a couple of lines of code and it's easy. But here we have to prioritize it against fundamental improvements like E44s or 4844s and um uh because fundamentally if we manage to

decrease gas cost significantly like I don't know by 50 to two times or whatn not that's a much bigger win than optimizing it by by 2% my two cents and also It will say like uh if we spend time on on on things 11 like like 1153 uh then the more time we spend on things like that the less time we we spend on refactoring our like cleaning up refactoring out code base uh making performance optimizations and so on.

Thanks uh Dra.

Dankrad Feist: Um, yeah, I mean like I don't know much about this particular EIP, but like the argument of like, oh, it makes re-entrance blocks easier. Just makes me wonder is there a point that you get 80% of the value using something much simpler like simply one flag you can set for the on a contract that's transient? like do you actually need to build a full scale storage system or is this complete overkill?

Moody Salem: I I would say that re-entrgency logs are just an easy example. Um and uh if you if you look at like unis swap uh protocol design, you can do a lot of things to like say token transfers if you take advantage of transit storage. Uh for example, when you do a multihop swap uh that means like swapping across multiple pairs um you're not actually changing the overall token balance of the intermediate tokens in unis swap. So you can completely get rid of those those s stores and those calls to that to those intermediate tokens um if you take advantage of this transient storage which is really just transient balance changes.

So, so I think there's a lot of like uh like real protocol innovation that can come from this which will just open up a lot more block space on L1 and and I don't think it's just like a you know uh like a I don't see it as just a 2% increase in in the block gas limit. It's that that also like scales to L2s. Um L2s benefit from that additional block space. So it's anything that helps L1 uh just is multiplied by however much L2's can can scale L1.

Tim Beiko: Thanks uh Daniel.

Daniel Lehrner: Yeah, I just wanted to add something from from Besso side. So 1153 is one of the very very few EIPs that has been implemented by external developers for us. And this is really something that that that does not happen a lot. And I would like the the other clients maybe also to to to reconsider that they really did the hard work and and not only just implemented a prototype for GE but also did for minority clients. And I would like to use 1153 like as a role model to to say to people look if you want your EIP included soon maybe do the same. maybe go to the minority clients as well, implement the prototype

yourself and like this maybe we really in the mid and long term we really could gain because we get more external de with de developers and like this we could really also get in more features per hard fork simply by by having more developer power on it.

Tim Beiko: Thanks. Yeah, I guess Moody or Mark, do you want to maybe just take a minute to talk about like yeah, all the implementations? I know you briefly mentioned it at the start, but like what's the state of the implementation across the different clients? Um, and Sarah just shared also the the PR to Ethereum tests.

Mark Tyneway: Yeah, totally. So I believe that um GU has an open PR right now. Um between Basu and Netherm I believe one of them is merged and one of them is still open. Um the Ethereum JSPR has been merged for a while now. Um, I do think one thing that we could do to kind of um, show that all the implementations are correct on top of having them pass the integration tests, which they already passed integration tests, is is running basically like a a multiclient test net. Um, that's something that we haven't done, but that is what seems like the next logical step

to do in kind of proving out that this works. Um, we're also working on a fun little CTF um that uses transient storage in a really interesting way that we plan on launching very soon on a test net um just to kind of get something out there and show like what's possible with using these new op codes. And we're hoping that, you know, the community can have some fun, you know, playing around with this and, you know, solving this like onchain puzzle.

Tim Beiko: Thanks. Um, DRA, I'm not sure if your hand was still from last time. Uh, if so, then Lucas,

Łukasz Rozmej: uh, yeah, just a quick here on the, um, my point of view from this PR. So I was uh I managed we we managed the PR but before that I I managed to have a very detailed um uh review and actually there was some back and forth to to to like improve some some things based on I think performance and our general I'm not sure if there was like any because it was some time ago if there was any like issues with it or just like maybe just

some smaller improvements. would have to check and I was also suggesting implementing um some tests at some point uh which were done but I haven't validated them. So I would say the main effort here would be validating if the if this test suit of course apart from each each uh client validating their own implementation validating that this test suit is um good in terms of its coverage that it covers every case and yeah running proving this with a test net would also be helpful like with external test that

that would be uh another thing that would uh ease the burden and so the question is um more in rather than like the throughput capacity problem of engineers is more if we generally want that to be included in VM and uh potentially how well tested it is rather than which in my opinion is a good candidate for like uh some future improvement that uh instead of like uh if you if you really want something included and there is a consensus that we want to include this at some point uh instead of u like pushing everything on on the core devs. If you can like um

actually provide value here by doing part of the work yourself and only leaving the validation to the cords that might be something good and something that actually helps the community, right? And yeah, that's that's it for me.

Tim Beiko: Thanks. Uh, and Marius, you had a different opinion about uh this in the chat, so please.

Marius van der Wijden: No, actually, um, I have a kind of the same opinion. Um, what I just really want to make sure is that no one uh actually believes that like only because someone showed up and did the work that this change is going to go in. I think

it's very important to validate every change on on whether this is actually a good change uh not whether it is ready. Um I think this change is actually a good change. Um I am not sure if uh it will increase testing and it will make if we want to sh schedule it in Shanghai, it will make Shanghai uh even harder to test uh especially because we have like a lot of other EVM changes uh right now considered for inclusion

and um all of these EVM changes kind of interact with each other and so we need to we need to test uh their their interaction and we need to test that everything is working. Um just from the feeling I have is I I would say this is it's not important not as important as other changes and it's uh not worth uh the increased testing effort and maybe the delay of of Shanghai for um but I'm still on the fence so I can also be convinced otherwise.

I guess

Tim Beiko: yeah, you know, I'd be curious to hear just from client teams like it seems like the rough feeling is, you know, people think this is generally useful. It's unclear, you know, yeah, the relative benefit of this versus something else. Um, but yeah, does I guess does anyone feel like we should basically give this precedence over something like EOF? um which is probably the other big change that for the EVM that's been considered for Shanghai. Um because I can I can imagine, you know, if we didn't do EOF in Shanghai, we could probably do this and vice versa.

Um so I don't know. Yeah, I'm curious to hear from client teams if that's the right way to think about it and if there's like a strong preference either way.

Łukasz Rozmej: I don't have a preference or anything but this is uh this is a lot smaller than than eof as a as a whole of EIPs. This is uh right. Yeah. Yeah. Yeah. Yeah.

Tim Beiko: Yeah. So yes, I I agree with that. And I guess yeah. Do do you think so? Say we did have eof in is your view that like we probably don't have space

for something like this. Is that correct?

Łukasz Rozmej: So I don't know what the from never mind perspective implementation is finished. So in terms of space for that there's no problem. Uh in terms of testing I haven't validated the test cases. So if someone from uh core development would do that that would give us more visibility how much uh more is needed. Uh there's definitely uh value in running a test net with it.

Uh so but yeah that's it's my opinion so it's hard to say how much effort that would be from the testing point right because if the test case are already robust then there's little work

Tim Beiko: any other team have a opinion on this yeah

Daniel

Daniel Lehrner: yeah I think from from That is also mainly the the testing effort that we've been able to put up. As I said, there is already a PR. I think we need to do some some small changes to it, but more or less is ready. But it would mainly from our side be that the additional testing

effort, nothing more.

Tim Beiko: I'm curious. Yeah, never mind. Sorry, not never mind. Aragon, Andrew, I know you were saying like this is probably less of a priority and I I don't know if there is an implementation in Aragon already. So, is this something where like you it would slow our gun down significantly or can you take also from G what's been implemented there?

I

Andrew Ashikhmin: I think we can um benefit from G's implementation because our EVM implementation is still quite uh similar. Uh yeah, I I mean if kind of also on the fence uh I would rather not do it but if the majority wants to do it then of course we will implement it as well or let's say I would rather not do it in Shanghai

Matt Nelson: right and I guess yeah maybe this is uh would like I don't know it's hard to pre-commit this stuff in the next fork.

because we things change a lot. But like is this something that we should basically try and get alongside the devets we're building for Shanghai and see if we're happy with the testing and all of that or you know should we should we basically soft agree to to do it in the next fork assuming we we can we can test it and and you know the implementations are there. Um, yeah. I mean, so to this is Matt from basically to echo what Daniel was saying. I mean, as far as the minority

clients are concerned, it's straightforward. Um, I would love to see it included in the test networks or at least in some specific multiclient tests like we're standing up for withdrawals. Uh so if the tests yeah if there's agreement that the tests are robust enough um that were just shared I don't see an issue with at least attempting right uh if it does add complexity in in light of some of the other changes to the EVM uh or unforeseen things uh with these kind of test nets uh it could be useful to push uh but again it just depends.

Tim Beiko: Okay. And so I guess um you know Sarah Moody and Mark you've been like doing a lot of work on this in the past few months obviously um if we were to say like you know let's try and add this to Shangdong uh and you know see how multi-client test nets work and and and you know if we need to increased testing coverage is that work that you can sort of own such that it's not like the core client teams who have to do the bulk of it.

Moody Salem: Yeah definitely. Yeah absolutely.

Tim Beiko: I know. So, I guess I don't know based on this, my feeling would be like we should probably make it CFI, add it to Shangdong and like see how the testing goes and assuming it's a minimal effort on the part of Pine teams and we're happy with testing, we we include it as part of Shanghai. Um, if for whatever reason, you know, we find the testing is is too complicated or that when, you know, interacting with EOF or whatever, there's some weird issue and and we'd rather do EOF, um, we can always like remove it. But it seems like if I don't know if if like the unis swap and and optimism teams are are willing to help and like champion this, it's not really a ton of additional work for for client

teams. And um yeah, it doesn't it seems like everyone sort of wants this. It's just a question of do we have the resources to do it? So does anyone disagree with that? So making it CFI trying to to get it in in Shangdong and um sort of reconsidering based on how how well that goes.

Paweł Bylica: I have like small issue with this uh because I I will not be like from EVM1 I will not be able to have combined test uh having this because that's the way where the transit storage is placed is like kind of outside of the AVM API I have. So I wouldn't be able to

participate in like testing that has both features enabled.

Tim Beiko: So this would be just for EVM1.

Paweł Bylica: Yes.

Um I don't have a good feeling.

Moody Salem: Could I ask is that like an implementation thing we can help with?

Paweł Bylica: I don't think so because like it's like on the client side have that. So I kind of need to redesign the API that's that kind of plugins EVM and

but it's like minor issue in the sense that like EV1 doesn't like participate in the test net but if like yeah it will be really annoying for me if the status like kind of have all the features suddenly enabled. I don't know how to like figure out the like the current testing with this, but so try to figure out later. I just

Tim Beiko: I guess yeah and I I don't know. I it feels like we've never really blocked something on that and also just yeah it like especially because the commitment is just to move this to the

test nets and I don't know I I would probably still lean towards doing it unless I don't know someone else have like a strong objection to that. Okay. So yeah, I I say yeah, let's let's move 1153 to CFI. Uh try it on the test net with the help from the UNIS swap and and optimism folks. Um and and and you know, try and improve the test coverage as well. Uh yes, CFI. Uh and um yeah, we and then yeah, we can see in the next couple weeks how the dev nets go and and and you know, if there's

any issues that that come up from there. Um, and I think it's it's worth again reemphasizing like ideally this should take kind of minimal bandwidth from client teams and and um if this is like a way we can get external contributors to bring your whole change in um that's that's a really valuable thing. So we should um yeah should try and get that done. Anything else on 1153?

Mark Tyneway: Nothing else to add from our end, but yeah, thanks for, you know, making space for us.

Tim Beiko: Of course. Yeah. Um, and I I I I assume you're all in uh the R&D discord, but we can use the interop channel there to to chat about this stuff and and the devets. Um, sweet. Next one on the list was uh we've talked about this many times in the past, uh, BLS pre-ompile uh 2537. Um there's like many different people championing this. Um maybe Alex, I see. Um yeah, you're on the call. Do you want to give a quick update of where things are at me? Alex,

Alex Stokes: yes, there might be boxes. Um yeah, everyone.

So yeah, I think many of you have seen this EIP in the past. Essentially, it's adding BLS arithmetic to the EVM. Uh there's like many many many reasons we'd want to do this. Um you know we could have like more secure snarks. We could start verifying any messages from the consensus layer which unlocks a ton of use cases around staking pools. Um lots of good stuff like this. So yeah, I think historically there were some concerns around implementations but I think those have pretty much all been resolved. like if there's any like concerns around stability of the underlying code you know this stuff has been used on the business layer for many you know quite a while now um so yeah so

I think uh the question now is just like do we want to push for this in Shanghai

Danny Ryan: I think an important um so chains that use BLS we could have like client support in mainet I think an very important second order effect is that EVM change would likely adopt these changes and thus the beacon chain would then be light client in there. It's kind of a weird reason to do it because it's, you know, the fact that it's on mainet would then make it on other EVM chains which makes mainet interfacing with other EVM chains potentially safer um is the argument. But there's a lot of other

essential use cases and reasons here. Um other than the fact that you know at this point this is just a native Ethereum crypto curve that we can't natively use inside the EVM. I guess yeah,

Tim Beiko: I'm curious from client teams, does anyone feel like this is something we should be prioritizing in Shanghai? Um, like obviously there's value here. We've been talking about it since the Berlin hard fork. Um, yeah. Does anyone think this is one we should be prioritizing given I guess the other things in Shanghai that we could

be doing?

Marius van der Wijden: So I actually think this is um more important than some of the other things in Shanghai. Um I would like um I think this is it enables a good amount of new use cases and I would say it's more important than things like EF or 1153. Um but that's just my personal opinion.

Um uh from the kind of the testing perspective, this is way harder to test than uh some of the other changes because it involves the I think eight or nine pre-ompiles. Um and uh we have seen in the past issues with cryptographic uh libraries. we've seen in the past the US uh issues. Um so all of these analysis the US analyses are like very old at this point. So we need to rerun them. And um yeah, so I'm

I kind of think it's it's very uh it's good. Um but I think it will like if we do this then we will definitely delay Shanghai. Um uh yeah that's my general feeling.

Tim Beiko: Uh Jared,

Jared Wasinger: hey. Um hi. Uh I just wanted to uh chime in uh and say that I had uh drafted an EIP um 5843 for uh expanded uh modular arithmetic in the EVM. Um, and it's not really a competitor or or

um to the 22537, but um just uh chiming into uh maybe ask for uh to to just say that maybe we should consider something like this to um potentially implement some of the cheaper operations that would be covered in 2537. um just as a food for thought. Um and this is this EIP is something I've been working on for quite a bit and has uh been around the idea has been around um it was previously uh called EVM 384 about two years ago.

Um, so yeah, just um saying I've been working on that on and off and um just to add that in there to ask people to consider that that as a um route to maybe also get some of this functionality in the chain with little added overhead versus some of the pre-ompiles.

Tim Beiko: Uh Marius, is your hand up for another question? Yeah. Yeah.

Marius van der Wijden: Yeah, a quick question. Um, which of the operations could be solved with?

So right now like this this the the the BLS EIP has as I said like nine uh uh different um pre-ompiles and if we could get that down to maybe only the pairing pre-ompile and solve everything else with uh the the mul mode stuff um I'd be really happy.

Jared Wasinger: Yeah. Um, so yeah, so I um I was actually looking at uh I think my uh 5843 to to answer the question um from Alex in the chat. Uh it's a draft it's a a

draft of an EIP and I I'll I can link uh more resources about it. But um I guess in short my understanding is that um uh the elliptic curve so uh scalar uh multiplication and addition so G1 add G2 add G and the G1 G2 mole um would be fairly competitive and I started to put together a doc about that that I have not finished yet but um uh I can uh I can try and release that fairly soon.

Um I know so there was an implementation of the pairing um back in when with the EVM 3D4 spec. Um but my understanding is that it's like significantly like on the order of three to four times slower than BLAST, but I don't have a I don't have a uh a pairing implementation in the current spec. Um, but I can Yeah, I can um I can uh put out some more information about this pretty soon.

Tim Beiko: So um I feel yeah, we yeah, we had a similar conversation when we were doing Berlin and then BLS ended up not making it in because of potentially doing 384. Um, is that I'm curious to hear from crime teams like do people think that's still worth sort of waiting for or or or at least you know and we can we can discuss this again in the next two weeks. We don't need to make a decision now. Um, but yeah, I'm curious how strongly client teams feel about either way of um of of of BLS.

Yeah.

Guillaume Ballet: Uh yeah. Uh I would say we're uh I mean the guest team uh I think I speak for the guest team when I say we're not a big fan of adding more pre-ompiles. Uh simply because curves change and if you have nine pre-ompiles that you have to keep maintaining forever that might be a bit of a I mean it's not great. So I think it's worth at least digging um you know into EVM 384 and see if we can uh if we can um make it work in a reasonable time frame. Um I understand BLS is here to stay but you never know like uh you know the research keeps

happening that you get more uh newer ideas better ideas. Um I think uh I think taking two two extra weeks to to consider it would not be wasted time. Okay.

Tim Beiko: Uh Antonio yeah

Antonio Sanso: just quickly same my opinion about what GM said I I agree that the curves change the point like we're using this exact same curve in in the consensus layer. So it's kind of if it changes we have a I mean if if something in research happens that make BLS 12381 obsolete we have a problem in any case right so um so for the moment we don't know we think BLS 1231 is the state

ofart curve but so was BN in the past and things changed pretty quickly but again keep in mind that this curve is used in the consensus layer by all the clients at the moment right

Tim Beiko: so I guess yeah just we're running against time. I think given that it probably makes sense to yeah spend just two weeks looking at the potential EVM 384 up code. Also um you know uh progressing on on all of the other Shanghai stuff and then um yeah we can redis discuss this I think on on the next call. Does that make sense?

Any final comments on on BLS? Okay. Uh last EIP uh that someone uh wanted to bring on was EIP294. Um and uh Zingbelv is your handle. Hopefully I pronounced that right. Um yeah. Do you want to take a minute to talk about it?

Zainan Victor Zhou: Hey team. Uh thanks everyone. Uh so uh can you hear me by the way? Uh yes.

Yeah. So just want to quickly shift the light. This is uh EIP294 uh proposes um a bound on the um chain ID. I discovered this is because I was trying to implement something and realized that chain ID was not very uh specifically uh formalized in five5 and when I dig into the history there is a bunch of it and one this seems to be a proposal for for for years. I like to know the context why it was not prioritized and it seems a simple implementation but can have a lot of benefit. Now uh what adds to the urgency is that if we are envision a uh sharding multi- uh like chain world chain ID will uh explode and I wouldn't be surprised

if people start to do things like kach something with chain ID. So adding a bounding uh as currently proposed by the previous uh EIP uh author uh was using was bounding it under 200 uh under 64 bits. So you can imagine if some people start doing kach is definitely going to break it. uh so want to ask people's thoughts about whether we should prioritize this or uh I personally feel strongly about that we need to pri prioritize making at least a decision um and then whether it is 64 bits or 254 bits is up to debate. Yeah, thanks. I'm done speaking.

Marius van der Wijden: I think it's we we don't really need to prioritize it. It's not a breaking consensus change. um we can have a soft for it and from my point of view like I don't see anyone being against this. If there's anyone against it then they should speak up. But uh otherwise we can just say let's let's do it.

Tim Beiko: What do you mean by let's do it?

Marius van der Wijden: Let's implement it in the clients and just ship it whenever like there's no for consensus. Yes.

Tim Beiko: Okay. So, okay. So then given we're going to be implementing a lot of stuff that needs consensus in the next few months. Um my suggestion would be we just talk about this in like three to six months when the Shanghai work is pretty much done.

Micah Zoltu: Does this actually need to be talked about other than just like just people saying yes? Like this is very similar I believe to the non-slimiting where currently this is effectively already in place. We just need to make it official.

We need everybody to say yes, I agree and then we're done. I think

Marius van der Wijden: yeah, exactly. That's what I wanted to say. Yeah, there's no one disagreeing then.

Zainan Victor Zhou: I I see people asking why it is 256 bits is because the word but also the bound of 64 is that if it might not break the consensus layer but it can break the application layer quite a lot because of how u the nonsense and and the signatures were calculated and yeah just like in case people did agree without deeply thinking about it I personally want to activate it but I hope that is a stronger consensus of

Andrew Ashikhmin: Yes, I I would include it into Shanghai

though it's not necessarily a protocol breaking change just to track all the changes so can kind of loosely couple of it with Shanghai for trackability

Tim Beiko: but I guess the question is should we do this now is it triv if it's trivial to do then maybe but in the chat we're sort of discussing the fact that there's way too many things considered for Shanghai now. So is is like putting that additional load on teams to do it.

Micah Zoltu: Yeah, we don't call to do it. That's that's it. There's no additional load on teams. Like no one else has to do anything for Shanghai. We just say that officially this is the rule as of Shanghai, but I mean it's effectively been the rule for all of

time. Like we could we could we could assert today that this was the case since the beginning of Ethereum. It's very similar to the nons issue. We literally just need people to agree that yes, this is this is the thing. Um, no work needs to be done, no code needs to be written. There's some probably some places we could improve some code, but that's just tech debt that clients can pay down whenever they want.

Tim Beiko: Okay. Does anyone disagree with that?

Danno Ferrin: So, just because no one's used uh chain ID over 64 bits, we can't use it ever again. I mean I I see no value in limiting this and I see don't see how it impacts mainet.

Tim Beiko: Okay then okay given that we're at time I think if there's like any amount of contention we should just talk about it offline and and try to like we can even make a decision offline once we're all on the same page. But yeah, we're already sort of at time. Um and I'm guessing the only decision we need to make is a 256 or 64. Yeah. Yeah. And once we've made that, then we can um yeah, we we we can just kind of signal it. But yeah, let's not have this conversation here. Um yeah, and that sounds good. If you want to follow up with Dano, Marius, and Ma, that's uh probably the way to go.

Um okay, I think yeah, so we're not going to have time to cover everything in the agenda. I think one thing that's probably worth covering um is we we discussed EOF and 444 early in the call before the like CFI conversations um and and like client was saying well given you know what we're doing with uh the EOF EIPs we should probably make them CFI uh 4200 and 4750. Um does any I guess does anyone disagree with and I actually before that the other part of the conversation from the chat is that it's probably unrealistic that we can do eof 1153 BLS 444 and

withdrawals on an um on on on in one fork. Um so we probably need to like prioritize for a subset of that and we can spend most of the next call sort of discussing that. Um but yeah, generally the people want to move either of these two ef um or 4844 the CFI. Um the people strongly disagree with any of that and if we can't get quick agreement, we can discuss this on on the next call.

Lightclient: I'm not sure if 4844 is in a place to be CFI yet.

Tim Beiko: Yeah. Okay. If okay if if anything is like a bit contentious we yeah let's not make let's not move it to CFI today then um but I think we should move the EF ones to CFI. Yeah.

Andrew Ashikhmin: Yeah. I agree. I think because we all the consensus is that in favor of the big EF. So they should either all be in CFI or none of them should be in CFI.

Tim Beiko: Okay. Does anyone So, and and to be clear though, there's the two I think we should move to CFI are 4200, 4750. Uh, does anyone disagree with that?

Protolambda: I disagree. I see arguments that to take

all the EIPs and then force a decision where we only do one or two of them. But then I also see arguments that okay, these are ready for CFI. So, so and so on. And as a result, I think the other EIPs do not get sufficient discussion and might never reach CFI just because of these

force decisions that we rush. Anyone have another strong opinion on this?

I

Greg Colvin: I think it's been clear for a long time that the stack validation's essential. So if we're not clear on that, I think we need to take it up at the the next EOF breakout.

Tim Beiko: Um yeah. Okay. So I think yeah, I think I would rather have this discussion next time with like more time on the call. Um I think it's you know we are working on 4200 and 4750. So I don't think them being CFI today changes how much like progress is going to happen in the next two weeks on them. Um and and yeah, I I guess like just for client teams and other folks to think about in the next two weeks, I think probably the main thing we should try and figure out in

the other call is like given the testing and implement stat implementation statuses of um all the things we discussed today, you know, what is the subset that we think is highest priority to to consider for Shanghai? Um yeah, and we can sort of spend more time discussing sort of these these five or so things that we uh we touched on today. Um and yeah, and then there were a bunch of links. So um so apologies we didn't get to them, but Muel had an engine API spec improvement proposal. So if people can review that also before the next call, that would be great. Um I think for DevNets, we don't really need to change anything in the next two weeks. Um, and

one thing also that's probably worth it for client teams to look at is the new test framework that uh Mario put together. So this is linked in the agenda. Um, and finally on the other call uh we should discuss uh a sunset date for Robston. So it's already been deprecated but uh yeah when we want to actually shut it down but that can wait two weeks. Um cool. Thanks everyone and see you all in two weeks.

Thank you.

Bye. Thanks. Bye. Thanks. Bye everyone. Thanks. Bye. Bye. Recording stopped. [Music]

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