All Core Devs - Execution #196

Transcript

[Music] J

[Applause] in

for for

Tim Beiko: and we're live uh welcome everyone to

acde number 196 uh today uh we'll talk about Petra as we have been lately um devet 3 got stood up this week so we can chat about that then we can continue the conversation we started on the CL call last week around all of the encoding changes uh for the different eips Petra um there were two other uh Petra EIP issues that people put on the agenda so one around 7702 uh signature checks and then one around the pricing of the some of the BLS promiles and then uh probably the biggest thing uh trying to wrap up the

conversation around uh potential additions to pectra so uh we discussed those two weeks ago and then um some teams have already shared their views and then lastly um there's just a small heads up around uh the way the network configs are being uh documented in the different repos for main net and test Nets uh so we can just yeah quickly cover that um but to kick us off uh Perry do you want to talk through the launch of

devet 3

Parithosh Jayanthi: yes so we finally have devet 3 up and running the main change from devet 2 is the fix to the consolidations issue as well as adding 7702 um since yesterday we've also

tested that consolidations work as expected now and they do and we have had some 7702 calls and they also work as expected we're currently seeing some issues with nethermind as well as ethereum JS and I think both the client teams are aware and looking into it um in case someone from the C team wants to mention whether are maybe now a time

yeah I

Marek Moraczyński: think our issue was fixed so I see that in Fork monitor our uh notes follow the chain

nice true

Parithosh Jayanthi: I have checked up after the update so that's good to know um and besides that there was one minor thing I

wanted to bring up um our CL our ER teams under the assumption that we're running the spec version 1.5 or 1.4 purely for updating the spec document it seems like there isn't any material difference but yeah just so that we have it on record properly

you mean sales teams right El

Parithosh Jayanthi: teams there's also the execution spec

testas now okay oh so the execution spec test okay yeah yeah Aragon

was under the assumption of uh running 1.5

Parithosh Jayanthi: okay um I think according to Mario's

message it was also that they're mostly the same except for a few extra tests and this allowing yeah okay um so I'll just update the spec version so that it's also clear for um people looking at it I think that's it from the devet side of things for

Petra

Tim Beiko: thank you anyone else have comment thoughts questions about

Dev nuts

Parithosh Jayanthi: I guess if you have a wallet developer you like please ask them to test 7702 now okay the faet is running so you can get funds and you can deploy contracts and you can I guess Bak it

awesome

Tim Beiko: yeah that's great uh so we'll

give a shouts to that also outside of the call but um yeah you can start testing and yeah Perry do you want sharing the link for just the devet config page in the chat here um I believe that also has a link to the RPC on it as well as all the other uh things like the spec are adding it to metamask and than PK anything else on devet 3 okay um if not then uh moving on next uh we had all these proposals to change

the encoding uh of the data that's been passed from the El to the CL we discussed this on the um we discussed on the CL call last week uh and then Felix said he he'd open up some PRS for them which he did um and effectively I believe all of the PRS do sort of the same change just in the context of the different eips um I know there's been conversation about this on the Discord in the past uh day or so um I don't know if Felix is on yeah Felix you maybe want to start by giving you a bit of context on the PRS and then we can yeah get into the discussion that we were having on the award

Channel yeah

Felix Lange: so I mean there are two ties to this and the discussion we've been having is mostly in on the like CL side so this being acde I think uh uh the the changes that I'm proposing are like I think very uncontroversial for the for the E so basically um this is going back uh to some stuff that we've been proposing kind of before so um in the it all kind of started when we when we were seriously reviewing the uh implementation of the requests mechanism in G and we kind of noticed that there are two big problems with there so one problem is we used to be able to turn a

block into executable data and back with basically no knowledge of the for configuration and this is something we would like to preserve so at the moment when you create a block you can sort of pack things into it and um without having a lot of context so it's kind of a freestanding object for us and this would change a little bit with the introduction of the requests um if if they were to be done as separate list so we like Matt originally just proposed turning a request into a single list and on the CL side this was met with some criticism and I mean when I started reviewing his implementation of it I

also kind of felt it just like the El just has way too much knowledge of these requests because in the end the whole the point of the requests construction is that it's some data which is technically I mean it is generated by the El but the El shouldn't really know too much about like what's inside of these requests because they are supposed to just supposed to be for the cl to process and they are meaningless for the Els so in the changes that I'm proposing now we're basically removing responsibility for the E to ever decode these requests what we want to achieve is that the El should call the system contracts and then whatever is returned by the contract the only thing it has to do there is basically just it has to turn

the buffer returned by the contract it has to turn that into a lid and for that it has to know the size of each output request so that's like one data item we still have to track but other than that we don't really have a knowledge of the structure of the returned request we turn them into a list of just bite arays and then uh basically we we we uh are supposed to return them to the CLS for processing and they will be put into the El block as well um protos I can quickly finish my description or do we have very urgent question yeah

Tim Beiko: you can don't no urgent

I'm just in line

yeah yeah okay finish so then we move yeah

Felix Lange: so let me just finish the tangent so basically that the whole point of the of the PRS to change the e um is to just make it so that the output format um is exactly equivalent to what is returned by the contracts so we don't have to par them at all we basically just pass them through and then there is one PR to actually update the request EIP itself because it turns out that it was defined to use this treeh hashing function that we also use for receipts but actually we realized uh that it's totally unnecessary because nobody is supposed to make a proof against this root hash um the requests

root has in the E block is meaningless because the requests that are in there have not been validated for correctness by the CL so for example let me remind you for example for the withdrawal request any withdraw request can be submitted on Shain even for a validator that doesn't exist or has already withdrawn or whatever so just this request alone is meaningless and just creating a proof of that would actually be kind of dangerous because then you'd be proving that like this this request exists in the El chain but you don't know if at that block the the request is actually valid or the valid dator can cover it or whatever the the the thing that people should make proofs about is when it's processed and validated in the CL and for this reason the validated

requests they will be put into the CL block and as an SSE uh uh um list so there can be an an ssz Merkle proof uh about these objects and so for this reason I'm proposing that we change the uh hash that we or the request hash that we put into the El block header we change into a flash and this is similar to how we treated the like the omers they're called basically it's just a hash of the list uh instead of having this like Merkle tree construction there anyway so this is my overview of eips and now I'm ready to answer questions

Tim Beiko: thanks Felix um

pus yeah

Potuz: so I had a quick question uh so you're you're calling the system contracts and I I assume that you're calling them in the order that you're getting these requests in the in in the block you're calling the system contract getting whatever is returned you treat it as a flat slice of bites and then you want to store this somewhere so that you send it to the CL what I don't understand is if these system contracts are different system contracts and and and you know which which ones they are because we are prefixing the the the return with whatever a number that you in indicates which system contract was why would it be difficult for the El to just collect many different lists and just put them

in the order that you're getting so instead of using the index as a prefix use the index as the and the index in the outer list to put the and and then complete this this the inner list with the flat array

Felix Lange: yeah I mean this is something that if you guys absolutely want it we can have it as a separate list but the way I see it is that um we can make this list of list construction but I I would so for from our point of view yes there is a point in the code where we will be calling the individual system contracts and we know uh there we have the for configuration so we know which ones we should call but we also have um obviously we have the knowledge of like

which contract is it and so on so there is some some knowledge there but what we want to avoid is like having any more knowledge uh the system outside of that so there's a lot of other places in the client code bases where we have to deal with these requests and we just want in these places to have as little complexity as possible um it has not is yes there will be like when we are actually making these system calls we have all the knowledge that's required but it's just more of like a convenience for us that's why we proposed this like flat list if you must have it as three separate lists it can be arranged but we would be have happier to just have it as a single list to be honest

so if I if I could just make this

Potuz: this quick comment

is that so someone will do this like either you do it or we will do it but we will definitely grab this list which is prefixed and then make this list of lists anyways uh so and and the the the one advantage that I see of having already the list of lists on this API is that if we ever move to szz that's exactly what we will use in the SZ object that will be a list of lists so so that's that's perhaps why it's more future proof to get it on the API as list of lists but as I said before prism will not disagree with implementing this if this really makes the El life easier

Felix Lange: it kind of does make it a lot

easier because we have this we we basically don't have to know anything about the request further down the pipeline we only have to know about the request in this one play where we actually perform them and um yeah from that point onwards we just don't think about it and this also goes for example for decoding blocks and things like that like whenever we we have to deal with a block we can assume that yes there's this list of of opaque objects there uh sorry Tim what was the question

Tim Beiko: oh no sorry I was uh re said in the comment they already do this but I'm wondering if by this they mean compiling

the three different lists yeah

yeah we so because we need to uh deserialize the rlp to get ajacent representation of each of the requests these are different types so we end up doing um three different lists and then doing a wrapper type and then coating it into one list

Felix Lange: yeah yeah this is exactly what I meant so all of this complexity is totally unnecessary for for the El and this is why why I'm proposing to remove and um yes on the CL said it will mean that you have to pick apart this list and figure out by the prefix but I mean to be honest it is this information is like kind of pre so there won't like in the normal case there won't be any like uh wrong

um I mean the the requests won't really come out of order so for example because they are just generated in the right order by the Els I mean the we can argue if it if it somehow improves so if there is a specific proposal that would make it way better for the CLS then I'm happy to integrate it as well but as it stands the way we see it it's the best for us and that's why I propose it so yeah like we need to I don't really know how we should put this to a vote I do think that we should kind of decide this today because yeah I mean it's we're sort of like in the kind of late in the uh in the whole like Fork changing game even

though the fork probably not going to happen this year but I still think that like if we're going to have it the next devit or something we should probably have it in by then so yeah and I have uh created a separate PR to change the uh withdrawal system contract to return um the output in a way that's more friendly to the to the CL specifically there was this one field in there that is big engine and I've changed it to little because um yeah it makes it easier for the for the C to decode it but and this should probably then also be integrated into the E and stuff so we have to I would have to update my PR to include the new system contract code into the

EP

Tim Beiko: um there's a comment about uh by Destin about the ordering as well and that we uh if we do move forward with this we want it uh we want to have like effectively the ordering guaranteed um and adding this in the uh basically the ex the engine API spec yeah does anyone have any issues or concerns with that

Felix Lange: I mean it's simple for us because we can literally I mean I'm totally happy to just put it into the spec like right now I would I the sentence I would add is something like the requests have to be ordered by type and within the type they have to be ordered in the same way that they were returned by the contract but honestly this is just what's going to happen automatically

because the the during the processing we create them in this order so the ordering is I feel fully defined by the semantics of creating the

request

Tim Beiko: right okay so so if we make this explicit in the spec um as I understand it it's like yeah clients already sort of do this but then we should make it explicit to make sure that um um yeah that all the clients follow this um so yeah I if we can yeah if we can add a PR to the engine API that just adds this

Felix Lange: um yeah I mean I'm fine with adding that

to into into the existing PR I mean this is definitely the I'm absolutely not against adding as much text as you guys want about this in the specification okay

Tim Beiko: okay perfect so let's um I guess this like concern aside which seems like it can be resolved this anyone have like a strong objection to moving forward with this and I know like yeah the the issue is more like a CL one around the decoding and I don't think uh TK is on the call he's the person who left the big comment um yeah

Dustin Brody: oh hey hi oh yes yeah

Tim Beiko: okay yes yes sorry I didn't yeah had a brain

freeze between you the GitHub handle and uh Zoom name um so okay so as aside from the specification being more formalized are you okay if we move forward with the E not compiling the individual lists by default

Dustin Brody: well okay it it would be of of an an an acceptable compromise I guess um but but that is I really I mean I see this all this really really dismissive stuff about oh the the execution or engine API just

provides what's in the um what what's in the E what the El is doing we cannot I I I think I need to repeat this we absolutely must not and cannot rely on gu does this right or or re does this or like this is this is not this is an absolute non-starter I really need to emphasize this

Lightclient: I this is not how it's specified it says very specifically in each EIP how the request should be ordered within the list of requests

Dustin Brody: it doesn't address the I assume you read my GitHub comments that it does not address the interleaving case it doesn't I I specifically it does

Lightclient: it does in it does explicitly say the inter

leaving case it's exactly like Felix just said you order by the type and then intro type is defined by the eaps 6110 70002 Max EB

yes

Dustin Brody: within that's within the El block that's

Lightclient: and the engine API is defined to send the data from the El block over to the Co in the same way that's ordered in the E block

Dustin Brody: not precisely

enough not

Felix Lange: I mean we can add this like look Dustin it's fine for me to add the sentence the intent of the change is to relay the request exactly as it is in the El block because this is what creates a simplification for us like this is why I'm posing this because then we will be able to just put into the

engine API what we have in our block object and we don't have to think about it like anymore if I understand your concern that like these are different specifications and they each need to be complete and I I will add the sentence so given that this sentence will be added do you have any other comments about this

um beyond that that

Dustin Brody: I think I mean some I've said before and and and that pus has I mean I I I have I have other concerns but um and I I do I do want to Echo what pus was saying for example about the um

essentially this is not SSC friendly I know you've already or well it uh it it has been responded to in other ways in other ACD calls um and and um but it would borderline work sure I it's not it's not difficult to parse exactly if the other thing that needs to be defined here and this is not just an ordering issue I'll say is and and I actually did not see this defined in the El SE or the the engine the El semantics either is is the

invalid U type thing so what now what happens for example if you got to type um this is both meant as a general question but also I mean operationally if you want to answer I guess but that right now we have three request types uh currently uh and what if somebody that what if the CLC something with a request type um numbered three like a fourth request type coming out of of the E what what is it I mean is it defined what the CL is supposed to do because this this becomes as I mentioned there this is a consensus issue yeah now one dismiss this as a oh that's buggy eel I mean

assuming it's premature we don't have one yet but that's another example of um on the the execution API this may this is maybe not a concern for the El I understand for the e um as you have said this is they're supposed to be black boxes they're supposed to be opaque and the El doesn't actually care just conveying some some bites um but the obviously the CL does care about the semantics of this um and the CL does Define the consensus and so the there are questions that come up that uh on top of this as well that I think should be resolved and should be resolved hopefully sooner than later for honestly broadly the the same reasons as I think

you have been pushing to get this in um soon this soon in sooner than later which is to say consensus is consensus issues of this sort are things we want to discover early in testing um not not wait

Felix Lange: yeah so I I think the what we we can add an a bit more text on the um po request onto engine API as well so I see it is that obviously the correct answer is for the cl to reject the block if it contains request that it cannot sort uh into any of the available um request list into the SE block so the algorithm that the SE has to perform is basically when it

the block information from the El it has to go through the request and it has to sort of put these I mean it has to validate the request and then it has to put the valid ones into the CL block uh enclosure and if it finds a request that isn't supported under the current for walk then obviously um it's an invalid block so um it has to be treated as as invalid in terms of the fork choice but I think this is somewhat similar to if for example the El had returned that the block is invalid so it has to be treated in the same way uh whereas like yeah it's basically the same as having an invalid execution result or something

okay

Dustin Brody: I mean that's very reasonable I that's my inclination

personally as well as to say if any any single invalid thing makes the whole thing invalid that said there's precedent El I I'm not you know so that the invalid deposits don't make an entire block invalid in the CL for example and I'm not saying that here but but I'm saying this is an interesting point

Felix Lange: yeah actually that I don't really know how it works for these I mean if you make uh how does it actually work maybe you can quickly give a comment I I'm sorry for stretching this out so long but this is honestly super interesting like what happens if the like if a withdrawal request is submitted for example that isn't covered by the validator then it's just ignored or I mean it doesn't obviously it mean that doesn't lead to the block being

invalid but it's another kind of invalid right so you basically just discard this

Dustin Brody: yeah basically um that for for the request invalid requests are skipped yeah um but but the but but the whatever we do I guess my point is and and I I I I I take your points but not wanting to stretch this but I I do regard this I'm bringing that specifically in this context because I regard as as part of this at some level I mean um PR that you're you're trying to get in which is to say there are if there are new error conditions that are not possible now that are possible after your PR then those should be discussed as part of getting your PR in and one of

them is for example you know this let's say this this interweaved case you can I mean does maybe you say maybe that's just an automatic reject but then that should be again specified I mean I know we already but but but specifically a a specific aspect of that to say that is an invalid thing somehow that should be specified because otherwise the risk is we get people trying to follow postals law right the the be liberal and what you expect uh accept thing and this is this is dangerous um you way this is what

Felix Lange: absolutely agree with this yeah

so so

Dustin Brody: so if we want to prohibit helpful

quote unquote CLS from saying oh well we see request type one then two then zero then one let me just like sort that for you like we because the first one who sorts it they'll be more compatible with with other with with random and this is and now that's a now everyone has to do that now get HTML 5 you know in in Jon RPC and so like this is we this is something that has to be prevented upfront from you know Day Zero

Felix Lange: yeah I understand this and this these concerns I will deal with by just adding additional text but you right that these things exist and maybe like

some of that wouldn't exist as much if we had uh put it differently in terms of the encoding so it adds like these cases to the to the consideration I agree with this okay okay

yeah can I yes yeah

Peter Miller: so the position um from the From eel's perspective on this um is that when you execute the block um you deterministically generate a set of requests so that that are put that are put in the block and there there is no choice here or no discretion at all in the execution you you run the execution you get a list of requests and if the list of requests in the block is

different than the one you generated during execution including if it contains extraneous requests or if it contains the request in a different order it's just invalid so there is only one valid form of the requests so the E unless it is broken guarantees that the what order the requests come in and there's only one deterministically valid order um and the second thing and the thing so from our point of view if it's an ordering issue uh um it's broken and like if the CL receives something from the e and it concludes this the only possible way this could happen is that the El is broken it should reject the request and

complain um the other thing that this was compared to is there are other situations where a request can be invalid but in a way that the um e can't tell the E does not check deposit signatures it does not check whether withdrawal requests are valid so it just passes them on to the CL and the CL processes them if they're valid and um ignores them if they are invalid um so yeah this this I don't think this this should be an issue it should just be clear that there is only one acceptable order ring that the El can produce and that the cl um can rely on this if it wants to and if it detects

the this is not happened if it is welcome to just project the request as

inent okay

Dustin Brody: um I mean I I think as long as that's codified um that that mostly resolves um the the specific concerns um I I listed I mean it still strikes me as a um kind of pointless uh pointlessly flexible like it's it's a false Flex ibility as described but sure if one wants to insist on having that falsely flexible list and then you know ad hoc constraining it or rather post hot

constraining it I guess that that works

Tim Beiko: okay um yeah in that case I think we should yeah wrap up this discussion uh yeah this point so um as I posted in the chat I think the next steps here are um making the changes this specifically just having some stronger wording around ordering guarantees and how we deal with invalid requests making sure that's reflected not just in the eips but also on the um also on the uh execution apis and then hopefully we can get these merged async in the next few days uh but uh let's try to get this done at the lay list before next ACDC so that we have

like the finalized set of specs for all these eips and the engine API as a set uh these requests by next Thursday does that sound reasonable to people any concerns objections thoughts okay uh thanks everyone and yeah thanks uh Felix and Dustin for going to the details uh around the imple implementation uh specifics um okay next up uh 7702 uh I forget who put this on the agenda oh uh Andrew are you on

Andrew Ashikhmin: um yes I am yeah um yeah so B

basically at the moment uh how 7702 is specified it restricts U like one part of the signature namely s it should be it says that s must be less or equal than this SEC 256 k1n ided by two as specified by e 2 but the problem is that so it that ip2 is actually a refinement of a pre Homestead check that actually put some constraints on r as well uh as I mentioned in the pr so we should either make it consistent uh and uh like

check that the signature all signature values are valid uh and yeah there is for like you you can look at the method in in guess but it's kind of um uh basically it has two flavors pre Homestead and and post Homestead and we should use post Homestead uh also there is an alternative uh option by light client to actually um actually not check uh authorization signatures for validity only check that uh like that let's say all all signature values name namely y parity R&S are fit

into 256 uh bits uh and basically uh I think like the say say in 7702 that uh in case of um invalid like like like like the signature values outside of the E2 range uh the transaction is not invalid itself but that authorization is actually will be ignored when executing the transaction I don't care much which option is is adopted but I think like how 7702 is specified now is

Inon

Tim Beiko: thanks um yeah life C do you want to

just give a bit more context on your PR and

Lightclient: yeah so I think originally there was a PR that I merged by dragon that added some uh basically some instructions about what the serialization should look like in some reasonable bounds for the values in the 7702 transaction and when I merged I don't think I quite understood the implications it would have on the validity of the transaction and I've generally had this uh this idea that the transaction the validity of the transaction should really just be based

on whether the sender of the 7702 transaction can pay for the authorizations that exist in the transaction and has like a correct KN so my PR is basically to bring us back to that world where in the pr that I had merged from dragon that said some specific sizes of the different types of the transaction it also included this signature check that exists for the authorization list and in my perspective I don't think that we need to have these validity checks because it really just adds complication to the protocol that it it's not really it doesn't really feel necessary because if the sender of the transaction can pay for an invalid authorization then we

should let them pay for the invalid authorization they're incentivized to not send junk data to the chain but the data should be priced in a way where if they do do it then it's you know it costs correctly it's just the same as sending kind of noop transactions to the chain I think by having the validity checks we have to iterate through all the authorization lists before we accept transaction and it just adds a lot it adds a a lot more testing that we need to do to make sure sure that all of the different validity checks are correct so my preference is to remove as many of the validity checks as we can I think in my PR I've just made the validity depend on the data the

width of the different data types so I think most things are just u56 that's what I would prefer to go through rather than fixing what exists here which was what Andrew's PR uh was doing

Tim Beiko: thanks um does anyone else have strong opinions

Peter Miller: I'm very keen on the approach um but like TR suggested um it's it's probably worth like pointing out like what the issue actually is here is that that there has to be two stages of like investigating these authorizations firstly we have to like um basically pass them and make sure that they are actually authorizations and that they've been paid for we can't allow people to stuff arbitrary data of arbitrary size

in there for obvious reason um but we can't actually validate the authorization because that requires doing some curve math that's too expensive and we don't want to like require people in the mempool to go and do large amounts of curve math in the mol we just want to do one check make sure the Ping is paid for and then include it um like client um PR takes a very sensible approach that basically we just pass the request we take the request to the r we pass it if doesn't pass because one of the data types is too big or the structure is wrong then the entire that transaction is invalid because the RP structure of it invalid but we stop we we stop strictly there we

do not investigate at all anything other than is stuff the correct size and I think that the advantage of that distinction is that it's a very clear distinction it's is this check does the transaction pass rather than are these authorizations valid so I would support light Lin's approach

thanks

Tim Beiko: um does anyone disagree or yeah thinks in another approach would be better

I think I generally agree with approach uh I'm just wondering why the V component of the signature needs to be 256 bits like why would it need to be constraints to that is it not in

practice a lot smaller

Lightclient: the main reason is just this has been the sing with that we've accepted in the past and I think it's much better to reuse all of the exact same signature tooling rather than have multiple signatures in the protocol where we have different wids that we're accepting so if we wanted to change the signature withd I would rather that be separate EIP to do it across uh you know many different signature types

so you're saying it's because we have an EAP where we already do this

constraint and it's 256 bits in those

eaps

Lightclient: I think all transaction types V is allowed to be up to you 256 like in practice I don't think it's really ever valid because the only way you would get that high is if you had a chain ID that high so there is kind of this implicit um there is an implicit idea that it is the size but yeah I I I could be convinced I could be convinced to reduce the size of

v i in general don't think it's really that necessary because the people people will pay for the data people will overpay for that data and it seems like an extra check that's you know not doing that much like this the signature won't valid right ultimately so it just like feels like we're adding an extra way for a transaction to become invalid that doesn't you know it doesn't seem super necessary I guess that's generally my take

I think uh let's discuss async and then I'm fine with merging this if it's like if this is already the standard then I won't push too much back

on it but I think in practice obviously it's not 256 bits and it does have like some implications for performance but I don't think it's like so major that we should LU on it for now

Lightclient: yeah let's let's look into it a little bit iyn thanks

Tim Beiko: and I guess um if we're arguing about potentially reducing it we could also bias towards merging this and then adding the like more constrained version after

Lightclient: um yeah that's my preference I think in general people support this direction so let's merge this after the call and expect that we'll have these changes for devet 4 and in the next week or two we

can look async about uh constraining the size of V yeah

Tim Beiko: does that does that make sense to you Oliver

yeah okay

Tim Beiko: anyone disagree with merging uh like client PR uh which would supersede and and then using that as a basically the spec for defit 4 assuming we don't make further changes okay awesome then H let's move forward with that and yeah continue the discussion about uh the different bounds on the Val value um yeah thanks uh Andrew and light cin for bringing this

up then uh last uh issue about an existing picture EIP the pricing for the uh for the BLS pre- compiles I don't know Jared put this on the agenda I'm not sure if Jared is on the call

Jared Wasinger: yeah I'm here

oh hey yeah do you want to watch yeah

Jared Wasinger: so um yeah totally uh so yeah while um benchmarking the performance of the various pre- compiles and the g implementation um I discovered that the MSM pre- compiles uh use uh multi-threaded

execution um and that reducing them to single-threaded uh results and performance that makes the uh that makes them heavily underpriced uh relative to both the other BLS promiles and uh the EC recovery pre-compile and especially for the case of the G1 and so yeah I mean this is just our implementation that I've benchmarked so far but um yeah but basically um I want to broach the idea that we should uh repic these against

uh a single the performance of a single- threaded implementation because uh introducing concurrent execution to the evm kind of breaks a a previous precedent that we've set and not only that but it uh essentially takes resources that could otherwise be used by the client and does not pay for them um so yeah so as far as like how to repic them the easiest idea that I came up with is just to across the board uh so just to recap in the pricing model for the MSM pre- compiles um there is this uh table of values a discount table

um and that is uh basically if we uh scale that by a factor of two um that would be the easiest way to uh to bring the price up to uh the level of the uh EC recover pre-compile in the worst case um and then like obviously if we wanted to get more complex we could uh change the each entry of the discount table and price it to and set the entries to uh Target the performance to some Target

like I don't know for example the E recovery promile so yeah um yeah that's kind of what I had to say

Tim Beiko: and just one one Qui what others think yeah yeah one quick comment when you say you know increase the discounts by a factor of two I assume you may you mean make like reduce the discount by 50% for those curves make them twice as expensive

Jared Wasinger: so the naming of the table is a bit of a misnomer because the price scales inversely with it but yeah exactly make make them twice as expensive across the board got it yeah

Tim Beiko: just so to make sure we're we're CED there thanks yeah yeah yeah anyone have comments questions

thoughts about this um yeah there's a comment about checking other implementations uh and then plus one by nethermind I guess how easy is it for clients to um how how easy is it for clients to replicate these benchmarks

Marek Moraczyński: so we have solution uh we uh created a tool that can Benchmark all clients uh some time ago but we uh haven't written BLS test here so if we if we do that work then we will have benchmarks across all the

clients okay

Jared Wasinger: um if I can just jump in also so I've the benchmarks I've implemented I've also translated them to execute as State tests so um if clients have the ability to Benchmark state test then they would be able to replicate the inputs that I've used um without much difficulty

Marek Moraczyński: we use engine API request but we can uh talk about it as how to translate

your

Łukasz Rozmej: uh uh just one one comment here this the told this tool was built because

Benchmark is is hard especially for some managed languages like C and Java because there's like multi-tiered um compilation going on so you need to properly warm up everything etc etc so it's generally complicated so that's why this tool was built to have a proper benchmarks um and I would advise to use something more complicated than just a single run

Tim Beiko: and I guess yeah if different teams potentially have different approaches here is it reasonable for like re Basu Aragon and nether mine to just look into benchmarking these uh on their clients individually in the next couple weeks

and then um kind of report back as we have those benchmarks and hopefully by the next uh acde we're able to have like agreement about changing the the prices and I think it's it's probably good to use Jared's like uh suggestion like simple idea of like using a factor of 2x on the discount table and then um yeah having other teams look at whether this is reasonable and if if for whatever team or whatever other issue it's not we can discuss it but um yeah and I two weeks I assume would be sufficient for people to look into this um okay so I'll take the silence as a yes

um yeah so I guess in terms of next steps Let's uh yeah have each team look into it run the benchmarks um we can report back is there like an issue or like a channel I guess we can just use the execution layer channel in the R&D Discord to discuss this uh like the execution Dev Channel um which Jared was already posting uh benchmarks in and then um oh Basu is a maybe um Justin is that on the timeline or on whether it's possible for Basu okay here it basically say yes now okay so yeah um yeah let's let's follow up uh let's

follow up on this on the execution Dev Channel but then hopefully um at the latest two weeks from now we've have the benchmarks from all the teams and then as soon as we have that if uh they're all roughly similar we can just 2x the the costs and if there's like big uh big discrepancies between different client teams benchmarks we can look at that further um does that make sense okay um well yeah thanks Jared for uh sharing this and um yeah we can now move on to uh last I guess big thing on the agenda so on the last

acde uh there were a bunch of potential eips uh that were brought up to consider for inclusion in Petra uh we already have a ton of VIPs in Petra it is by far already the biggest fork uh in terms of number of eips um but there's still some other stuff so uh we had uh four eips that were cified so uh the R1 pre-compile uh inclusion list which I think we've agreed we're not going to do uh the call data cost increase and then the decoupling of The Blob count between the El and the CL and in addition to this uh there were a couple more eips so we had uh these ssz eips we've been talking about uh for a a couple months uh there was this eof related EIP has

code uh which would allow uh effectively to to check whether um eof account is uh is a smart contract account or an EA and then lastly there was uh Max's EIP uh to increase the minimum base fee per block gas um and so I asked the teams to sort of share uh what their perspectives were on these on these different uh these different eips we heard back from W from etherum JS and from nethermind um each of them uh you can see on the agenda their their uh their opinions and it seems like across at least these three teams um the uh decoupling of the blobs is like the least cont ious so it

probably makes sense to start there um so yeah for EIP 7742 um I don't know yeah Aragon Basu gu um how you all felt about this one does anyone have concerns um but it seems like the yeah the one thing the one thing that had the broadest support um and that's also pretty straightforward

Lightclient: yeah this is U Matt from Bas I think the same same normal scope group considerations but yeah we're in favor specifically the decoupling and loely in favor of those other two as well just to get that out there but we can discuss those more as we go thanks

um anyone from Aragon or

guest

Andrew Ashikhmin: so I think we are slightly in favor no strong

opinion

Tim Beiko: okay and then there's some comments in the chats that yes the fork is big and you know should we consider removing some eips um yeah like I'll also Echo this where we have a lot of different things in this Fork um yeah I don't know if anyone has thoughts there they want to share um Alex has a comment saying instead of

removing we could consider splitting into two forks um Alex do you want to expand on that

sure yeah

Alex Stokes: I mean I think everyone agrees that it's a really big fork as schedule so a natural thing to do is just to break it into two um you know generally smaller Forks are less risky in particular with Petra right now there are a bunch of like cross layer eips which really raise the like testing and Security review load so that's not great and yeah I mean I'm curious how people think about this

Tim Beiko: uh yeah L Cent has a comment about Perry

proposing this I remember there was like a devop stock that had like four or five different options um and Perry saying plus one to a split um I don't know Barry do you want to share um yeah more context there

Parithosh Jayanthi: yeah um I think the main reasoning is that uh currently we have a lot of eips and when tending to touch many many many layers of the stack and the more we add SL even at the current load um it's hard for any one person to have an overview of all the changes um at least the approach we're taking right now to testing is one well the testing team looks at more the El eips and we're

looking more at the C eips but I do think it's it's a lot um but yeah just want to put it up out there as well

Alex Stokes: yeah maybe to be specific like one option is just looking at sort of the quote core pectra that we have right now say on De 3 and there's things that we're discussing say like e or puros I think those could very naturally go into a second Fork just given development timelines and again accounting for how big pectra would ultimately be if we do it all at once

um ancar

Ansgar Dietrichs: yeah I just wanted to basically very

briefly say in in in support of uh pasas because I I do think kind of a split might make sense and I'm actually conflicted on petas as well but I wanted to at least give voice to the point that to me over the next year this is kind of the the part of the upcoming upgrades that is the most core to kind of the Strategic road map of ethereum and so at the very least it might be unavoidable that it would have to go into the second part of the split but I would at least say that we should at least try to basically give it like give it a try evaluate like is there any chance we could have it be in the first part and and if not then yeah of course it has to go into the second part but just want to mention to

me pias really is stands out in terms of its um strategic components to ethereum

Jared Wasinger: thanks

Tim Beiko: um there's a question by Oliver like how we would split I think one thing we should consider there is that um when we start bundling things and Dev Nets and testing releases and whatnot like there's then a cost to uh unbundle them um and so like not that what we already have in Dev Nets should exactly be Petra but I think we should like that should

basically be like our default of like stuff that already bundled and being testing together is going to be quicker to ship together than if we both add more stuff and also remove more stuff um and in the past we've seen like mainnet consensus issues happen when we like remove eips from Forks as well so we shouldn't yeah we shouldn't treat removing something from the current scope as effectively like free um we should we should assume that'll also take some testing and Engineering work um and so like yeah so there's a comment about devet 3 like um I'm trying to find a spec real quick

um but basically devet 3 right now comparing it to uh Petra so 2537 2935 61110 7702 uh Max CB 7549 7685 7702 are all in um so I think uh this means that the the two eips included in Petra today that are not in defet 3 are pias and eof uh which is a whole set of eips and then none of the additional eips that we've considered um in the past couple weeks um that we were just talking about are included yet either um so that's kind of

the way to think about it where defet 3 has everything except eof and pias um and then um which are also being prototyped in in defet right right now and then all these other eips like 7623 7742 and whatnot um don't have any prototypes or like implementations as far as I know

um so I guess I guess yeah one point

Parithosh Jayanthi: bring up and already kind of playing The

Devil's Advocate um if we do split eips today what's the guarantee that we're not going to add more eips to the next for and kind of be exactly where we are right now just 6 months down the line and how do we prevent that we don't do that I guess

Tim Beiko: yeah I guess maybe to touch on that and like Kev has a comment saying like if we split when with the second Fork be I don't think that we can I don't think it's useful to like think about when the second Fork would be because we're just going to like optimistically um say something and then probably be wrong um the way I would think about it is assume everything that's already in Petra is like the set of things we want to ship as quickly as

possible um does bundling it all in one release make the whole thing ship quicker or do does isolating some of these changes together make the whole thing Shi quicker and my intuition is like if we just look at what's already in Petra today um it's potentially quicker to like literally ship you know devet 3 separate from pias and eof and that the date when all of this is live on mainnet is earlier than if it was all combined there was all these weird uh interactions across it um but yeah the the the the other question there is like if six months from now um

if six months from now we keep adding a bunch of stuff to like whatever Petra 2 is um then we're kind of in the same problem so in terms of scope yeah we I think we'd want to basically limit things as much as we can and like potentially start planning for like the fork after that but yeah

um Dan

Danno Ferrin: so I think the model we should probably consider is is basically what you've been talking about is it in the devnet um then it's set to go for the next fork and we could just close the door on devet 3 right now um polish it up fix it bug fix it only had absolutely essential changes and start um devet zero on buaka so we Shi devet devet 4

Becomes devet of pectra becomes devet zero fusaka we put e in there we put all the other things that are ready to go in we start testing that in parallel but we also polish up Dev net 3 ship that just as soon as we get it polished and ready to go that's that's just something that I could get behind if we um you know start putting a stake in the ground that this is already what's in the next devet the next hard fork with the devet zero that hard Fork that would have sawed a lot of concerns to say when is it well look and see which devet it's in and that's your answer

actually yeah

Tim Beiko: I like this idea I think maybe the one net I'd say is like maybe there's like a devet 4 that's like Petra 1 and then devet 5 is like Petra

two or something like that given that there were maybe things we wanted to add um that are simple like I don't know if people still feel that strongly about decoupling The Blob count or like increasing call data cost but like those eips are like relatively simple and like so I yeah like maybe yeah I curious yeah to hear from people like if we went with something like this do we think devet 3 is the thing to ship do we think there's maybe still a couple things extra to ship as part of pectra and then um pectra 2 becomes devet 5

Alex Stokes: um I think that's a good way forward and

maybe just to add another plus one here like I think this scope has been decided because we kind of have just scheduled two forks with pectra already and so this is just recognizing that like timing wise riskwise you know production wise it makes a lot more sense to have two here rather than one hard fork

Jared Wasinger: and yes

Tim Beiko: to be clear Kev I think Petra 2 I don't want to use like fusaka because like we already have veral schedule for that like yes I would think of Petra 2 whether it's eventually called fusaka and the veral fork but like Petra 2 is say you know eof and pias but um but um yeah like it it doesn't also

include veral and we can like we can call it fusaka or whatever like we can sort this out outside of this skull but just want to be clear that like this is um a separate thing than like the fork that has

verle and yeah then know

Danno Ferrin: so my controversial take on veral is that it gets a third test line that is the current Fork whether it's Cancun or Prague or whatever comes after Prague and it is that Baseline and when it passes its quality metrics that is when we ship it independent of any other feature because it's so big it wants to be its own thing so we let us be its own thing Let It Grow when it's ready to ship and passes the quality metrics that's when we pull the trigger and start scheduling it so it's not tied to

the regular Release Train something that big um is causing scheduling problems because already talking about inventing new Fork names and moving stuff around because we conceptually tie this way named Fork no it ships when it's ready and we give it it space So cook and make sure it's ready when it passes it quality metrics out the door it goes

Felix Lange: this is a good point but you have to agree that it will only really start passing the serious quality metrics when we put it as the next Fork like this is traditionally how things have been going I mean maybe for workers different because there have been Dev Nets and all this kind of stuff even it's not scheduled right now but I mean for sure the finish line is sort of when it

becomes visible by something being scheduled that's when we really start putting all the effort in

Guillaume Ballet: and more importantly uh this uh you know like verle was more ready than many things that were U that were scheduled and we pushed it because it was big yes but okay sorry I have to do bitting at the same time but um yeah the the fork was already ready a long time ago at least like the quality materal were already pretty Advanced um we can't really push because otherwise you're sending a signal that is very uh I mean no one will ever

invest in it but no one will ever invest in in larger forks and sorry about

theise

Danno Ferrin: well the quality metric I had in mind was two or three successful mainnet Shadow Forks so you move towards the full dress rehearsal when the dress rehearsal is ready you just swap in and say that's the one that's going next I don't think you had a successful main netw Fork yet you've had some te netw forks no no pretty full size

Guillaume Ballet: this is this this is unprecedented like this is the amount of quality uh eof was never held up to and this this is completely unacceptable

I think that's I

Tim Beiko: yeah I'm I think another way to look at this is like when we when we scheduled veral for the fork after uh Osaka or uh sorry

Petra um we then started adding a bunch of stuff that we thought we should do before veral and that list sort of grew longer and longer and longer and there's a sense in which like we like we effectively prioritize this ahead of verle um One Way or Another and whether it's like one fork or two forks I'm I guess that's the main thing um that at this point feels like a uh like the decision to be made but um it yeah it seems like I know teams wanted to work on eof before work hold we made this decision we're already you know quite far ahead in the testing um

and again we can always like revisit these decisions but there's also like a cost to that um so I yeah I know I think a way to look at it is like assuming this is the set of things we want to do now and that we've already committed to doing before veral what's the quickest way to ship all those things um and yeah I think my sense and like what a bunch of other people have EO is like splitting this set of things we wanted before V into two separate Forks is probably quicker than keeping it bundled together because there's like uh effective nonlinear cost in testing and Engineering complexity of having a massive Fork rather than two small ones

um and then I think the big risk though if we do this is that we split in two forks and then we look at the second one and we're like wow this only has 10 eips now we can like bump it up all the way to 20 and then you know we sort of end up in this infinite Loop of like splitting Forks over and over my hope is we like slightly better than that and we can commit to like keeping the scope relatively tight um yeah I guess yeah maybe uh yeah another

question is like is there anyone or any team that feels like a single unified Fork including like regardless of the additions we're talking about but like just including the stuff that's already uh in pectra would be quicker than like yeah two separate ones um uh yeah Ben

Ben Adams: um I mean it it really comes down to the devet process I think it uh how much uh splitting into two cuz now we have to do two sets of

Deets uh versus doing M1 I don't know the answer to that

way

Tim Beiko: well I guess the so we already effective we have today three sets of Dev Nets right there's there's pectra Dev Nets there's the EF Dev Nets there's the pias dev Nets um as I understand Dano's proposal is basically we say we use devet 3 as the basis for Petra one um we you know we do that we keep working on it we ship it and then the work that was currently happening in the eof and P Das defet tracks um gets bundled into and and that we were planning to include in devet 4

instead of devet 4 being just like a continuation of uh changes to the Petra spec devet 4 just gets rebased on Petra and effectively becomes you know devet zero of Petra 2 or something like that but um yeah yeah

Parithosh Jayanthi: and also just want to make a point that uh pias hasn't been rebased on Petra either so it was kind of a commitment we had to make anyway so we can just continue to keep the pias line of devet separate and just pin like a Petra Branch we would um consider

canonical for pasas and I guess we would do the exact same thing for eof but I guess we can discuss those details more in the breakout room that we would eventually have

Tim Beiko: and I guess so we have devet three that's launched today or sorry yesterday um I assume teams still have like some work on this um but at the and at the same time like this is kind of a huge decision to consider so we probably should give people time to think about it but what's the what's the timeline uh by which teams you know like feel we need to make a call here um where like yeah if we if we don't have a

decision on the specs then we effectively won't know what to implement in the next evet um like do we need to make this call today do we want to give people like a week or two to think about this um yeah my sense is like a week would be reasonable especially if we're considering different ways to split it but yeah sorry Alex I think you came off

M

Alex Stokes: well I was just going to say if we don't decide today yeah then I would say either I mean next week would be great or definitely by next ACD yeah

Tim Beiko: yeah I think yeah I I think ACD feels like

almost a bit yeah too far um but my yeah my suggestion would be um by the next week looking at um yeah like so the what first the binary decision do we split or not second if we split are we happy with the scope of devet 3 as Spectra one or are there things that we feel strongly that we should include um and then um and and and then also like you know this if if we do make some changes to the actual eips already in devet three like we discussed in the earlier half of the call um you know how to approach those and and how do we want to get to a spec

freeze um yeah but I think that's that's kind of reasonable and there's a comment in the chat as well around uh timelines so like I think there's also broad agreement that if we split the ideas that we want to ship pectra one quicker then uh or as quick as possible and you know early next year should be like our Target so if we think about like stuff we would consider adding to pectra one um you know it should be stuff that doesn't really change the Timeline under which we' like expect to ship to Fort um yeah so maybe yeah so I guess yeah a week from now on ACDC we can continue this discussion um see if like any team

strongly oppose spilling and if there's consensus towards splitting then what's the set of things that we can optimistically ship you know some time between the end of this year early next year um do we need to bring anything else in that feels urgent and um take it from there any other thoughts comments okay um well yeah thanks everyone um I'll try to write up some summary of this as well after people who weren't on

the call but let's uh continue this discussion on next week's call um okay and then the last thing that we had uh on the agenda today was uh some updates around uh network configs uh for main net hosi uh PK you posted about this um do you want to give a quick uh overview

yep can give um yeah there is a set of PRS to align the format of the three public network Genesis repositories um there isn't a big change just aligning the format of all and to have a consistent format of all these

repositories so in particular we added the um execution layer Genesis for mainnet and zolia and we started tracking the execution layer boot noes for uh yeah for these networks so it would be great if client teams could have a look at it and add um potential missing boot noes that are operated by them so later on we can ping these boot nodes and have some monitoring and blame the offline ones that's basically it

Tim Beiko: thanks any questions comments okay um then that's everything

we had on the agenda anything else people wanted to cover okay well thanks a lot everyone uh yeah we covered a lot today um and again yeah reminder to Think Through uh yeah the options for the fork before next ACDC and in the meantime we'll also finalize the specs around um the encoding stuff and uh yeah if teams can start looking at the benchmarks for uh the BLS PR compiles that would also be great so we can uh get the pricing done and yeah I think that's it for

today thanks everyone for joining and talk to you all on next week's calls

thanks Tom thank you cheers everyone thank you team bye thanks thanks everyone bye bye J oh

I for

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