All Core Devs - Execution #175

Transcript

[Music] than [Applause]

for e

and

Tim Beiko: we are live uh welcome everyone to acde number one 75 uh today as uh always we'll be talking about Denon uh get some updates on testing um I believe there was a a execution API PR we wanted to discuss as well and then uh yeah figure out where we're at with regards to launching devet uh 12 and uh what we see as the next steps after that and related to this um we discussed in the past that uh this would would be the last Fork on gorle um in a world where we forked gorle before

the holidays it would have made sense I think to announce that as part of the hardfork announcement but I think if we're not going to hit that we should still announce uh how long we plan to keep Gordy around for uh after uh dankun and so if we could uh get a feeling from teams today around like how long we want to maintain at least the client noes on Gordy that'd be great and then to uh close off uh Micah has a proposal for a new rpcn Point uh East multical um yeah so I guess to start um I don't know Perry Barnabas uh either of you want to give an update on uh testing so

far and uh Dev Nets where we're at there and then we can go to the client teams as well

Barnabas Busa: yeah sure I can give you an update so basically we are running Dev net1 right now and uh everything seems very stable the only pair that is uh not able to keep up is ethereum JS with lar uh but it seems to be some peering issue probably gajender can look into that we wanted to launch devet 12 next week but we heard some feedback from uh the prism team that they think that this is a bit too soon so we might as well uh hold off for a bit longer because this week is a Thanksgiving uh week in the states and

we expect that uh maybe not all client teams would be ready to go with devet 12

Tim Beiko: got it and just could you remind us uh devnet 11 does not have the latest CL changes right devet 12 is the one that will have the The Blob signing changes got it

yeah

Barnabas Busa: yeah that's correct uh so I do have a spec sheet also for de 12 give me one sec I will get the link

Tim Beiko: oh I literally I have it in the agenda let me post in the chat here

Barnabas Busa: okay yeah so the only change should be just that uh that one change that we discussed last last time

Tim Beiko: got

it

Parithosh Jayanthi: we did test a couple of things for the lighthouse team I think they uh changed what gets gossiped in which order as well as support and uh I think pan has like a bunch of information is collected out there and then we turned on Mev back in devet 11 so we're going through the entire Mev work on devet 11 as well

Tim Beiko: nice

H Ben

Barnabas Busa: yeah we should probably sorry uh so we still want to enable all M boost for all the different clients right now it's only running for ler and nimus but we're going by by the end of this week we're going to enable

it for all

sales go uh sorry anything else Barner Miss Perry otherwise I will go to B

Barnabas Busa: yep that's it for me

uh yeah just wonder if we should do a straw poll really on devet 12 starting in a week um if it's only prism who is unable to make it they can catch up later um so just in terms of kind of keeping up the the Cadence whether if everybody else is ready or not we we could just you know put a finger in the air and see uh teu we believe we should be ready

Tim Beiko: awesome yeah uh how do other clients feel about that

um is anyone else ready to start

devet 12 next week lotar can start devet 12 next week

Tim Beiko: anyone else

Marius van der Wijden: I think all the execution layer clients probably can

Tim Beiko: yeah I assume there's no changes uh I don't know if there's anyone uh so prism said they can't I don't there's anyone from Nimbus or lighthouse on the call um okay well if we have all the Els and then at least two of the Cs potentially up to four

um yeah I'm curious Perry Barnabas do you think there's value in standing up the devet even with a subset of clients um it feels like we might learn about something breaking especially given like the new C change um by doing that next week

Barnabas Busa: I think we can do I think we can do CIS test for sure and then uh if we have like three clients then can start the

dep okay

Tim Beiko: uh okay that sounds good I guess uh what I'll do then um I'll post in the Discord asking for if there's more CLS um and we have a testing call on Monday as well

scheduled um so yeah we we we can bring that up there as well and see if there's if there's a third client but I think yeah let's try to do it uh you know even if it means it breaks and then there's a devet 13 or something I think we'll learn a lot by uh trying to get the the de 12 up um yeah so okay so cool I'll do that I'll ask uh I'll ask in aord Dev and then uh we can discuss this on Monday

um any other oh sorry we work for load star sorry

Barnabas Busa: like Wednesday or Thursday would

work for load star and

te

yeah I think so um the 30th was the original plan I think that's good with teu um possibly earlier

Gajinder Singh: yeah lot s is already even this week as well so yeah we're good

Parithosh Jayanthi: yeah I think Lighthouse is ready as well so we can just try to make sure the devet is up before the call next week

thday

Tim Beiko: yeah that would be amazing if we can get it up you know on Wednesday try to run it for a day and see if it's still up or broken by ACDC

Barnabas Busa: um yeah okay sounds like got plan just uh

bring me your uh branch that I should use for Dem 12 and then I I will build images

Tim Beiko: awesome thank you um anything else on devet 12 um if not U Mikel you'd link the pr and the agenda uh by uh sorry I'm blinking um but the pr round uh dis disallowing the valid invalid equivocations um this is an execution AP PR do you want to give some context on

that

Mikhail Kalinin: yeah um thanks Tim uh so a bit of a background Astin from uh Nimbus raised a problem uh in in the Istanbul um and the problem looks as follows that actually some e clients uh when they first time receive a some execution payload um can return uh can validate it and return the invalid status so saying that this payload is invalid but if the same payload sent to to the same client for a second time um the response could turn to valid uh which uh actually um yeah which must not

happen um and yeah obviously it must not happen and uh basically is implicit uh in this fact that U the valid or invalid status is like the end status and it must never change for the same payload um and because we have have some clients which does not follow um uh these implicit requirements we decided to make them explicit and Rise awareness that this thing should be fixed um because on the CL side uh this is really unexpected behavior and I guess that for other reasons and not only for C side like

receiving something then that will be changed in the future for other reasons this is also um the behavior that the CLI should not U have um yeah Dustin do you want to give more context from SE side what um bad things can happen because of that

Dustin Brody: uh yeah sure so the the main issue from the C side is that it is defined in Spec that um a valid uh block cannot be the descendant of uh of an invalid block and an invalid an invalid block cannot contain again P spe on the CL side uh uh

an execution payload declared to be invalid by anyel so what this means that it is valid and legal and actually a quite common optimization for example for gossip rejection for things like this for a cl to say oh no this the E already told me that this uh um execution payload was invalid anything I see that refers to that just Skip and discard and move on and what this means is that the Stalls chain progress for for the CL um now different CLS do handle details of this differently um CLS can try some do some are more strict about just saying no they saw it once and and just stop and

never use it again uh at least in the past I believe that some have saved the rejection to dis in some format but I think they stopped doing that a while ago so most be starting will will wipe the slay Queen on this point um but that that's essentially though is that it really cuts off the validity of the chain um and that's that's the harm that it causes um and to the degree that some CS seem to tolerate it that's because like they're they're just retrying and honestly it's not clear to me whether they should

Mikhail Kalinin: yeah so so basically if um some payload is dimed invalid and this is actually an incorrect status of this

payload um it may also cause uh temporal Network splits because validators will not vote for invalid blocks uh for a blocks containing invalid payloads so this is quite important to um to fix this bugs if they exist in

E clients um and uh yeah so so is this I think that uh yeah sorry

Tim Beiko: just to understand is this an issue where the spec on the execution API is currently more permissive than the spec on the consensus layers and therefore we only need to fix a spec or have have we

seen actual cases of this happen on like a devet like I guess I'm trying to understand what what leads an El to First classify something as invalid and then invalid and if we've seen examples of that or is this just yeah a spec issue that we want to make sure everybody's following

Bo both

both are happening so so first is the case that this is and I in the wink spec that um or issue PR that M um Winks um actually the very first link within that description is to the optimistic syn spec and the optimistic sync um already essentially requires this I mean very I I think

explicitly if people want to debate that that's fine but I as far as I'm concerned this is basically just implementing what's already in CL specs in the engine apis so um and the and for various reasons um I guess the engine apis had not strictly required this and and what had happened was there's let's say some evidence that engine API implementor uh on the El side have not always looked um at nor should they have to if the specs are well factored out um pure CL specs which is to say the optimistic six spec got it which is how they operates so they did not necessarily see the uh

you know dire outcomes of of this equivocation necessarily because this the El spec doesn't clarify this that's part of this that's half your question now the other part is is this essentially theoretical or is this just sort of a a spec alignment for the sake of spec alignment and no it's motivated there are multiple Els this is very clear I'm not picking on one e here I have encountered this with multiple Els uh where they and um and there are GitHub open GitHub issues and and um Discord threads in eth R&D Discord where I you know they're I mean the latter are

theoretically public kind of hard to find just because you know Discord ux but you know um where I have discussed this with saidel and provided examples from their walks and and and compared um from these def Nets yes because that's actually a great way to harvest these things because then I can log in and see the exact same network situation with you know Nimbus um G nbus nethermind nbus Vu nimus Aragon and just compare them and and how they react to each payload um Beyond just looking at the um uh like Beacon chain uh instances so yeah and there are absolute examples of this and in in the devet up

through devnet 10 or 11 um so uh it's it's become less common sure but but I think almost the fact that it was um it has continued uh kind of at U Al be at a lower frequency these days than it used to is is part of what suggested to me that maybe it's an issue of well it's it should be in the specs because it's clearly not because look Hive tests many many things just I I I this is a de I don't mean to make this a degression that will last longer than a sentence or two but it's going to feed directly back into this Hive tests many many things and empirically El's are quite responsive to when Hy finds issues with with them because hyp tests El

specs and what would I was reading out of this was that this was one of those like regressions that was never really tested for therefore it kept happening again and again because it was not one of the metrics people were trying to hit and so my goal is essentially to add this explicitly back into one of the constraints about how Els work as El's see it when they Implement their own code not just when they happen to look over you know and and into

csps

Tim Beiko: got it thanks yeah that's that's really helpful context and then there's a a comment uh in the chat by Gary saying you know one case where this could happen is uh if you have a state rout mismatch and then you restart your node and it turns out fine and then

you're processing the same payload um but yeah I guess I'm curious to hear from eel folks like first does anyone think we should not do this change and then two how should we test for it because something like this where it's like a state root mismatch and you have to reset uh is there is there a way to t for that in Hive or somewhere else so that we can uh we can catch those bugs earlier in the process

Gajinder Singh: here I want to seek some clarification on behalf of etherum JS uh so is the oscillation so the problem is the oscillation between valid and invalid or between invalid and sying as well I mean it could happen that the

node could not would not keep the cash off invalid blocks or would clear out its cash at some point and and might if the CL again is trying for an invalid block which it should not uh but let's say because of their syncing strategy they're trying again to uh sync a block and that is responded as syncing I think this is also being mentioned in the PR but I want to sort of confirm that is this also sort of a

noo

Dustin Brody: not as unambiguously so this is discussed in the issue went uh the pr um between M and I actually as far as and obviously other people's well input yours anyone else's is is welcome um so

strictly speaking the for compatibility with the CL specs optimistic sync which is sort of the reference I'm going with here because that's how cl's work this is all the CLS of this and so an El which breaks this sort of contract really makes things difficult but but the only thing that's Sur require is requires is exactly what you said uh at first which is it cannot cycle between invalid uh or invalidated obviously B cash Etc and valid um the syncing is okay for this purpose there is a question it's a good question I think what the correct thing to do about the sinking is um because what you describe

of course is you know true that as far as keeping pre states around and all that um it strictly speaking though is a little bit distinct from this issue and and you know and that's one of the questions actually that uh I think we would love Mel and I are would I think welcome input into how to incorporate that or not into the this PR

I think

Mikhail Kalinin: I think that previously we um decided that invalid Sy is probably fine but valid syn is not fine and also invalid and valid uh switching between the two um is basically something that

must never happen and as it's been said that um one of the easy ways to fix that could be say we have a cach for invalid blocks and uh when the next new comes with the uh the same the same block hash so we can uh pick the value uh hit this cash and see if the pck is invalid and respond invalid um even though this cach makes sense for other reasons but I would like to emphasize that this easy fix for this particular problem um should not be um you know applied because really um jumping from invalid to a valid state is quite can be quite

detrimental dependent on the share of uh of the um of the Market of of other Market that the certain client that do this um has so yeah this has been said chain splits um that's some and some SE clients will have to be manually restarted um to to accept the block that was deed invalid incorrectly

thanks uh Lucas

Łukasz Rozmej: change this

here things I want to add that one um I think those are mainly bugs right so and they're unexpected bugs so bugs that something got corrupted either like uh corrupted and stored but that's a bigger bug or corrupted like in memory uh like you have something that breast fixes it for example this is especially the case for State try M State rot mismatch uh so um and they are unexpected bu we don't expect this to happen uh but you know they are there sometimes um so I think it would be hard to test for it because the scenarios can

be really really wild uh and the other thing I think this is mostly a social problem that we need to just treat those bugs with high priority and try to fix them uh and communicate them well between CLS and Eels if if this happens so I yeah that's that's kind of the thing I don't think there's much of like changes in in make sure this communication STS well

and go

Tim Beiko: and so and to be clear I assume this means you're in favor of like

making this explicit in this spec and then treating any issues we see that break this as basically a consensus issue uh in terms of severity or potential consensus issue um there's a plus one uh uh from this to this from teu any other y team have thoughts on this or how to approach it to make sure that ideally we don't hit this but then also uh that we we document or or test it

okay and yeah so there's a comment by uh gender around uh basically a plus one in yet as long as we can still have invalid going back to syncing um so maybe we can we can give a couple more days on the PR but assuming nothing else comes up it seems like making it explicit that you can never go from invalid the valid um as part of the spec uh I don't know if we want to explicitly call out invalid the syncing um and then for now unless the testing team comes up with a really uh unique way to test this we probably can't add more test because

of how hard it is to to create this bug um but if we do see this on dev Nets or or somewhere else uh clients should you know fix this with like really high priority um given it can affect uh what what a validator uh attests to on Main net does that make sense to everyone

Dustin Brody: sure I I I have a question actually to as a you know wrapping up question in terms of how to phrase this in term do would you know El implementers is is this is the preference for kind of enumerate all

cases or or very spe specifically address the cases which changeed which is to say for I I specif specifically have in mind things like the invalid sicking thing here so if this PR functionally would not change anything with invalid sying like it says that's it can happen now it can happen after it's fine is is is the preference to say so explicitly or to you know leave it out and then have that inferred

um and yeah

Tim Beiko: any thoughts from El folks okay there's one comment saying

it's good to have everything explicitly in the spec okay another comment in favor being explicit oh sorry

Migel

Mikhail Kalinin: yeah just want uh say that we'll work on the exact statement how to spec this out um taking into account that inval syn can is fine jump in between these two yeah and we'll just then publish it in some on some of the channels that is ready for review

Tim Beiko: awesome uh yeah thank you both uh

for bringing this up um anything else on this okay

so next up uh I guess I wanted to bring up Gorly um so originally I think we we thought we would uh upgrade Gordy to Denon before the holidays uh obviously with the CL spec change that's pushed things back a bit um so I think you know realistically if we wanted to upgrade gordley before the holidays um the lay list we could do that is on December 20th which means in like one or two week we need client releases out to do

this my feeling at this point is this is unlikely um unless I don't know if client teams disagree with that maybe now is a good time to voice and okay if if that's the case so if we're feeling like uh it's it's really unlikely that we do get uh Gordy Fork ready to go out in the next week or two um I think we should have a proper announcement about Gordy being uh shut down so we've already said it was deprecated um but uh just to clearly announce to people you know when is the network literally going to go off um and obviously the anyone can validate on

Gordy so it's not a call that uh like client teams make on their own but client teams do run the vast majority of the validators on the network uh so the day that all the client teams decide to shut their validators down um at the very least it's going to cause a lot of un un instability on the network and it's you know unclear how many other entities or orgs will keep running uh validators uh long term there um so I was curious to get a feeling uh from teams around you know how long should we keep running teams validators on Gordy once it's upgraded to denune I talked with a couple people ad hoc this week and the the rough number that I got was

maybe something like three months and then potentially we do like one month where we um one month where we uh start doing you know slowly shutting down validators to maybe do some Controlled Chaos testing or stuff like that um but yeah curious how people feel about that um so there's two two comments in the chat saying until we Fork mainnet which would probably be less than three months it' be closer on the order of like one to two months um if that's the case then I think that raises if no one wants to run the the the nodes for like three months after the fork I think that raises the urgency

as well that we should announce this because it might be effectively like three months from now or something um so anyone I guess yeah does anyone think we should do longer than after the magnet Fork happens because there a couple comments in the chat about that

Gary Schulte: we know um how many uh infrastructure providers are still using

goras

Tim Beiko: a lot

Gary Schulte: yeah that that would primary concern I think is that we want to give them uh the Controlled Chaos option I think

Tim Beiko: yeah I I I my personal feeling is like main net is like maybe a bit close it's

obviously we don't know when we're going to Fork mainnet but if it happens like a month and a half after Gordy that feels a bit short but it's maybe the shortest possible we can do um I think there are yes sorry go ahead

Parithosh Jayanthi: yeah my main argument against announcing until we bunch mainnet is that there's no date for main net I would prefer just a static girly Fork plus three months something like that it's easier to communicate and it's easier for people to and that can by default mean that mainnet is already merged at that point uh sorry already

F

Tim Beiko: yeah um Gary I

think so Perry I think is arguing we should gate the Gorly shutdown on the Gorly Fork date but then there's some comments saying we should gate it on the main net Fork date um one thing that's nice

sorry

Barnabas Busa: based on the girly for because if if something very happens during the girly Fork then maybe it's going to take more than CH to get it fixed before we can even Fork the polia or maybe if we push out a fix on girlyy uh it might take weeks or months so right I I think uh we should assume that everyone is going to run their validators at least

the client until we hit mean a plus uh few weeks here and there

Tim Beiko: um yeah there's a comment by Ansgar saying maybe we do the later of Gordy plus three months or main net plus one month I kind of like that um it'll be a weirder thing to explain in the blog post but I think it's probably the the the soundest approach um yeah does anyone disagree with that and then yeah there's another comment also in the chat around you know

didn't we Fork sepolia first last time but we agreed to Fork gordi first this time because it's uh end of life so we uh if we break it it's it's less bad give worse a polia we want to keep around for a longer time um so yeah does anyone yeah does anyone disagree strongly with uh Gordy plus 3 months or main net plus one month uh whatever happens the latest and obviously in a case where we have something break on Gordy so badly that it takes us 3 months to fix we can also write another blog post you know

saying we're going to extend things um but that that feels unlikely okay I'll take this as a yes um and then the other question I had so once we hit that point um do we is are there any specific tests or anything we'd want to run are ways we'd want to like handle uh shutting down the client validators uh that I don't know give us more valuable data like the obvious thing is just triggering inactivity leaks but is there is there a period of time over which we'd want to run some

tests in like a more chaotic mode on Gordy um and should we pre-announce that some way so saying you know after 3 months it's going to move to like this chaos testing period for a month and then will shut everything off does anyone have strong opinions on that

Parithosh Jayanthi: perhaps we can just the time point where we said we're stopping support for girly as the time Point chaos stuff starts you can do chaos for roughly a month yeah and I would advocate for everyone than doing honest exits so that

whoever's left over can just continue validating until they feel like it

Tim Beiko: yeah and a a month feels sufficent I assume a month gives us enough time to try out any flow or thing we'd want to try out

Parithosh Jayanthi: yeah I would say so I can't imagine too many things that we want to try

Tim Beiko: okay uh there's a question how long will the exit take months

Micah Zoltu: should people who are exiting continue to be good citizens and

validate until they successfully exit

Barnabas Busa: I think we could just slash do a MTH slashing that should be a lot more fun and a lot more quick

Potuz: it's not quicker

Barnabas Busa: oh they would still need to exit right

Parithosh Jayanthi: yeah they would still need to I I would actually just case it's per uh validator basis so if you decide to be good you can keep it up if you don't then Network's dead anyway

Tim Beiko: okay so I think overall this makes sense so three months after Gordy

or one month after menet whatever comes to latest then we have one month where we do some testing and then we assume you know at least from the purpose of from the point of view of client teams and EF devops um it's no longer maintained or supported but obviously anyone can choose to run uh their validators on gordi uh if they want um and then the other thing is we won't have it uh as like a canonical net test net for the future hard Forks uh so after this Fork it'll it'll start being out of sync uh with

May that um Poes

Potuz: half joking but uh but if it's really an issue for devops we can always hardcore the

high higher exit chn on

girly I actually don't hate that

Tim Beiko: so meaning that you changed does gordley has specific configs basically that are different from

Potuz: we can we can hardcode more validators exits for

blog

Tim Beiko: I know on the E we never wanted to do changes that were just like only applied on testnets but if you're all fine doing that on the CL side

Parithosh Jayanthi: um isn't it just a spec value though

Potuz: yeah

Tim Beiko: so and and I assume this has to go live with the hard Fork though right yeah uh um maybe let's I don't know if

somebody can make I assume this is like a literal oneline PR where you change the number if somebody can make that PR and then just post it on the agenda for ACDC next week I think it'd be good to get like a proper consensus layer discussion on it and it it it might be a good a good idea to do it um but we should decide soon so I think if yeah if we can get a a PR for this uh in the next couple days and then um yeah confirm it on ACDC but I think for everything else um and I guess yeah if anyone if anyone has objections to any of this on ACDC next week as well we can bring it up but I'll I'll draft the announcement following

everything we discussed today but I won't publish it until the the call next week

Barnabas Busa: but this is not yet implemented in any of the clients right

Potuz: what this is not officially I was just joking but uh every client implements uh we we take a file with the spec constants so we just need to change the spec constants that the presets that were that we saving for each for each net

Tim Beiko: and I guess yeah are the presets Network specific or are they is there just minimal and Main net I thought there were two but is it one per

test

net

Potuz: so they are minimum main net uh however you can just load anything the fork ID is one of the values so it's this is something that we can just change on two networks

rep

Tim Beiko: okay so they're okay they coni values not PR values got it

Potuz: yeah both of them

Tim Beiko: yeah yeah look I think if if we want to make this change on the CL and it's easy and teams like it then you know we can discuss it but um yeah we should probably make that decision on the CL call next week week and I assume it's a small enough change that if we decided to do it it wouldn't delay anything

um okay um sweet so let's do that um and then uh hopefully by the end of next week we can post an announcement about Gordy just to uh yeah to let people know else uh on that okay uh in that case last thing we had on the agenda was a proposal by Micah or Not by Micah but advertised by mic for E multic call um do you want to give some background on this

Micah Zoltu: sure so the short version of eth multic call is basically the same as eth call except for you can do multiple transactions in a row that are applied in sequence on top of a shared State and so you can um the simple example of this is very commonly you need to do an erc20 approval followed by an erc20 transfer and um you can queue up both of them basically and simulate both of them against you know head of main net for example and see what the outcome is instead of whereas right now you can't do that you have to do the approval put it get it onto Main net and then do the E call afterwards unless you use specialized tooling uh this has come up in multiple times so a long time ago I wrote a plugin that for nethermind that I use that does this hard hat and Anvil

have similar features called main at foring and and whatnot Cena from the guest team built or wrote a proposal up in the execution apis a while back and then um another team built off of his proposal and had another proposal and so this basically just keeps coming up that people want this and so we finally got to got together and nethermind and gu have um implemented the spec that we have for this and currently we have tests and we're basically just fixing miscellaneous bugs and coordinating resolving differences between clients and so we're not quite to the point where we can't make changes to the spec anymore and we wanted to run it by the cord devs and see if anyone has feedback and um before we lock in a

spec and actually put out in release clients and so again this is currently implemented nethermind and gu we'd love to get it implemented in Aragon and Basu as well um the spec is linked in chat by Tim there uh the big differences between eth call and this is besides just the ability to do multiple calls in a row is uh we the jsonrpc method is named eore multic call V1 and so the purpose of this is of course versioning because we've run into problems before we need to make a small change or something that's backward and compatible to aart PC endpoint and so um we added the V1 there and this is something maybe is a little bit controversial people have other ideas we talked a lot about various ways to do versioning of Json

RPC um we don't necessar have to do it this way this is the way we all decided was the best but it's open for discussion we also added in here eth transfers now show up as erc20 logs from address zero um this is because people who are doing accounting on chain um it's very frustrating to have erc20 and so this is we felt like this a good place we can kind of test this out and this idea of having eth transfer show up within a transaction as logs and this is um there's a config flag in your Json RPC RPC request where you can enable or disable this so if you we don't want I think it's off by default so we don't confuse users who aren't used to receiving e transfers in their logs um

it also allows for Block override so because you can do multiple calls we also have the concept of these calls are inside of blocks that you can control so you can set things like the time stamp on the Block um the block author basically any field on the Block you can set um this is particularly useful for things where you want to maybe simulate what happens if I you know vote for this proposal and then three weeks later I want to see what happens when that proposal is actually executed for like governance contracts and whatnot and so the idea is is that by overwriting the block you can set the time stamp of the next block to be you know two weeks in the future or whatever and then your evm is going to ex as if it's two weeks in the future so this allows you to do

better simulation of things like that has state overrides state overrides I believe already exist in eth call for several clients so that shouldn't be anything new there really um it also does allow pre-compile overrides though so you can replace a pre-compile with some evm code this is particularly useful for EC recover because it makes it so you can simulate what happens if you did have an accurate signature for a thing you can see how the execution would flow and so you can override the EC recover pre-compile with some other some code code that just like always returns success or whatever and um it's very powerful because it allows you to do things like simulate permit to or permit um an erc20 contracts uh it

also ignores the normal validation of no calls from contract and I believe e call does this as well so I don't think this is new but um this is important because few hard Works ago we disabled the ability to do calls from contracts and this um makes it kind of enables that for this e eth multic call contact only not of course not for execution on mimet and this allows you to you know do the simulation of governance contracts time lock contracts stuff like that and the last thing that's a notable difference is we have two different modes one is validation on one is validation off validation off basically just keeps the client's current eth call validation semantics so whatever your

client does for validation keep doing that um whereas the valid validation on that serves two purposes one it's standardized across clients so eth call currently the clients all validate different amounts of things in different ways like I think for example nethermind just completely ignores your eth balance and allows you to go negative effectively in terms of this gas spending whereas I believe gu does not allow you to go negative error and so you get these weird little idiosyncrasies between clients with eth call and so we're trying to use this eth multi call as an opportunity to try to standardize that and so this validation mode allows us to do that it also allows us to have a kind of more strict eth call and so when you're trying to simulate something that um just before you deploy you run it on

Main net you want to make sure that this will actually run on mainnet ahead of time and with eth call previously you could run it but you know because it wasn't fully validating the transaction you could still error on Main net and it was very frustrating because you'd waste gas and so by having this validation mode on it basically makes it so you are doing exactly like if this was on a main net chain almost all the validations on and you can look in the in the spec there's a couple of things that are not validated of course um transaction signatures are not validated in that mode and I believe the no calls from contract is also not validated um the ask for the cordev team here is basically just take a look at the spec and please give us feedback we would like to get this out into Mainline

on the various clients um sooner rather than later so people can start using it and apps can start building on but we also want to make sure that everybody has an opportunity to give feedback and discuss the last thing we want is to deploy spec that everybody you know if they would have been given opportunity would have said oh wait this is a bad idea because X or Y and so really what we just want here is everybody to take a look at the proposed spec and like I said there's implementations in gu nethermind if you want to fiddle around with them um you're also welcome to join us we have a little weekly call between the various implementers and parties involved and so if any wants to join talk on there or um feel free to talk to us you know Discord or telegram or

wherever if you have any feedback and that's it if anyone have questions um fre happy to answer anything

thank you any oh Dan

Danno Ferrin: so I just barely seeing this spec um one feature that that's I would find useful for some of the work I'm doing is rather than moving a pre-compiled call and giving it code is the ability to say here's a set of inputs and here's a set of outputs you're supposed to give if you get a call to this address is that something that there be for that in this specification

Micah Zoltu: um we talked about different ways of handling the pre-compile contract one have a saxophone in the

background oh was down um so we we've talked about a few different ways to handle the pre-compile overrides U one option we talked about is just like doing EC recover um just special case where you can just override to recover because that's most common we think of the rest of them are like math things there's not a whole lot of reasons to redefine math in your um in your execution the tricky part I think is with what you're describing with the kind of here some inputs here some outputs is that it makes it um It's actually kind of hard to get that into Json RBC right so we can do kind of bite arrays we have a mechanism for that via zerox strings um I think the the other

solution I would suggest for that what you're describing is someone can make a contract and even Deploy on if they wanted and that contract can just have um some State and because we can do state overrides as well we can give the pre-compile contract in question some state so you can basically say override it with my fixed input to Output mapping thing and then you just have your you define in your um your state overrides what the input output mapping is and so you can just literally put kind of write a mapping in and so I think there is a way to do what you want that being said I'm definitely happy to talk more about this and if you have other ideas on how we can get this in I'm not against what you're describing I do think what we have could satisfy your needs um it just

might not be quite as simple way

Danno Ferrin: okay because I mean thinking of using this for like l2s let's say there's a system contract called get like L2 L1 bridge and all sorts of stuff that may not be reflected in etherium state um so I guess I'll call in the call and I'll put proposal I don't think it would be an array a b arrays I think it'd be an array of structure we have input in response um but yeah I'll definitely call in and workshop this because I think there's a huge Market for here's a magic value here's a magic output and it's completely external it's the evm what those are and it's not necessarily like derivable from the from the call values

Micah Zoltu: yeah I definitely think we can make something like that work I don't know what the exact Design's going to look like but if you we out to me or

um any of other people mentioned in the pr or just comment on the pr we can definitely have a discussion I think it's definitely possible to do what you're looking for regardless of how we do it when are these calls um currently they are Monday I think Monday morning UTC um all right I don't know the UTC time check in real quick uh Monday around 13 o'clock UTC is when we currently have them um and we're also all available on various messaging platforms if you want to talk there

Danno Ferrin: and where's the website with this information is it in the log somewhere

Micah Zoltu: yeah I'd say if you scroll up a little

bit in chat here um Tim post did the spec PR that's the I don't think we actually link to the calls in there but we can we can do that um and if you feel free to just drop a message to remind us in case we forget

Danno Ferrin: yeah I'm not seeing a link to a call in the spe PR I'm looking at that

Micah Zoltu: yeah I don't think it's in there yet so um either message me on Discord after and I get you invited we actually talked about this just before the the meeting um about get making the calls a little more public previously there kind of invite only between the teams implementing um and so we will we do have plans on getting that link out there and if you just follow subscribe to that PR it will almost certainly show up on it before Monday I

hope there go just post a link to the calendar invite any other questions concerns thoughts sounds like not okay so just please reach out to us if you have any thoughts or feedback if we don't hear anything from anybody then we'll probably move forward with getting this merged into Mainline gu and nethermind once all our inconsistencies between clients are worked out um we're pretty close unless we get feedback from someone so please reach out and read this back when you get when you get a chance

Tim Beiko: thank

you um before we wrap up uh so in the chat uh there were some more discussion around this uh idea that PO is brought up and I think we've landed on a consensus that it's a bad idea and we should not do it um so instead you know simply keeping Gordy configs and presets as is uh keeping the like Gordy plus 3 months May net plus one month and then some chaos testing um but not trying to mess with like the amount of validators that can be exited from Gordy per Epoch um so I just want to call that out one last time if anyone feels strongly we should change those config on Gordy otherwise I think we can just call it a day and move

forward with um with the same plan but no no proposed changes for gordi so last chance if someone wants to make the case for it okay uh doesn't seem like it so um this is everything we had on the agenda was there anything else anyone wanted to bring up before we wrap up okay then uh yeah thank you all for hopping on and we'll see uh some of you on Monday's testing call and then most

of you on uh ACDC next Thursday um yeah have a good day everyone

thanks bye bye you bye-bye

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