All Core Devs - Execution #157

Transcript

[Music] foreign [Applause]

thank you

Tim Beiko: okay uh good morning everyone uh awkwardness 157 today we have a bunch of things on the agenda uh the first ones are around

Shanghai so we saw a chappella go live on Gordy um then we can recap that figure out if you want to set a main update um today uh then uh Terence and POTUS had a PR around a local uh local block building um so makes sense to go in over that after that uh I've tried to basically list out all the stuff that's been proposed for Cancun so far to kind of give people a picture and we discussed SSD last time and wanted to come back to it and then there's kind of all these other things that have been discussed so I might be worth if not like touching on every one of them at least the biggest

ones and and um at least putting it out there so people know sort of what's being proposed and we can start having those conversations um and then we'll try to keep a couple minutes at the end uh Puja I know catharters have put out a report around uh El client diversity and just um yeah basically what node operators feel they like and dislike about the various clients so um yeah I guess the kick off uh so we had the Gordy Fork this week uh does anyone want to give a quick recap of how things went and if yes thank you any anyone else have any

thoughts they want to share about Gordy or yeah anything they noticed beyond that okay uh so if not uh it seems like it went relatively well and so I think we can probably set a date for mainnet um I had proposed three in the agenda so I basically April 6th 12th and 19. there's a couple comments in the chat around April 12th uh yeah does anyone I guess you know does anyone think we should not do April 12 otherwise we can we can go for that I picked out and Slot

an Epoch number I'll copy paste them in the chat um that I'm 90 sure 99 sure end up on a historical Roots boundary I'll double check it right now but um yeah uh oh and there's a comment in the chat about hearing from base you um so just basically have any issues if we okay okay embaris in the chat about like it's in the

evening for the EU and um that's unfortunate uh but if we wanted to cleanly map to like a a historical Roots boundary it needs to divide by 12 by 8192 sorry um so this is always kind of a weird time and you get like one of those every day and a half or something oh uh oh damn

uh oh okay okay sorry I know yeah I know it's wrong sorry um thanks

obs oh can you speak someone not me oh okay okay it's working now okay so sorry about that people on YouTube um let me just post a comment um so I'll just really quickly recap and we can upload the full Zoom uh later today but uh in short Gordy

Tim Beiko: went well saw a drop in participation because of unupdated clients but um even regardless of that uh BLS changes and withdrawals went well um and the network reach finality and

then everything was fine and we were we were just disgusting uh we were just discussing uh the fork date for mainnet um it seems like people like April 12th uh so the comments chat reflect as well um and we were about to start talking about like uh whether or not the time can be a bit better but it seems unlikely because we need an uh historical Roots boundary which happens every like 27 hours sorry YouTube um but yeah April 12th uh is what's being discussed right now so I guess

yeah this current Epoch is late for Europe um how big of a deal breaker is that we can always go like 27 hours later which we did later yes which would be like the 14th or something

um you know that would be later in

Tim Beiko: well oh yeah actually yeah it'll be worse it'll be like you know plus three hours or something

Danny Ryan: so yeah there you go you got a day before but also it's kind of nice that we have this forcing function that slowly rotates and would be different next time so that yeah we get a nice distribution across time

zones

Tim Beiko: okay we'll get another mine some energy

drinks any objections so this would be uh Epoch uh six two zero nine five three six on a mainnet okay so cool we have a date for chappella um we'll give teams like a weaker you know so to put out releases I think it would be nice um like ideally if I'm the next uh on next week's uh call we could like have the team releases out um so we can announce them there but then at the very latest I think if like early the week after that we can

um put out the announcement that would be great um so that'll give people like a proper two weeks to upgrade yeah so from today I guess you know we have uh one two three three and almost four weeks uh to the four key anything else on chappella okay uh if not next up uh Terence photos you had uh PR you wanted to discuss I'll post it in the chat but if either of you want to go the floor is yours

Terence Tsao: yeah sure uh I can get started put this

feel free to um add if I miss anything so basically one property that will be really nice for um this between a CL and the El interaction is that the El it basically determines how CL um proposed panel's blood space um some sort of censorship recipient uh metrics or uh monitoring basically you can look at mango and look at just transactions to see whether based on certain things to determine if the transaction is Monitor to determine the transaction is being censored and the one nice thing about this is that it's not required in a way that if the El

doesn't implement it El can just return us no and then if you still doesn't want to use this CL doesn't have to be use it so right now it's right now it is like phrase us completely be optional but yeah but anyway the pl is out there it's open for feedback and yeah I know we also have a prison implementation here as well I mean on the CL side it's relatively simple to implement I guess the majority of what will be on the El side but but like I said this is uh this this creative phrase us an optional thing

Danny Ryan: I'm pretty supportive of this like it's

a very small change that can then be very much iterated on um by Els and CLS as they see fit and really does open up the design landscape to try to ensure that we have censorship resistant and other potentially nice properties of how the mempool is being utilized

uh Lucas

Potuz: I have talked uh I have talked with some El deaths and some CL debts and got some feedback uh that I wanted to mention here everyone on the El side told me that it would be absolutely trivial to hard code of Falls in that return which means that they

could just immediately implement this and on the CL side there's no change that is actually needed so so I think it's from everyone that I've heard I've heard that it was absolutely trivial to implement this and I've got some other some some feedback from the CL folks saying that they would be allowed to either use it or not use it and actually there's some diversity as to how to use this which also makes me happy because uh having diversity on on when we're gonna fall back to local execution or not is something that is quite interesting in itself

thanks um Lucas did you did yes yes so

Łukasz Rozmej: um yeah but this is just the first step right and in order to for it to make any

sense to to be used in the future we need to also think about the heuristics we would potentially use just even like discuss them because we can add them and not never use it right or or use it in some

Potuz: can I can I list the ones that I had in mind I mean you can add as many as you wish and you can have them configurable or not I just focused on like the stabbing of Falls because uh if we manage to implement this right now then we will avoid bumping a version on the engine API that's if it's absolutely trivial then I would be in favor of implementing this right now but as for the heuristics the one that I listed in the sites I think are are sort of like the more most Dramatics for the kind of

implementations that I have in mind one of them is if you have seen a transaction that is constantly being reward whenever this transaction appears in a block then that block is reordered then that's a very strong indication that there's censoring going on uh there are other heuristics that you can apply if you have seen a transaction that is paying twice the current priority the fee and that transaction is not has not been included in three blocks we still valid it's paying twice as much as any other transaction then you should include it and then you should fall back to local execution uh if you have seen some something that worried me and the reason why I'm opening this PR is that uh the flashbots community so is going towards uh having

the relayer not check the the execution payload uh this is something called optimistic uh optimistic debris layer and this screws up uh some statistical analysis that I wanted to do on censorship and the reason this screws up is that we may see some some blocks that are invalid that obtain that contain transactions that could contain transactions that were sensors so that's another heuristic if you see one transaction that whenever uh it appears in blogs that block is invalid you should also fall back to local execution but I'm sure smart people will come up with with better weather heuristics uh or combinations of them

thanks um Iraq and then because

Marek Moraczyński: quick

question right now do you mean before Shanghai or uh what do you mean by right now

Potuz: that's that will be optimal if if it's absolutely trivial as everyone has told me we could do this in less than one day and have it in the next release and test it even in devnets immediately uh if it's not possible then I don't mind any any delay because uh I think this is very simple so you can it can be shipped later but the thing is that this would require uh more complexity because we will require like bumping the engine API and then coordinating what I mean either using on the CL side uh an end point to check that the endpoint is supported on your El or other sort of complexity combinations

if it's if it's absolutely trivial then I think it's easier to just for us it's absolutely triggered because we don't need to do anything and then for the AL if for DL is just sending a folds it's trivial then I would suggest to do it now

Łukasz Rozmej: so um one last thing for me that's um so in generally I think I'm far but that I don't like um that it creates another like complexity on the El and another responsibility on our side to to implement maintain and um have this heuristics and this is potentially something that could be done even outside of el right it doesn't have to be inside of VL and

integrated in the API that's the question that doesn't make sense to have it in the

I

Potuz: I can reply as to why I think it's the Yale is the right place uh and the reason is the reason I I wanted to do this is when I realized that you can unchain uh with very mild assumptions assume like with probability of like one in a million that there's been no censorship if you know that two consecutive blocks haven't been missed and this can be verified on chain within with the assumption that uh the validators will fall back to local execution when they see censorship by poor people

and the only the only way that I can see how to do this is if the CL has access to the

memo

Łukasz Rozmej: but uh one one more question but this is basically optional functionality on both CL and the layer right so El can also always return far pulse and seal can always ignore even if it's returned true

Potuz: that's correct but just the fact that that this is a possibility allows the theoretical assumption that certain percentage of validators will be using it and with those assumptions you can actually prove things statistically which if we don't have the option then you cannot prove anything I think this is a big big difference in ux for me

Tim Beiko: so I guess there's a couple comments in the chat about you know being supportive but not for uh Shanghai so I guess it seems unlikely we would get this in now um does it make sense to continue the conversation on the pr itself if it's something that's not going to happen uh like in the next couple days anything else on this before we

move on

um so I guess next up Cancun um so I went over to eat the magician's thread yesterday to try and like look at all the eips that have been proposed so far I've updated the each magician's thread and also listed them on the agenda here and I guess uh the obviously as well is 444 is the only thing we've officially included so far um so that's uh that's you know something you should take into consideration when when talking about Cancun and maybe the first thing to cover is um all of these SSD proposals um so last week or sorry two weeks ago we discussed this a bit on the call as well but it seems like teams didn't have a ton of context

um but basically because we are introducing SSD as part of 4844 um on on the execution layer um it's for figuring out do we want to introduce more at the same time um at the very least what is the format we want to go with so that even if we don't introduce more SSD objects um whatever we do introduce in 444 is consistent with what we'll introduce in the future so I don't know if any of the client teams have had time to look into this in the past couple weeks if anyone has any kind of updates they want to share on this okay so I guess

so oh yeah yeah

Marius van der Wijden: each and I kind of had a discussion I think it was it's two weeks ago now uh about this and we kind of came to the conclusion that we're trying to optimize for different things yeah it was in in the Discord and hashtag Charlotte data um so I think my focus was to make the the transaction as small as possible while his Focus was to make it as

easy to verify by like clients as possible and um yeah I I that that basically there are two different ways we can do the SSC format or the at least two different ways proposed and one is smaller and one is easier to verify and so we kind I think we kind of have to make a decision what we want to prioritize

Tim Beiko: got it uh Lucas you have your hand up is it

Łukasz Rozmej: yeah so um this um they're like well because this is about only um this is seeing the roots right but the question comes up should we assess ZD storage and network formats too might be easier to to have just one uh one format and uh or maybe we shouldn't maybe we should keep it in the rlp right so it is right now so that's the question and the other question is um how does this affect Cancun timelines right because if we are cramming more and more and this is not trivial uh in my opinion then yeah it depends when we want Cancun

to comment

Etan Kissling: the network format is is not really does not really have to be bundled um it's only about the storage format for actually not even the storage form at this point like everyone can store the transactions how they want um the format that is a fact that is how transactions are represented as part of the consensus execution payload and the size difference that Mario's mentioned is primarily because um I mean one of the goals is to allow clients to use Json RPC

while having a way to verify that what they receive is correct and there are three items in there namely the transaction ID the sender of a transaction like the from address and for transactions that deploy a new contract that contract address those three items they are currently not part of the raw transaction and they can be computed from the raw transaction with the SEC p Aid public key recovery and some rlp and some ketchup so if we want to include all three items

they either need to go into the receipt 3 or into the transactions tree the size differences are mainly if we decide to put it into the transactions tree then of course the transaction that includes the extra information is a bit bigger than the and then the other one but the receipt is a bit smaller and if we do it the other way that we put this extra information into the receipt then the receipt is a bit bigger one way than than the other so ultimately the total size is probably comparable but it doesn't affect the networking that one can still be rlp if

that's what people want but it means that you have to convert back and forth between one representation and the other whenever you receive a message and when you send it

Marius van der Wijden: and this conversion is is kind of costly actually so we try to have as little conversions as possible so we store the transactions in the same format that we send them on the network

Etan Kissling: okay I mean then then we can just update

the network to exchange that in the same format as well um to avoid the conversion but then I mean either the receipts or the transactions are getting a little bit bigger in like depending on which one we choose there is also one conversion that we cannot avoid it is when we convert from a transaction before like a raw transaction that's in a mempool that one is using whatever format it originally was signed under so that one cannot be changed that one is always an rlp or it's this block transaction with

the network wrapper so when those are bundled into a new execution payload they need to be converted a single time and when they are validated as part of new payload they need to be converted back so that you can check the signature against the original representation so there is this during new payload and when bundling a new block like new payload get payload where the conversions cannot be avoided regardless of which SSC format we choose

Lightclient: I think that's okay because we already have to do that to calculate the Sig hash anyways

Tim Beiko: um oh sorry

it didn't even finish it no no I just wanted to say Danny has his hands up yeah okay

Danny Ryan: thank you um I'm curious before we go deeper on the technicals here and start talking about decision points um have we done an analysis or an Ask of the community as to what this is going to break and imagine it breaks tooling to a decent amount and then it certainly will break some on-chain contracts which I imagine many of them are upgradable for example some l2s but are there like have we done analysis of like is there anything fully breaking by doing this transition um which you know not to make a claim that we must not break anything but I I

think that to make a decision about how to proceed we need to know the answer that

Etan Kissling: the only analysis that I made there is to see whether like what what the use cases would break um Json RPC would still return the exact same data it could just be extended to also include the proof that it's actually correct but if you have applications that depend on the current Miracle Patricia dry root those would essentially break because that Legacy route will will be removed I'm not sure how to gauge which projects

are affected concretely I hope that the high profile ones have a mechanism in place to upgrade if they depend on this functionality

Danny Ryan: right and like I know l2s that do do have such a great functionality it it's at least uh worth at this point if we're seriously considering this like yelling into the void to see if anyone comes up with something that we can't uh match Yeah Tim I'm there might be some automated analysis we can do here but it's hard to catch everything because this is like a relatively you know using utilizing proofs against the root is like not obvious to yeah

Tim Beiko: okay that's what I figured um so yeah we

can definitely make a call uh for people to to show up if this breaks things um and yeah it might be worth looking if there is some sort of fancier way that we can scan you know potentially transactions in the last year or um yeah what's been deployed uh Peter

hello

Péter Szilágyi: uh just a very very slight diversion so previously it was somebody asked whether it makes sense to bundle this together with uh Cancun with 4844 or not I just wanted to react to that in my opinion based on just the discussion of the past

few minutes you can see that this is a very very deep rabbit hole and uh I do think um essentially it's we really don't want to harvest this so if you want to I think the advantages are super nice and but the question is what do we want to transition over and my two cents would be to I don't see this going in along with 4844 I would much rather just gather everything that needs to be done so that we can roll this out in one big go and update everything that's needed and I think that's a completely separate effort and it won't really fit inside one problem

Marius van der Wijden: like yeah but one thing that

we should like just be aware of is that we that the plot transaction is kind of written in a way so that it's that is also kind of upgradable to to this to this new version but I guess if we do the club transaction similar to how we do the other transactions then it should

Tim Beiko: so are you saying I'm not sure I understand if you're saying that we need to be sure of the format today because blog transactions will use it or are you saying that like it's fine to change the format of blob

transactions in the future and basically

Péter Szilágyi: yeah I think Maurice was trying to say that uh since blob transactions are already introducing partial depend also introduce independencies and SSE let's make sure that whatever block transactions do will be compatible with okay

Tim Beiko: yeah the final dream yeah yeah I and yeah I agree that's like the minimal decision ideally we would make is um even if and we might not have a hundred percent certainty here like there might be a format that's like better or worse for some reason but like if we can have some confidence that whatever we

um we Implement an SSD for 4844 works and is forward compatible then that's better than having to like re-change it

Etan Kissling: yeah uh there are um three parts of this proposal and I think for each of them it can be decided separately when they should be included um the one that has to be in Cancun if um if the blob transaction is assassed to Signature scheme like eip6493 because we need a signature scheme that cannot ever conflict with a future transaction type that we

introduce or with an rlp transaction type and the other one that's kind of orthogonal is the withdrawals root that one um the idea was to already convert it with uh with sharpella and that one was only delayed because um it was already late in the cycle when this was proposed so that one can be moved into Cancun without any controversies the only one that is controversial is transactions route and

receipts root and

Péter Szilágyi: I wasn't really referring to controversial controversy I'm referring to Simply work and making sure that

nothing blows up so my main issue is that 4844 is huge and anything that's sufficiently complicated beside it will be really messy because people will need to juggle to very complex things at the same time

Tim Beiko: right but I guess what Ethan are you saying is that like we need a signature scheme for basically because we introduced 444 which is an SSD type so we need some signature scheme that we agreed to in order to make sure there's not like conflicts with future transaction types is that correct

Etan Kissling: yes

um that let me I mean the signature scheme is for transactions in the main pool so that one is um regardless of how you format the SSC transaction later as part of the execution payload um you need to know how how do we sign those transactions and I mean it it it's probably good to have the same signature scheme for all SSC transactions even even if the individual transaction payloads can be whatever I mean there is no reason to align those before they are accessible through apis

Tim Beiko: got it

and

Péter Szilágyi: can't we just so currently

4844 is back to use the SEC p256 uh signatures and can't we just keep those and then whenever we do this uh SSD switch over then we also switch the signature scheme is there a specific problem with doing that

um do you mean like keep it at K track of 0x5 plus SSE encode

Etan Kissling: um one issue with that is if it's SSC um you start getting problems when you look at it across different networks including private networks because with

the SSE transaction the chain ID does not always end up at the same offset as it would if it were rlp encoded so you can have a signature on a private Network that is type 5 but some rlp format that accidentally serializes to the same hash as the SSE transaction on the main net for type 5. I'm not sure how big that risk is if but it could be that if both are using the same hashing and the same transaction type are different encoding strategies like SSC versus rlp

that there may be a conflict

Péter Szilágyi: I'm not really following because currently the with typed transactions essentially the first bite is the type

Etan Kissling: yes yes but that one is Network specific someone could create a private Network like a layer two that's ebm compatible and they could Define their own type 5. maybe they already have a type 5 and we don't know about it and someone signed transactions on it and uses the same key on mainnet as well um it's only across networks where you

have those problems

Andrew Ashikhmin: but it's like hash Collision which is supposed to be extremely rare so I guess it's like the probability is very low not hash

Etan Kissling: um it's the it's the serialized unsigned transaction that could Collide and that one is not a mathematical property it's just um you can construct an rlp object that has the same encoded value as an SSC object as an SSC encoding of a different transaction

Péter Szilágyi: yeah I mean that's sounds exceedingly

improbable to have an rlp something be valid both as an rlp and SSE decoded stuff and be actually meaningful

Etan Kissling: sure I mean that's that's the open question whether whether that is a real risk or

Tim Beiko: um just based on this conversation um does anyone feel strongly I guess that we should do like the the the you know

quote-unquote fall SSD overhaul as part of Cancun or is this more about finding the minimal set of changes we want to do that are forward compatible and basically with uh Peter was was saying because that can help just kind of prioritize like the future discussions where obviously we want to understand the full implications but there's a difference in do we start implementing this wholesale now or are we trying to find the minimum we can we can do for Cancun uh Andrew

Andrew Ashikhmin: uh I would concentrate on the minimum because we have to weigh uh the like I agree that with Peter that it is a big change so we have to weigh the benefits

of the SSD overhaul versus the other potential candidates our throughput is as developers is limited so

Tim Beiko: okay yeah and plus one from never mind we probably can't take a decision on the exact format right now but I think if this is something that teams can look into in the next couple weeks that would be good so we can start aligning on what's like the right minimal scope for SSD for Cancun yeah does that make sense so like do you think we need a I'm I'm

cautious about like the breakout rooms now because it feels like there's almost one every day but do you think we need a separate call to discuss this or can we have teams review it async in the next couple weeks and you know potentially discuss it on the next all core devs

Etan Kissling: I think that's fine like just discussing it as part of

Tim Beiko: the ACD yeah xacd is like there's been literally zero progress that maybe we can schedule a breakout room but yeah Okay so uh like Andrew was saying I guess uh there are a lot of things being

considered for Cancun um and yeah I I wanted to list them here and it's probably worth going over them kind of quickly to at least share kind of status updates and and get some sort of temperature check from different teams about the efforts um but high level you know there's everything around self-destruct um the evm max proposal uh solidity had proposed uh eip663 which is this unlimited Swap and dupe instructions um we had EIP 5920 which we discussed quickly last time the payoff code and there's everything around eof uh obviously 1153

um and Moody had an update about the status in the agenda and then and the two editors that came up last time were the BLS pre-compile and the beacon State Route up code um so this is roughly everything that's uh I believe that the yesterday was was proposed

um I guess on the self-destruct side uh I don't know if anyone has an update here uh we did have this like deprecation warning as part of Shanghai um so I'd be curious to see if you know how strongly the people feel this is a priority um yeah where where do people think we are in terms of specs and whatnot Andrew

Andrew Ashikhmin: uh I think that removing self-destruct

is very much a priority so uh to yeah we would like to do it in well as early as possible uh I was also thinking that there was this analysis by Jupiter who suggested that there was one um one smart contract fine core using self-destruct ephemerally so for a contract was created and this is self-destructed to within a transaction so if we just keep that special case if we allow to keep self-destruct for so if we keep ephemeral self-destruct and deactivate non-ephemeral self-destruct that might be a nice compromise I don't

think we have a nip but if people here agree that it's kind of a viable option then I can create a name or somebody can create a nib but in general I think the removing self-destructure stop priority

Tim Beiko: okay anyone else have thoughts

again oh

sorry accidentally raised my hand uh yeah I mean apart from the fact I also think it's a priority um yeah not much to add sorry

Tim Beiko: I guess

maybe one question for you while you're on uh muted like to be clear so say we wanted to do vircle trees and you know not Cancun but the fork after that we need basically self-destruct to be removed prior right like it would if we didn't do this in Cancun it means at the very least um we would push out vertical trees another Fork right

yeah exactly and I will probably spontaneously combust as well um no yeah if like self-destruct needs to happen in Cancun um otherwise uh yeah their groceries will be pushed indefinitely because there was there will always be something

uh to come before

Tim Beiko: um and yeah so I know there were some proposals around like basically what Andrew was saying kind of allowing some sort of ephemeral transactions uh to use self-destruct uh I know Alex from Epsilon also had uh some proposals so um I think that would probably be like the most important thing here in the next like couple weeks is if we can come up with like a spec for something that does deal with the multiple edge cases that doesn't you know break the contracts that use um uh that that use it the most and and that are like most popular today with um and have an actual thing we we can

look at we did review a letter spec last call and uh there was a lot of um uh there was a lot of like complexity in it so um yeah it does feel like something where having a clear spec is the main blocker but assuming we had that I assume people would be pretty on board with uh moving forward with it um do we have a self-destruct Channel or something like that I wonder I guess we could use the execution Dev Channel at the verities to discuss this in the next couple weeks um if we don't have a self-destruct one uh yeah

okay uh

next up uh Evia Max uh I don't know is Jared on the call uh yeah you're here hey you want to give us an update

Jared Wasinger: yeah hey um I I'm just joining um I just wanted to um just raise awareness um so recently I uh or in fact yesterday I posted um EIP 6690 on ethereum magicians which is uh just a variant of uh 6601 which was the latest uh uh proposal update update proposal

um in 6690 is um the attempt to decouple the proposal from eof um not to say but um basically the um it would be great to get more people just like clients specifically like potentially looking into implementing this and I think a great start um would be uh 6690 uh because I think that's the easiest to implement um but eof also brings benefits I think that I would say

um like as far as advantages go I mean um if you compare it to something like eip2537 of course you're not gonna be able to uh Implement BLS operations as performantly as pre-compiles I mean that's kind of obvious um but um we get several other benefits like for example like I've noted in um in both of both of the recent eip's um this would basically allow us to replace the modex P pre-compile for all of the inputs that I've seen it used on when

I've scanned the chain and then um other things like the ZK friendly hash functions such as Mimsy for example the I am MC and it was 80 faster or 80 percent more uh cost 80 cheaper than the zircom lib implementation which was being used in production by tornado cash so I would just say like just to sum up it would be great to get more eyes on this and if we do or don't want to move forward um yeah yeah it would be good to

to hear something

Tim Beiko: any thoughts comments on evmx okay and then uh yeah so I linked both uh both your two new proposals in the uh in the agenda Jared so people can go and and comment on that async

Jared Wasinger: cool great

perfect

Tim Beiko: thanks for the update uh and I guess oh Marist do you have something to say

Marius van der Wijden: yeah so okay one thing that I would like to highlight is that uh Eva Max is not only cool for

BLS 12 381 but can also be used in a bunch of other use cases I think we should even consider this even if we decide to to implement the BLS pre-compiles I think the like the BLS pre-compiled which we probably will talk about are very important and much needed but uh evm Max or like modular arithmetic on within the evm is something that is

that has a lot of use cases Beyond on the the BLS pre-compare uh yeah that's a good point

Jared Wasinger: I probably should have mentioned that as far as I could tell you could and maybe somebody can correct this if this is wrong but as far as I can tell basically any elliptic curve uh could be implemented with this proposal um and another thing to consider is that if you have a higher a higher uh width base modulus like I know there's some curves that are like at like 768 bits or more um as far as I can tell this would

actually be like pretty close in performance to what you could hypothetically get with a pre-compiled just because um modular multiplication has quadratic complexity so um I mean yeah but yeah I think yeah good point

Marius

Tim Beiko: yeah and I think like several years ago we had a very similar discussion around I think this is the Berlin Fork where we discussed BLS versus evm 384 at the time and like um I think and there was like a similar you know concern around like should uh should we do one or the other and we

ended up not doing blf because evm 384 might happen soon and I think it probably makes sense given the uh importance of like BLS to like consider um also separately and even if there's like redundant functionality um that might be one of the few cases where it's worth it relative to delaying BLS if uh if we aren't going to do evm Max at a later date yeah

Jared Wasinger: yeah I guess just from the user's perspective what really would be the difference I mean you're saving a bit of math a bit of gas but um like what uh it it would be great to quantify uh and

maybe like extrapolate out from like how people like are currently using BN 128 and just like I don't know assume that they'll just move to BLS and then like extrapolate out exactly what we're getting in terms of savings overall with with pre-compiles right which is hard because I don't have all the evm max operations or all the BLS operations implemented at evmax but it's fairly easy to to guess how much they'll cost

Tim Beiko: right and and I think the maybe another way to Frank this is like assume we do blf in the next Forex and evm Max in the fork after you know what's the benefit of

users to have access to BLS you know six months 12 months early right and maybe they eventually moved to like using it natively in evmax or something but that's I think that's the other trade-off that's like worth considering is um if we do both but not at the same time you know is there like and you know one way to ask this question is like if we how would things be different if we had had BLS in like Berlin you know several years ago yeah regardless of just like the raw gas cost I guess

Jared Wasinger: um well if it's if it's not factoring the raw gas costs when Eva Max be

strictly like disregarding the raw gas costs wouldn't even Max be strictly better in that case because you can I mean you can just Implement more stuff right

right but but if you get it if you get BLS sooner right that's the thing I mean um yeah yeah like that's the the cost is like not just the gas cost of like each call but it's being able to use it and you know six months versus 12 months

Jared Wasinger: yeah yeah I mean I'm biased but I I would say Vmax is uh it seems simpler to me than BLS um and I would implore people to take a look because it's real like really not that complicated I I just lifted a few

like all I had to do was like adapt a few hundred lines of assembly code from blast to get the most performant implementation anyways okay yeah

Tim Beiko: yeah I'm cool yeah uh just want to be mindful of time anything else on evm max okay yeah so we can continue that discussion uh on on the threads um and then I guess uh the two things it does touch on is eof so uh and BLS but does anyone have an update on eof was like when on a call

Oh I thought he was for a while oh yeah yes I'm here okay

I

Lightclient: I don't have much of an update honestly I haven't been working on eof I've just kind of been running the eof breakout rooms which we've got another one scheduled for next week um yeah I don't know EF eof 1.1 is kind of uh taking in a lot of the thoughts around the discussions in Austria and what eofv2 might look like and that's um sort of coming together and I think that they've got this implemented in guest now I just haven't followed it super closely in the last couple weeks

Tim Beiko: what's the best place uh for someone to follow the latest on eof

like if they want to just yeah understand probably the hashtag evm Discord

Andrew Ashikhmin: I have a small technical suggestion so if we want like eof whatever 1.5 or whatnot with uh with Alex idea of non-observability uh that will be quite different from eof1 so my my suggestion is to for ease of referencing create a

single Eep for this new eof so that we have everything that we want in a single release in a single

leap

Danno Ferrin: yeah so there's multiple facets that are easier to understand and see leaves but I think a single combo even says point to these five is probably what we might wind up getting um because some of these are fairly um separated and we put them together in one giant document and it looks like impossible but to break it up into the five key component parts and it's actually you know the the sub sum is the whole is greater than the sum of the parts um I think you know we could write one that would help help add to it

um but I mean like the stuff like the observability I mean it's the current plan we're going to stick with where we that's still a discussion if we do the one one in Cancun and the 201 Prague we're in one one we remove key features that um would be necessary to preserve observability in Prague we would ship the um non-observability preserving versions of things that we're taking out um you know it's I I think a giantic would obscure some of what we're doing and the step work in there and make it harder to explain so I I appreciate the need for to be able to get your hands around the full scope but we still need to have clear seat you know that the structure of Eep does not really lend itself to like you know five

different subsections because there's like one big you know the rationale and the implementation are often tightly coupled so yeah we should have a Cabo eat to point to the sub-components but I don't know if a full Leaf of everything together is going to be a good idea

Andrew Ashikhmin: understood

Tim Beiko: um anything else on EOS now okay uh so I guess maybe next up we did touch on this already a bit but BLS pre-compile I don't know if there's anything that add here we've discussed it several times but in case there's any

updates or comments people want on this

Alex Stokes: yeah I'll just say that uh kind of echoing what we said earlier in the call you know this curve is really important to ethereum so I would really strongly suggest we consider shipping the pre-compiles even though there's very exciting work with evmx um you know we could go ahead and get the curve today and then when CB and Max is ready we ship it and you know there are plenty of other use cases where are you being Max to be on this that are also really important but you know this curve is used on like this is hilarious so it's just uh something we should do ASAP in my opinion

Tim Beiko: cool

Danno Ferrin: uh

the one thing I would ask if we do that is that we take another look at the gas prices um we did Berlin we priced it against a gas metric of 35 million gas per second which is about um 28 nanoseconds per gas um performance wise that that provides an upper limit as to what we could expect local clients to to perform um and it makes a BLS not the the the BLS ones that is the lowest point in in the whole EDM architecture in capsis at 35 for a lot of performance considerations I can explain why that's gonna be the case but I prefer if we were to reprice the gas on some Assumption of something more like 50 gas per second 50 million gas per second um which would result in higher gas

prices but at the same time would allow um the the conceptual maximum throughput of the evm to increase up to 50 billion

Alex Stokes: yeah I think it's further visiting EIP um especially if you want to like very seriously consider it for Cancun the question I have since we're all here does anyone feel strongly about the cip2537 having like a large number of B compiles versus say just one

Marius van der Wijden: yeah I kind of do

um I

Alex Stokes: I'm just wondering because like it'd be pretty easy I think to rewrite

the AP where like you know basically there's a type switch in the first bite um and the question then is like is one more palatable than the other

Marius van der Wijden: what what do you mean by having a type switch

Alex Stokes: well just like rather than say like nine EIP or sorry nine freaking piles you just basically call one pre-compile but the first byte says okay this is an ad this is a mole this is a pairing whatever

I

Marius van der Wijden: I don't care about that but I think maybe we should think about not doing all nine pre-compose uh how many of them can

I I actually need it

Alex Stokes: all of them I think if anything we actually should add two more

Marius van der Wijden: I don't like that yeah okay

uh Dan crowded said sign up oh yeah I

Dankrad Feist: just wanted to comment on the gas costs because uh they like if the benchmarks were done two years ago I think the BLS libraries are also significantly faster now so it's likely gas costs from back then would be an overestimate rather than an estimate now even if we want to Target 50 million gas

per second or rather what's been done recently I think is more just compared to existing um pre-compiles and of course right

Tim Beiko: then it's probably pretty easy to re-benchmark them because we just ran benchmarks on every clients for the 4844 pre-compile so it shouldn't be hard to do it for BLS as well

uh Dano

Danno Ferrin: so I would prefer to keep all nine or possibly 11 pre-compiles uh one of the reasons is right now pre-compiles they do one thing each pre-compile does one function and we don't have any pre-compiles that have like a switch bit to do different things based on what's coming in

um so we would also have to test in addition to the nine or eleven Forks coming out pre-compiled we need to write test cases to test the switching logic which would increase the testing load it's not necessarily that bad but I think the real concern there that I have with it is by putting them all into one pre-compile we're masking the true complexity of what's being asked to implement this and what it really means to the evm that we're doing nine different functions behind one pre-compile so I think it's being more upfront clear about what the complexity of what's going on is because originally this started out um is a arbitrary length an arbitrary distance um you know arbitrary bit width and arbitrary um sized uh set of pre positive Theory you could have enabled anything at

random times and the issue there is that they were getting you know in theory could turn more stuff on as we go later you know it makes a compatibility problem because what if we add more switches uh and we add you know 13 14 and 15. then all sudden code out there we're going to have to have different versions of the pre-compile um whereas before you know you can switch on version 13 the pre-copal would fail then all of a sudden it works I think switching inside the pre-compile is the wrong place to add the complexity um weekly held I can be talked away from that but that's why I prefer multiple pre-compiles

Alex Stokes: yeah that makes sense to me

Tim Beiko: yeah and we we did switch it out to

multiple pre-compiles when we were testing DLS for Berlin so it feels like it's a probably a mistake if we say we're gonna rebundle them together and then to start re-implementing and then we'll come to testing and figure out it might be better to separate them again yeah unless something has changed probably makes sense to keep them separate uh Democrat was your hand still up from last time or was there anything else you want to add

oh yeah sorry

Tim Beiko: no worries okay anything else on BLS uh okay uh next one so 11 53 I don't

think I don't know if there's any uh Champion if Sarah or moody or

um yes um yeah I posted an update in the agenda so feel free um people can look there but only new update is that we have the tests now merged in the ethereum test Suite bow um and then yeah just again calling out that the implementations in gath and other mind Bay Zoo and ethereum JS have been run against this sweet and um those are all merged as well thanks

thanks

Tim Beiko: thank you uh anyone have questions comments on 1153 um almost then we have three left uh 47

88 uh this is the beacon State Route in the in the evm um I guess yeah Lucas do you want to sure I just saw your shot message do you want to share more

well

Łukasz Rozmej: no I'm just saying okay I'm Pro including 1150 frame to Cancun uh like it's most of things are done so why should we postpone it I don't see any point

Tim Beiko: I guess I wouldn't because we have like a bunch of open eips I probably wouldn't make a decision today about including any of them but uh yeah we can definitely do that in like the next couple calls

anything else on 1153 sorry before we move on to next one

Greg Colvin: no I very much support it um it it will save a lot of gas and uh Save A Lot on the tax surface uh we just got it to get ways to use storage that aren't aren't so hard to get right so thanks very much for for pushing this forward

Tim Beiko: cool um anything else

uh okay yeah so next one yeah so 47 88 that's the beacon State Route in the evm we also discussed this briefly last time um I think Danny had a comment uh plus running this as well before he left uh Alex is there any updates there anything you wanted to share

Alex Stokes: uh yeah I mean I would just also plus one this um this along with like the blsp compiles or just BLS with the tick generally is like really important for a lot of uh staking pool use cases which given the predominance of Lido and sort of the you know fragile position that of one dominant staking pool provider as the network I think it's really important to encourage and support Alternatives so uh for that

reason I think this one and also some sort of BLS solution is like really hard to do quite quickly um yeah the IP itself 478 I think is pretty ready to go I can make a pass on it before the next awkward dubs but yeah this one this one should be pretty lightweight and um yeah I think generally there's pretty good support for it so I think we should include it

Tim Beiko: thanks any comments thoughts on 4788 um two to go next up uh 663 so this was mentioned by this solidity team uh right before we uh

actually right when we were discussing eof for Shanghai and they mentioned that this would actually be very helpful for um in addition uh I don't know if anyone on the call is a strong supporter of 663 or has any updates or uh yeah concerns

the show

Danno Ferrin: I think it's important to point out that it's going to be eof only because of the use of immediates and this is the sort of stuff the eof opens the door for um in the evolution of the

eem

Tim Beiko: so generally I'm in favor of it when you say EOS only so you're saying we should do 663 in like

eofv1

Danno Ferrin: basically we can't do it without eowab so we do it in either eofv1 or it comes in later we

may as well do it now while solidity is rebuilding their compiler

Tim Beiko: this might be a stupid question but given this is like an EIP from 2017 and eof like I guess they they've adapted the EIP like recently to reflect this

Danno Ferrin: yeah they've called out eof I think at one point they were going to do the immediates until the issues with immediates um was shown to be a security problem and then it was adapted I think to be stack based but now they're back to immediate based

Tim Beiko: okay and eof enables them to do that basically

Danno Ferrin: exactly

Tim Beiko: got it any other thoughts comments about 663

okay and then last one so we discussed this briefly on the last call that was the pay op code is the other one that's been proposed um I don't know if there's anything new since the last call that anyone wanted to bring up about that

Danno Ferrin: I'm skeptical on this one um I don't see what it adds that provides significant value um some of the rationale um is based on well there's a radio security exploit you can do this stuff anyway but I don't know if the answer to that security exploit is the door wide open to make it cheaper um weekly held I can be talked back but generally speaking I'm skeptical

Tim Beiko: got it

any other thoughts comments um so we made it through the list um I guess high level you know for client teams uh it's probably really important in the next couple weeks to start thinking through like all of these and you know what makes the most sense to potentially bundle together um I think for like the sort of three bigger efforts so like well I guess the four bigger efforts right like for SSD self-destruct uh eof evmx like thinking what's this what's like reasonable subsets to consider for Cancun is probably the most important thing um and then for these uh I guess

smaller eip's you know whether they make sense bundled with uh 4844 and then potentially some of the larger uh other things um yeah and we can keep discussing this in the next couple weeks but any other comments or thoughts about Cancun generally um sweet so uh last up uh Puja you've uh put together a survey these past few weeks uh for node operators uh do you want to take a couple minutes to walk us through that

Pooja Ranjan: yes thank you Tim for that uh so exactly

two months ago we floated a survey for ethereum validators users to share their experience about client node running and what can be done to improve present Network distribution uh Tim if you can maybe pull up the oh yeah I posted it there

Tim Beiko: uh if you want to share your screen and give a quick overview we we have some time we can do that as well um I can put it up if you if you want otherwise but it might be easier if you're the one

blocking

Pooja Ranjan: sure I just lost my listing oh I got it we added

I hope my screen is visible

Tim Beiko: it is yes

oh okay I'll be

Pooja Ranjan: able to see the medium

blog post

Tim Beiko: yeah we do

Pooja Ranjan: okay uh so a couple of weeks not exactly a couple of weeks actually exactly two months ago we floated a survey for EPM validators to uh like collect their feedbacks and thoughts on what they think about present client distribution what are their experience with the working with those clients like if they are staking or they are running client node for any different purposes um they have responded quite generously

by sharing all their thoughts uh the service sample size was really low in comparison to the present active validator on the network it is less than one percent uh but we believe that the data provided by them could be useful for client team to understand uh what are the requirement of users what they like and dislike most about every individual client so we received this response from about uh users from about 40 countries and obviously staking is the most prevalent reason for running a ethereum network node the representation of a chart here is different from what we do see at client diversity.org that's because

again of the sample size of the data that may not be the exact uh uh there may not be consistent with the percentage that is being shown there however uh the information shared is almost similar like Prisma Lighthouse are the favorite client on the consensus side and get is predominant on the execution side we did receive a response to different questions in terms of how many pairs are being run by a single validator like are they planning to have backups of it or not um I have tried to put together some comments obviously all the responses could not be added to this report so we have tried to add uh multiple repeated

comments by user and we also ask questions about if they have to switch clients for client diversity or for any purpose what would be the reason you would like to switch and what could be done for you from client teams that you would consider running minority client like client which is not in the majority Network shareholder right now so these are the these are the responses that we have tried to capture and there is one very interesting thing like what can be done what what features should be added by different client team providers for you to help out with the staking of ethereum with the help of

what can be added to help you continue doing the staking on ethereum blockchain and they have provided quite a lot of input in that direction like they would love to have a elclined packages and like their testing could be more thorough one click could be really good to include more users and all um there are some suggestions on Mev boost site as well so I would encourage client teams to maybe go through the report and other users to understand what features are being provided by the these clients what can be like you know suit their particular needs um as I mentioned earlier we could not

add all the data points but we have tried to include multiple comments but if any client team is interested in learning about uh what all comments did we receive for individual clients please reach out to me and I will share the um responses received from users so yeah that's all thank you

Tim Beiko: uh thank you yeah there was a comment on the chat I'm not 100 sure about this but um basically some of the like numbers of clients use end up being greater than 100 but I assume this is because people were able to say like they used more than one client right like they use like guest and base 2 or

Pooja Ranjan: that is correct so the option the questions were multiple multiple answers so they can choose more than one client if they are running multiple nodes

Tim Beiko: any questions comments thoughts on the report okay well thank you Puja and and yeah I guess we can wrap up then thanks everyone um and talk to you all soon thank you thank you thanks everyone thanks Tim bye everyone bye everyone thanks bye

here

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