All Core Devs - Execution #174

Transcript

[Music] for

Tim Beiko: welcome everyone to acde number 174 um so we'll cover Dan today some updates on the Gordy Fork client updates uh there's also some RPC discussion that uh people wanted to bring up and then um aside from that uh Gom has a veral EIP to discuss and then um given its Dev connect next week and US Thanksgiving after that uh it makes sense to figure out which calls we want to have in the next couple weeks and whether we want to cancel so any of them um I guess to start um so on the Gordy Shadow Fork uh Perry I believe you

shared this analysis uh do you want to give us a quick walk through how things went

Parithosh Jayanthi: yeah um so we had a girly Shadow for earlier this week um we basically synced up all the nodes to gly head then started a new Beacon chain and forked off a small section of the nodes so roughly 21 nod and afterwards we set the dun Fork so we had um we enabled tenun on gly um since then we've been running zatu to collect all the metrics so block blob arrival times Etc and the analysis is shared there I think there's nothing insane that pops out there's a couple of

like regular spikes we're still not 100% sure why um but besides that block processing times and gossip times look really low but that's also kind of expected considering it's a really small Network um the main takeaway or the thing that we're yet to properly analyze is um the amount of time it takes to build payloads Etc doesn't look very high so and we're still getting organic uh transaction gossip from gly so the question is just is there anything else we should be trying on this network before we delete it

Tim Beiko: thanks anyone have anything they would like to see on the shadow Fork

Danny Ryan: yeah I mean my intuition is given

we're doing the CL networking rework um and given that so far things look stable and you know it's a good test that we probably have what we need and we're probably going to want to run another one and potentially after we run another one another one at scale but after we have the rework on the consensus layer

Tim Beiko: right this is basically our Baseline uh before that change comes in

Danny Ryan: yeah so I mean as a baseline it sounds like it worked I don't I don't personally see more stuff to do right now

Tim Beiko: so I guess for the next ones um do we see value in having it and on Gordy again uh would we want to go straight to main net for the

next uh Shadow Fork um yeah the teams have an opinion about that or devops

Parithosh Jayanthi: I think mainly we prefer continuing girly Shadow Fork because it's um It's relatively most of the upgrade changes we're going to notice up here to peer and renting more nodes that can support the girly network is cheaper than renting more nodes for main net we're definitely going to do a main net Shadow for before we do the official main net for but the question is just do we do that earlier or later

okay

Tim Beiko: okay in that case I think yeah it probably makes

sense to do gordi again as the first one and if there's no issues then move to

mainten net

Danny Ryan: and yeah I'd be an advocate for that doing a large Gorly after doing a small Gorly then doing a small main net doing a large main net but again after we're pass another couple of Dev Nets with the fix or at leased one

Tim Beiko: yeah I agree I would do at least one devet with uh the final spec changes before we do another Shadow Fork does anyone see the need to do another Shadow Fork before that

yeah Dev sorry you broke up a bit there

actual underlying logic uh we heard about half of what you said Daddy how about now it's better um I should just barring unless devops is just trying to trength and devops tooling I wouldn't continue to do them now they used to tesing in proud We F

Tim Beiko: nice okay anything else on the shadow fork

okay if not so the um uh second thing on the agenda so

there was a PR to add uh the Bob gas price to uh East fee history and then in the comments there uh there was a proposal to also have like a single RPC method that returns all of the gas uh price related values um but maybe uh Alexi do you want to start walking us through your PR and then we can we can discuss sort of the the alternative proposal that that was posted in it

uh yeah um let me try to present um sure all see

just um let me know if you see the screen yeah we see your uh editor and your terminal okay and now okay we see you're getting T oh cool uh so let's try start from um very B description um uh what is uh blob gas and why do we need um API for it uh so block guess is a like I guess uh in addition to regular one uh but uh uh which is used for blobs uh and

uh is uh relevant for blob transactions um now and uh uh to understand how much uh um what price um maximum price for w gas uh is needed to uh we mentioned in the transaction um we need to provide some kind of estimation uh to include this data after all uh in to block transaction uh specifically the fil ma P Block

vs uh to do this uh uh we can quiry it through a new uh endpoint there are two variations um uh initially is uh gas prices uh was provided uh uh and uh the form of this point uh it's a pretty simple uh method that returns several various regular guas uh which can be used like a uh

regular guest cap or the transaction uh blob guas and Max priority which uh uh can be set as a tip for uh transaction which uh uh started working from AP uh 1559 uh uh and uh a simpler version of uh if we just return blg price and um um it can be used when posting um when sending blob transactions um I have no strong preference um uh I thought that um the

first approach uh could be more optimal because we um return this data based on the same uh structures like box and uh it could be one method because uh usually all these vares are quered uh together um but after all we can do just a bdge call which is uh can be done quite uh simple uh simply and my work too another update is uh for uh history uh in addition to regular gas ratio and uh uh basp uh Fe per uh such kind of gas uh we could

uh add the uh the same for blob gas and uh uh other fields uh uh do not need uh any change because they like report are about prorally uh that's update would like to propose and uh happy to hear uh feedback

Tim Beiko: so thank you um does anyone have thoughts preferences on the various options

I would post the link with the

examples and description

which

Tim Beiko: okay so there's a question about whether this already exists in graphql uh does anyone know pretty unlikely it does not okay um I mean I I shared some thoughts on the PR but I generally would prefer to

have eore blob gas price because that sort of follows the the pattern that we currently have and I don't you know unless there's like a strong reason to do the gas prices uh so I was hoping someone might make an argument for that but like as it is you know we don't really need to return gas price as far as I know because that's kind of a legacy value we really just need the max priority fee and the base fee and now the blob Fe The Blob gas price so I would prefer to have it as a separate method and just expect people to batch the RPC

request got it and I know yeah so there were some comments on the agenda in in the Discord now for um having a single call I yeah does anyone want to make the case for why batching them in a or why combining them in a single call is better if not um it feels like yeah it feels like we should at the very least add blob gas price um that seems kind of like a no-brainer it also seems uh it also seems like a no-brainer to update e

fee history that also include the data there um how do people feel about merging those two um and then if I mean the bundled method maybe doesn't have to be part of the spec but if clients want to offer it um they obviously can just add extra rpcs but that at least on the Json RPC spec we'd have a single method for E blob gas price we'd have the blob values as part of fee history and then the rest is sort of an optional thing clients can do oh and there's an argument that clients should not do stuff that's not in the specs

uh which unfortunately we can't control what clients do but I guess yeah yeah does anyone disagree with merging the single um the single blob gas price method and the changes to fee history and not having the combined one and worst case we can also always do the combin one later if there's enough demand for it I'm not sure if there is any L2 people or someone who was working with ethers who wanted to chime in since they're the people who are using I guess not yeah yeah okay so I guess

yeah let's oh sorry please I say we can try and follow up with those folks yeah asly but yeah we'll move with the the one method and update in Fe history

yeah

Tim Beiko: okay anything else on that okay if not um anything else on Denon at all uh that wasn't included on the agenda okay then uh next up uh Gom uh you wanted to discuss uh veral proof

verification precompile

Guillaume Ballet: uh yep um so um I mean it's more like uh I was trying to yeah bring people's attention to it uh so it comes from a conversation I had uh with some people from open zlan at first and then other people afterwards uh let me see if I can share my screen yeah should work um so yeah it's it's really about collecting input the the idea is simple it's uh that because veral uh entails a lot of complex math updating a lot of

tools uh the the idea that came up would be to use a pro verification pre compil so offer a pre-compiled so that uh for example Bridges or uh I forgot the word for for l2s but uh uh yeah L2 L2 Bridges let's call them uh or even application developer could verify veral proofs so that they don't have to to wait for uh for all the libraries like like opens Z plan like uh like Foundry to to get up to speed and uh and like get up to speed and Implement that in in solidity so it's just about adding a simple pre-compile So currently I

suggested xx21 as an address U but yeah of course that can be changed and the idea is that it receives a chunk of memory uh that starts with a version bite and uh then just uh the proof where where the proof data can be found uh sorry actually so it first receives a version bite and then a location memory where the proof data can be found along with its size and also the state root of of the tree that is uh that the proof is proven against um and what the pre-compiled does so it's upgradeable if we want to move on to different proof system but if version is zero we use the the standard uh polinomial commitment

scheme suggested like polinomial commitment scheme based multi prooof that that was suggested suggested by danrad and otherwise uh so we return one if the proof verifies and zero otherwise and there's also like the EIP also describe describes gas costs so so uh I think the model is not really complete for example I I realize it's missing the some data to actually verify the the IPS uh thep approv but that will be updated but the general idea is uh yeah you have you have this constant Point cost that corresponds to every time you need

toize a commitment so it's uh it's paid for each commitment get that gets distalized and then you need to evaluate the pomal at some opening point so you also pay that for each uh for each opening you have to do um yeah there's not much more to that I mean clearly it's uh it's something that needs a lot more input so that's why I want to uh to bring your attention to it uh of course if there are questions I'm happy to answer but it's more like a yeah a call for for CFS to to pay attention to

Tim Beiko: uh there's a hand up by Def connect

Berlin yeah hello um hi this curve is over bander snatch or sorry like this approving scheme would be over bander snatch the curve

uh Bender wagon Bender wagon

Guillaume Ballet: okay so I guess my question is how it relates to the bls2 curve and if there's any interplay between those set of promiles and this one uh how does it relate yeah I mean the I forgot which of the two Fields is uh is the one from BLS uh but otherwise it's my understanding is that it's a completely different curve I'm not an easy uh yeah elliptic curve expert but uh my understanding is that they are

different and so um you could potentially yeah I guess use that uh that precompile that BLS pre-compile but you would have to reimplement all the proving yourself all the the commitment sorry the the multi prooof uh proving yourself yeah so yeah that means that every application developer would have to reimplement that and the goal of this contract is to save some time right yeah so we just have pre- compiles for both then because that's something I'd like to do for the next hard Fork is the bls2 381 curve um but yeah it sounds like like they're like

almost similar but not quite exact so they are completely different curve

Dankrad Feist: yeah so no the uh this the blf uh precompile cannot verify um the work proofs we could add a bner snch pre compile I think that would actually also make sense probably um I think my preference is actually to have a state verification pre- compile and the reason for that is that uh that we when we change the state in the future we could make it Backward Compatible so that smart contracts can be built that verify a part of the state

and you can just upgrade uh the state commitment and the smart contract uh could be yeah completely the same and would um uh yeah so it could be an immutable smart contract and uh I think that would be preferable rather than having to have lots of smart contracts upgrade if we do need to change the state comit in the future again

Tim Beiko: got it uh Dano you had your hand up

yeah

Danno Ferrin: yeah um this might be a controversial take on this but I think one of the great things about 4788 um as a pre-compile is that there is um evm code that says this is the pre-compile this is the canical answerer so this kind of goes against kind of some of the idea that you know why wait for open Zeppelin to implement this in solidity um what if all pre-compile is going forward that the canical form is a form of solidity or Viper or fee or whatever and that defines it in you know modulo gas you know we're going to have to change a gas schedule on that and that the clients could do a pre-compile that would optimize that but would truly be a pre-compile at that point there would be an uncompiled version that is

the Canticle this is a reference implementation this is the correct state it would solve a lot of problems in you know devs who aren't you know phds in cryptography trying to you know get the small little details of these curves correct when they don't necessarily have a large set of um test cases to run against

Tim Beiko: and so the implication here is you can Implement any of them in in uh in solidity basically

Danno Ferrin: right and early on when you don't have you know when you're work doing the next hard work the client you just slide that precompile slide the evm in and then when you optimize it you come check it you got some local code it'll always be

correct

Dankrad Feist: so this curve specifically will be used for work trees anyway right so all clients will need like I mean we are we have already created libraries for that um so I mean I think like currently the general position is that client STS never uh touch the cryptography themselves well unless they are really comfortable with it and that we have readymade libraries and that's already the case for verl in this case

Danno Ferrin: so yeah yeah verle does kind of change this argument a bit since it's gonna have to be part of the client but I think it's just an idea I want to put out there for like cryptography not necessar the idea is good I was commenting on this but

particular yeah

Tim Beiko: this is a bit off topic but could

we do that for BLS or because I remember like the whole debates around evm Max were to allow us to build BLS on a one but

Danno Ferrin: I know the Epsilon team at one hackathon did through evm Max the existing precompilers I don't know if they moved on to bls2 and using evm Max right

Tim Beiko: got it okay and I assume I guess back to just the original EIP I assume there's an East magicians link people can raise uh raise issues there but were there any other questions

um about the the EIP Are there specific implementations you can point to of this uh like the multi prooof PCS

Guillaume Ballet: uh the multi prooof PCS itself yes they are there's I mean one of them is go veral the other one is um there's a python implementation reference implementation in fact by danrad and there's a rust one uh I think oh yeah there might be a nether mine one to a c one by nether mine um but yeah there's no there's no uh implementation of a pre-compile itself but it's going to be easy to to couble together if that's uh

that's what you need yeah just curious maybe toss links to those repos and the eth magician

St

Guillaume Ballet: sure

Tim Beiko: cool anything else on the precompile okay Ipson on there's a comment around saying uh they've started uh implementing BLS at evm Max and after Dev connect we'll know if it's possible um anything else people wanted to chat

about uh I had the call scheduled but there's anything more substantive we can get to that first if not um so next week uh next week There's

Dev connect um so next week we should have had a testing call on Monday and ACDC on Thursday the people want to keep either of those um yeah does anyone feel like there's value in having them or should we wait until either the week after uh just as it heads up that'll be American Thanksgiving on the Thursday um yeah

Danny Ryan: I was thinking if we don't do

the consensus layer call um I might ping on that Thursday the Discord and just ask for like a quick written update from the consensus layer teams on getting through the networking changes and surface any issues um that maybe have Arisen or unknowns at that point and we could do a similar thing the week after on like Wednesday if we don't do the Thanksgiving call us Thanksgiving call

Tim Beiko: we could also have the call on a Wednesday you know if we want to have one the week after and not skip two weeks in a row

Danny Ryan: um well and I guess one of the main things that will come up in that time period is if there are open issues or questions related to this update so I'm I'm also okay like

doing the Ping a couple times and then scheduling an ad hot call if we need it

Tim Beiko: okay that works for me does anyone have oh Ben

Ben Edgington: uh yeah just um interested in in signaling so um just delving back into into history uh when we were planning um the capella and the den canun upgrades we um committed we broke the on pass about delivering both together by committing to doing 4844 as a fast follow on to uh capella with withrawal um we're talking about June July time

which uh is amusing in um ambitious in retrospect but um I'm concerned about the Optics you know these week here and week there add up to delay over time we've seen it time and time again um and I know everyone is working super hard on delivering um denb canun but uh because I'm inside the process but from outside the process you know canceling two core Dev calls in a row doesn't the Optics don't look great to me um and I'm starting to see things hotting up again on the the need to deliver this thing so that uh would be my case for keeping the calls obviously there's no point if nobody's going to be here but uh I think generally that should be our default um approach

Tim Beiko: yeah I'm

also I mean I have less of a strong opinion on the dev connect one just because there will be a lot of people there even though there's may be a bit less than than expected um I do like idea of having your written update though from client teams so that we can still get a status update and I'm happy to keep I'm not American so I'm happy to do the one on us Thanksgiving the week after that and and um or to move it to uh or to move it to like Wednesday if that means more people show up um so either of those is fine for me um yeah and maybe I don't know maybe we can we can get teams to chime in on the Discord if they have a preference but

um yeah I I agree like skipping two uh might not be uh ideal so we can maybe do next week's async get an update from teams and then um figure out the best day for the week after that do people think that make sense okay I'll post something in the Discord uh get some more feedback from client teams oh now there's more and more support for having the calls okay I I'm fine either way uh I

don't know Danny do you want to do a quick call next week

I

Danny Ryan: I don't mind um I'm comfortable either way I might not live stream it given my remote capabilities and setup um I might even take the call from a phone but

uh I think we can probably getting

Tim Beiko: I think we can probably find someone to live stream um yeah okay then let's keep both calls um I guess okay let's default to this let's keep both calls if people if like a whole team cannot make a call and share a written update on the agenda and

we can kind of point it out at least on the call um but there will be a call and um we'll try our best to live stream it but worst case we'll just upload the zoom recording later and yeah if you're team can't make it just share uh an update

yeah

Danno Ferrin: when I toss up the agenda I'll make a comment to if you can attend to share it update in the agenda

Tim Beiko: sweet um anything else oh and I guess maybe the only one uh I just wanted to check do we want the testing call Monday

as well um or do we I especially given these award devs have become shorter I would lean towards cancelling next Monday's testing call though and just having ACDC next Thursday CD the Thursday after that and then whichever next I think the next testing call was was scheduled for the Monday after that one so November 27th but I think having just one syn call next week is probably sufficient um does anyone think we should have the testing call as well on Monday okay cool cool so let's do that

we'll add a note in the agenda and we'll share something in the Discord um thank you Ben for pushing us to stay on track um anything else anyone wanted to discuss okay well thanks everyone um I will see you all at or most of you at def connect next week and then uh we'll see everyone on ACDC uh whether you're at def connect or not

uh next Thursday um talk to you all soon thanks bye

thanks thank you by J

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