All Core Devs - Execution #168

Transcript

[Music] foreign um and

Tim Beiko: we are live uh welcome everyone

to acde168 uh so some updates on dencoon today on devnet8 um like I mentioned in the chat uh it'd be good to have a conversation around the deployment of the 4788 contract um and then we have some more updates on uh whole sky and uh the testing that's been done there um some updates on the whole EIP ERC repo split and then two other things to discuss one just around naming the fork specs so that they're easier to reason about and then we have someone to discuss a new EIP EIP 712-7212 um I guess to start

um Perry do you want to give an update on devnet 8 um you posted about it on the agenda

yeah

Parithosh Jayanthi: I can give you a brief update on that beat um so we have the chances um yesterday and since then the Chain's been mostly fine we did hit a couple of issues overnight where um prison got stuck as well as Lighthouse and ethereum JS Lighthouse and tmgs have been fixed in the meantime and I think prism already has a PR but are waiting for it to be checked and merged um in the meantime we've just reallocated a couple of validators and we're we're finalizing and people can use the chain as expected you can expect

the blob scan and some other additional tooling to come up shortly but the beacon chain Explorer is already live

Danny Ryan: what was the domain of the problem

Parithosh Jayanthi: uh I actually haven't looked into either of them currently so I need to maybe the client teams can talk about that

yeah yeah

Danny Ryan: there's a new one from uh prison Lifehouse ethereum JS or any of the other team want to give a quick update

uh sofa

Sean Anderson: Lighthouse I think the issue is because we removed mplex support in a recent update um and that caused us not be able to connect to some clients uh so we just added it back in and it's like more

impacts on small networks which is why we saw it here

got it

Gajinder Singh: was that on every slot Lighthouse sends around two fcus one with the old head and one with the new head and when we were generating payload ID we were basically not doing unique Mess by the parent we can block route so basically the payload ID that was finally being provided was belonging to the old head and that was causing the block hash mismatch and once it's fixed now the correct payload the new Flash payload ID is generated and

refresh period is built for the latest FCU

Tim Beiko: and this this is the first time that this was triggered it feels like something that would have showed up previously no

Barnabas Busa: we didn't have version three before I think

okay

Gajinder Singh: basically I think these are these best are not in the hive where basically two kind of fcus to an old FCU and UFC user being sent and checked whether the payload is generated or the new FCU but yes I mean it was for this particular new parameter it was for the first time

yeah

Parithosh Jayanthi: we ran through a couple of the V3 related errors earlier this week um we just used a couple of local testing tools psychotrosis and we were able to get them patched relatively quite a bit faster than we usually would have and I think we also caught an English an issue where an atomized and get would have been forked and that was also fixed with some local testing which may be good I know the Netherland team had a few stuff they wanted to bring up and have potentially fixed by now

Barnabas Busa: I would also highlight that kratosis have been working very well for us so it would be pretty good if uh different paintings could also begin into looking into it and possibly giving it a try to

check basic interrupt not like a full Matrix of all kinds combos but uh just some basic big ones I think it would be very nice

yeah

Parithosh Jayanthi: to give you guys an idea on how we use it we kind of once we had an El ready we just made a list of the CL set already and just did that combination and then once the second El was ready we just separated that combination so we knew that all the CRS worked with one particular El and then we just combine the El networks together to get completely interrupted yeah and I've listened to the document there in case anyone wants to try it out

Danny Ryan: and so this has been valuable just like

literally just running local Nets like you're not even doing or partitions or anything

Parithosh Jayanthi: nothing at all we're kind of just running these tests and when we find something we can just send the Json config along with the command to the clan team and they're able to reproduce it almost immediately um saving us a bunch of debug time there and one thing I want to also mention in the end um I'll be bringing up um in the next call which is Mev related but we also have the entire Mev workflow now um so we should be able to do a lot of Meb testing there as well

nice mvv

Barnabas Busa: doesn't support the fork yet though

so yeah it's kind of a yeah it's kind of the chicken and egg problem we need the network is supported before the relays can support it and we need yeah you get it

Tim Beiko: but I guess does this mean we're now like we're now ready to get relays to support this

or yeah

Barnabas Busa: yes okay so this is what we're blocked on is relay support for the fork yes okay and they can test on kurtosis also so that's going to be very very useful

Tim Beiko: um Andrew I saw you had your hand up briefly and then it went down to John ads

yeah

I was curious about some talk about kotosis but now parentage has sent

one

goddess be

Barnabas Busa: planning to write a a very proper documentation about how to get started but the the small dog that party put together it it's really enough to get started but there's like a bunch of new features that we had recently added that can even do like high high scale testing with multiple nodes on kubernetes so it's even it's even good for bigger tests also

uh yeah

if you could when ready if you would share that one that will be great

I'm sure

Tim Beiko: nice did any of the other client teams

uh want to share thoughts about the devnet or how it's been going

um yeah I would like to give an update on on Aragon so we haven't joined the devnet 8 yet we've been mostly looking at fixing the hive test for Dan so like like literally five minutes ago I've checked in a patched Auto Branch um bring down the number of high test failures Pro like two just just two failures out of 38 tests so that there is progress there uh we need to improve our like the security of our transaction pool for blob transactions we need to

implement EP 4788 version two so it would be nice if that one gets finalized and then join devnet8 but we're getting there slowly but not steadily

Tim Beiko: got it thanks anyone else want to share updates

Marek Moraczyński: some from our site everything is working as expected uh we another mind passes Hive test we have a couple of issue but we managed to fix them before the devnet

started um one maybe interesting one was that Netherland uh um doesn't have implementation of worry for for it based on system transaction we had uh we we have uh still direct rights to State TB but it uh it turns out that uh we had some Edge case uh encoding uh actually three encoding issue but now it's fixed and we will we plan to move to system transaction

um yeah

Tim Beiko: Justin you want to give them a

bit from

base View yeah

Justin Florentine: so um we're still working on uh being ready for uh devnet eight uh 4788 is still in Flight um The Hive tests are not passing yet and we do need to break apart our 4788 Branch so that we can um include the beacon route in Genesis right now we're experiencing a lot of failures because those are like I said 4788 branch is not merged in yet so we need to separate those and um we'll move forward from there we're still working on passing all of the

um podcasts guys depressed

Tim Beiko: any other team want to share

updates or where they're at okay if not I guess um the last big spec question we had was um figuring out how we approached deploying the smart contract that's part of eip4788 and we discussed this on uh last call but uh I don't think we had strong consensus either way and at this point it's probably the main just blocker the finalizing uh the the Cancun spec um so yeah I'm curious if anyone has uh I'm curious if anyone has a strong

opinion on like how we should approach this um or if anyone has a change their thoughts on this since the last call um Danny

yeah I

Danny Ryan: I will make my case once more but also acknowledge that either methods work it's a bit of an aesthetic decision and I'd rather this be unblocked than uh push this Kick the Can down the curb again um but essentially you know I I think that this is a system contract um this can be elevated as such and live at a particular address and given that we have the opportunity for the EIP just to

be like entirely self-contained you know it deploys its own code and then utilizes and exposes it via just on the fork conditionally placing code at what becomes kind of a system contract address I think this makes Downstream tooling easier I think this makes test Nets easier I think this makes all sorts of things simpler you know it's a matter of just turning the EIP on for a given Network rather than also considering you know if the contractor is actually deployed it's likely that this will be precedent setting in other things where we might

want to have some sort of system type contract for example EIP I think it's 7002 is something that I think is pretty important which is execution layer triggerable exits to enable certain types of validator activity but I think it's likely that once we kind of experiment with this type of system contract that we do see more of them and so I you know instead of having n of these where we're making sure that for a given test net a given side net or given mainnet have the contract deployed we just have them be able to deploy them themselves again I think that that's the simpler more elegant more self-contained solution but I both work and I am ready to unblock

however y'all please

Tim Beiko: okay thank you

oh sorry

Lightclient: I guess I can argue the other side yes please uh yeah I mean I I really don't think that we should just enshrine code onto mainnet and I think it's maybe simpler for you know some other networks to utilize Beacon route contract concept because they can just turn it on um but it doesn't make main that simpler it actually makes the code more complicated because now we have to write something that says if we're at this Fork then we need to try this code into

this address and it needs to be hashed into the state route and so there's just like another branch of logic that needs to exist there then we set the precedent that if we need to do more of these we possibly end up with like some file that has a bunch of different functions that says if this Fork to play this code if that worked deploy that code Etc and it just doesn't seem necessary because we have a good system for deploying contracts and this is an evm contract and I think we should use the system that exists for deploying those things and we should be kind of a normal citizen on there and it almost feels like that's a little bit more of a generic approach for other networks who want to use different types of system contracts because then it's more of a configuration thing where in their

Genesis file they can say you know this is the address I want to call my system I want to do my system calls to and they can decide what code actually ends up going there and um you know possibly do something different than what 4788 specifies and you know if it's like really a problem for people it's on new networks to deploy this thing like we can have some automatic um setup with the Genesis allocation where if you say this you know 4788 EIP is turned on then it just automatically adds it to the Genesis allocation like a lot of this stuff can be done uh behind the scenes so yeah I think that putting the code again trying the code is a little bit more complicated and this is just this is a simpler thing and it it

utilizes the the contract deployment infrastructure that already exists

yeah

Danny Ryan: I guess my one pushback is like this isn't just code that gets to be a good citizen this is code that has like very special system logic around it with like an exceptional color um and so it's it's I think we end up mixing two things we like to enable a system activity we have to have some user perform an action uh otherwise uh it's not there and I think you do end up with conditional logic the other way as well because now I have to handle

what what is a reality where this EIP is turned on but the code's not actually there you know and then we have the test

that's very easy

Lightclient: that's very easy to handle like the call already needs to handle evm failures because it's just a normal evm call so you kind of just discard whatever error comes back

Danny Ryan: so there'd be no there'd be no additional tests in hive

Lightclient: I mean we can have an additional tested Hive that's probably good okay but I would rather have an additional test in Hive than more code in the clients yep

so yeah I don't know I mean I see the thought in the chat saying what if we forget to deploy it I mean we'll just deploy it

we can deploy it yes so I guess it's possible well so what I meant more like

Alex Stokes: if you're on some other network and like you forget to deploy on like the test net or like some roll up like it just seems so like one of us here is not going to go and make sure this contract's deployed for every other network that's going to exist ever so it's easier just to like have it as part of the four project I think

Lightclient: I feel like a lot of networks don't need four seven a dates or they they need a specialized version of 478 data they need to think about how it's going to look so I'm not really worried about it being

a little bit more complicated for them I also don't think we should complicate mainnet to make it slightly easier for l2s to have a feature

Tim Beiko: okay I guess I'm curious you have to hear from more of the client teams I guess is there another client team aside from get who is like in favor of the the pre-deploy through a regular transaction okay so does this mean

all the other teams are in favor of having it combined as part of the forklogic

I don't have a strong position okay

Marek Moraczyński: same same assembly

Tim Beiko: and I guess yeah so to the point of like future compatibility oh sorry yeah and sky can go before

Ansgar Dietrichs: yeah I wanted to just mentioned that in case we basically want to do this for all future could be that in the future there might be an instance where as part of the

initial deployment we want to set maybe exceptionally set some initial storage slot or something and we can't do that out of a normal transaction so in that case we would have to have basically deployment as some sort of Special Operations so if we wanted to have a standard the standard could only be that we do it in a special transaction of course if we just do one-off solutions for every such type then this would be fine

Danny Ryan: yeah it's an interesting argument meaning like if you had to initialize the memory to non-zero you'd have to do something additionally exceptional

Ansgar Dietrichs: could be that you just deploy a normal

contract and then as part of the fog only set a few storage slots there would still be a smaller at the point of clock Change

Tim Beiko: so I guess like clearly there's still some like the Virgin opinions do people feel it's better to debate this and discuss this for another week or that we're sort of blocked on this and we should make a decision now um in order to move forward as with the whole Fork as quickly as

possible

Lightclient: it doesn't feel like it's blocking right now but I would rather decide sooner than later because all the test networks we just didn't try to mention this is

Tim Beiko: yeah okay so does it matter if public business have different addresses yeah we can use create two right

Lightclient: well we can use a generated create Martin and the pr has a

transaction that deploys it's to any network that supports pre 155 transactions with the same address

okay

Tim Beiko: yeah I don't know it feels like it's pretty split uh feel like and I guess yeah so okay so Netherland is also against any approach besides the system transaction right he's part of the team and does anyone else have strong opinions so

in terms of like just the the the code paths um how how big like is it a significant change to do like in Fork deployment if not if not I don't know I would lean towards the in Fork deployment because it seems like there's slightly more support there and we can always revert it even though that's not ideal if people feel strongly the other way later but I

I think I think we probably oh okay so there's more people who prefer the transactional process not there yeah I don't know I feel like we'd probably be better off to agree to a direction and start working on that for like devnet9 or I guess you know maybe we defer it to like one week but I don't know it doesn't feel like we're gonna get new information in a week or I guess yeah maybe this is the right question like does anyone feel like an extra week of debating this will be valuable

or yeah I mean

Lightclient: we have to actually debate

it because I don't think that a lot was discussed between now and the last call we discussed on

okay so I mean

Lightclient: I would like to see what like when is the system deployment like the deployment by a fork really going to be useful on other networks because I think a lot of networks won't use 4788 or if they do they'll do it slightly differently and any new network like for a new network it doesn't really matter which approach we take because it can just be in China Genesis that's very simple so it's really a matter of networks that want to use 4788 that exist today

um I'm on

Ahmad Bitar: yeah I just wanted to say that regardless of the approach that we follow here I would like to emphasize the importance of finalizing the spec in general before going into trying to deploy another devnet so before going to like at least two weeks before divnet9 we should have a spec finalized with tests ready uh to have enough time to run our tests and be ready for the next devnet

Tim Beiko: yeah I I could agree like I'd rather make it call on this now and be able to move forward and I guess so if

if we do the bundled transaction approach it doesn't necessarily preclude us from not doing that in the Futures like just deploying a contract um naturally whereas I guess what we're saying is if we don't bundle them together um then it starts to become awkward because we then have a list of contracts that uh that we that we need to consider each time yeah and then yes okay so Daniel's

saying also that there may not be that many

Danno Ferrin: uh this contract is only a mainnet focused contract with the elcl pairing um not many l2s do that I'm not aware of any they might maybe they'll repurpose it for L1 root which means they'll do their own thing um I don't think we need to make much space for this other than just for how Maine that's going to use it

Danny Ryan: yeah exactly I mean there is gnosis also I think this is precedent setting for this type of deployment which the fact that we're talking about uniquely something that is c-lo is interesting here but like yeah do you

even if you want to give context on the appointment it's like a generic word

Tim Beiko: yeah do you maybe want to give a bit of context on the El triggered exits and roughly wide I would use a certain design

Danny Ryan: that's also that's also probably exceptional although

no no yeah

Tim Beiko: if we're just thinking about mainnet right it's not clear to me how much context everyone has around like how El triggered exits would work um and it might be helpful to just understand that a bit better the the to like make sense at this

Danny Ryan: I mean similarly right now 7002 is specified as a staple pre-compile which we kind of got into the Zone on this one

that maybe stateful pre-compiles don't make sense and instead we should be deploying code so in that if that if this is precedent setting then if we did something like 7002 then similarly we would have a uh contract or some byte code living somewhere that users can hit and then the system does something with respect to that so on this case instead of preloading the state with something like four seven eight eight for users to use users are triggering actions inside of this contract and then the the system is picking up uh stuff so like users trigger as it exits uh that are valid upon some Logic the then the

system picks these up and pulls them into the consensus layer um so kind of similar Concepts going on there but uh you know other things you could think about were like the example of removing the 256 historical routes um that are implicitly part of the stage transition function right now and put it writing them into State that's not cross layer that ends up being useful kind of in any uh evm deployment and is a definitely a nice to have especially in the context of statelessness to make things much more contained on that front but uh there's just there's a lot of examples you can think of that we might end up

going down that path summer across layers and we're not

Ahmad Bitar: um one of the other reasons that I also support uh system transactions is that I feel like I don't want to have a change in the state that is not like justified by a certain like transaction usually in ethereum when there is a change in the state there is a transaction that made that change that's most of the cases that I know of so I would like to keep that up even if it's deploying a system contract it should be like done by a transaction changing the state

Danny Ryan: so I can think of many examples where that's not the case withdrawals are those transactions I don't know um the other component of 4788 is actually that the system updates the state every every slot every block um and so and coinbase and all there's all sorts of like system operations that update the state I if we're going to be bound to that then we can't do a lot of things um and just because this is I don't know like to to to compare this to an irregular State change I think is a bit dishonest with respect to the other things that um we do to the the system but I I'm

I'm gonna stop debating this because we're at half an hour already um and I don't I don't want to be the only person that's holding this up because at the end of the day both methods work and I don't really want to block this anymore

Tim Beiko: yeah it does seem like it's pretty split I so in terms of just the code implementations if we go with just the pre is it easier to go from we've like just a regular transaction flow to

then adding the special deployment flow or is it easier to go the other way around I assume it's easier if we go with the like normal transaction that gets deployed that deploys the contract and then decide to make that into like a special transaction during the fork that's probably simpler for clients is that is that correct

Lightclient: yeah I think right now we're kind of compatible with the just deployed in a transaction yeah and if we want to support the deploy by F4 we would have to add that code and then have some tests

yeah

Tim Beiko: so I I would lean towards deploying it in a separate transaction for now

um if people want to keep discussing it and feel strongly about it uh you know we can bring it up in two weeks like and if people implement it and feel like it's actually a terrible approach and the other way is better you know we can revisit that and then add the extra code path in two weeks but I think for now given it's like pretty split um I would just go for the simplest option and so we can have it you know tentatively finalized spec move forward with this and yeah revisit it if we feel a strong need to does anyone object to that oh okay yeah so there's the last question about the regular transaction

is like it requires a transaction oh it doesn't require transaction key Matt do you want to explain how that would work

Lightclient: yeah I mean I kind of want to keep this debate mostly focused on whether we deploy with a transaction or whether we enshrine it because I think once we get into wants to play with the transaction there's a couple ways that it's possible to do it um there's a way that you can just arbitrarily pick a signature which kind of creates a synthetic signature you recover the address and then that address is like a one-time use address for a specific operation so if we wanted to deploy the same address at any evm network that supports

pre-155 transactions we could do something like that I think that's the best approach but if people are not as enthusiastic about that then we can't just have someone deploy it with a key there's really nothing wrong with that either

Danny Ryan: you fund that address once you pick it

yeah exactly

Danno Ferrin: this was used extensively in Shanghai attack recovery there's a lot of transactions with that online

Danny Ryan: you're gonna fund it like that

Tim Beiko: is that what it takes yeah I guess yeah just because I do want to

make sure we like all agree on this spec like this probably the most important thing so does anyone disagree with like client's approach to to deploy the transaction um so let's do that uh like time do you want to open a PR to the EIP or I don't know if your PR already had this

Lightclient: um it has it

Tim Beiko: okay perfect um so we should go ahead and merge this if it's not already done then anything else on 4788

okay sweet next up uh oh sorry oh okay that was a little happy Emoji um next up uh testnet updates uh so there's been some more testing on the whole Sky uh Perry do You Wanna give an update on this as well

Parithosh Jayanthi: yeah so we've we had the last tests last week and I think I also brought it up in the last call but we tested essentially 1.4 million validators and we were able to get finalizing that Network so we went with um recommending that as the starting size for host key um there's an onboarding document and a telegram group for some entities to share their Pub keys and then we'll be

generating the Genesis State using those pup Keys you the info is also available on the GitHub repository uh the only thing that's still kind of open and that we also wanted to test was in the earlier course we did we to limit the overall issuance of whole skate or roughly the same order of magnitude as mainland but the commitments we've received total up to something like 1.6 billion we initially thought okay maybe that's too much but while looking at the test net code we've kind of been starting every test match for the past year with like 10 billion um and that's been fine so we also tried a couple transactions moving around like 9 billion ether or something and nothing

broke uh on devnet8 so the question to the room is do you just take the allocation as is IE host key would have roughly 1.6 billion ether or do we just slash it down until we hit roughly mean that mean that size

Tim Beiko: so it's going from 1.6 I thought you said 36 billion

Parithosh Jayanthi: no 1.6 okay okay that's what we have committed um but if we were to Splash it down to mainnet levels that would be like I don't know 10 10 times lower at least

Tim Beiko: is there a reason to not do 1.6 billion if we've seen it work on the devnets

Parithosh Jayanthi: I think the earlier field was just that

we thought we hadn't tested that but apparently we have been this whole time

Tim Beiko: cut it yeah there's any client team feel like 1.6 is not doable or would cause a risk okay let's do 1.6 then

Parithosh Jayanthi: sounds good then we should have a chance to stay ready around Monday and we'll put it up on the GitHub repo and hopefully Clan teams have a chance to make the uses before September 15th that's the date we're aiming for Genesis so much Dave

Tim Beiko: anything else on house key

um thanks Barry next up uh Sam I believe had an update on the Erp ERC repo split yeah Sam are you on the call

I am oh yes nice oh my area is working great so um very very brief update uh three points so one we're going ahead with the split we'll be removing ercs from all the other types of eips uh first and then we we may be dividing it up further we'll see um second we're working on uh making our governance process more transparent and actually writing it down into a document um reach out to me on Discord if you're curious otherwise it doesn't really

affect you guys directly so just mentioning it here for fun uh and third um Greg was going to make it explicit that we're staying like one group uh or one organization yeah so that's pretty much it for the updates on the EIP and governance side of things thanks

Tim Beiko: thank you does anyone have thoughts questions comments

Greg Colvin: I'd like to add that um the governance will be such that the editors should never be in the way of making an upgrade never

Tim Beiko: um thanks anything else on that specifically

Greg Colvin: there'll be documents soon enough yeah we're working on that

Tim Beiko: yes Sam I know you had your you had a PR up with some of your proposed change do you mind just sharing either to PR or the doc in the chat if people want to review

Greg Colvin: they're really not ready for some of you it'll it'll probably take a few days to a week and then the next deep EIP Bubba meeting uh we should come to consensus on that and then we'll bring them back to the um to this meeting and we need to open up some communication with the consensus

layer and see if we can find a way to serve them

Tim Beiko: um cool then we'll wait uh till the darks are in a better state anything else on this um then Andrew you had just a quick uh ask so we have um we have all these Fork specs on the yellow side um and their name just using their Fork name so Cancun dot MD london.md and you were mentioning that it's a bit awkward to uh to navigate if you don't know the actual ordering of the fork so should we

just rename everything to use numbers so you know zero one that uh zero zero one you know Dash the first four zero two dash the second Fork that seems reasonable I guess you want to add more context around that

um well yeah it's a minor thing it's uh ee but it might be a slide to usability Improvement and I think with the SEO folks they are named alphabetically so with uh with those it's easier to navigate

Tim Beiko: cool oh three yeah there's yeah okay so I can make that change in this pack if there's no objection there concerns

um and

Tim Beiko: then last thing uh we had uh someone wanting to present eip7212 are you oh yes I hope I got your name yeah uh please yeah go ahead okay

Ulaş Erdoğan: uh I'm Lois I'm one of the authors of the ip7212 and I'm here to present the proposal to request some reviews and feedback from the core developer community The Proposal creates a new pre-compile contract similar to EC recovery which allows the signature verifications for sec p262 56 R1 elliptical which is one of the

most Mass adapted Curves in the internet ecosystem allowing an efficient use of this curving the evm provides utilization of the products using this curve in the application such as signature abstraction by secure elements of the mobile device and dynastic operation for web 2 domains in DNS Etc and I think that this is pre-compiled contract can onboard lots of new users and solutions which connect web 2 to web3 especially in the account abstraction wallets and we would love to hear any comments and recommendations for the EIP and I I also have a few questions and I will ask them them here

the the first is the EIP specifies the curve operation for the verification but it's a bit different from the common use case that we are familiar in ecl cover which is recovery my design Choice are coming from in the EC recovered the recovered address is the accounts public address so it makes sense but in the uh in the R1 curve it's not a meaningful data for the accounts and the products implementing this curve is not giving the signature values so it's not possible to make recovery directly without trying different values to recover

so my question is is it makes sense to keep verification process going as the verification so the implementation is also becoming more adapted in the applications or I had some feedback to change the proposal to recovery from the verification these are my questions and again I would love to hear any comments and recommendations

thank you um anyone have thoughts comments oh Daniel

Danno Ferrin: um so one Trend that's happening it's it's not ready yet is we're um the Epsilon team I'm watching them build this thing called evm Max which is a modular map extension to the EDM with the intent that a lot of these things that might be precomposed could be done in EDM for reasonable costs um is the R1 curve something that might be usable for that um because judging by some of the experiences I've had in the past couple of years with performance and um not just performance but Corner case issues with pre-compiles um they're they're kind of high risk to put in it seems simple but the corner case is an attack service they exposed

tend to be problematic and it'll be a lot better if we could you know I used to be in the camp that yeah let's do all these pre-compiled let's bring automobile lessons but now I'm more of the camp that we should try and do as much fine tuning as possible and with this evmx um be able to record the R1 curves I guess it's a big question

hey um I

Jared Wasinger: I can actually answer that because I did a bit of Investigation on um so the answer is yes um and based on the cost model that I had originally proposed in eip5843 it would cost around 70 000 gas to do uh like EC recover or uh yeah to do EC

recovery with SEC p with this curve so I mean yeah it's quite a bit more expensive than the pre-compile but it's um I think the best implementation we have in evm right now is around uh or I was told is around 600 000 gas so yeah I think something like evmx would bring us closer to pre-compile like costs but it's still um it's still quite a ways off uh but yeah I mean 70 000 gas versus I think what is it two thousand um

I don't I mean yeah perspective that's a lot less relevant than six hundred thousand versus seventy thousand right so right

Danno Ferrin: but then there's also some design issues like it doesn't have the recovery key and a lot of the signatures the initial signature said here's a public key here's a signature try and match it out which might result in you know one or two typically uh tests to see if it works um so it allows it would allow the end user to customize their use of the R1 is one advantage but I don't know if that'll overcome the 20x so that's good measure that you have the number that we know that is like 20x that's very useful

Jared Wasinger: yeah I mean it was it was a back of hand well it was it I you know I don't have the I don't have a benchmark

um but I think it's I think it should be around there at um conservatively I mean I think it could be potentially better but yeah thanks uh Ansgar yeah

Ansgar Dietrichs: um well on that point first I just wonder if you mentioned that I think even if we end up at a 60 70k gas cost Point that's not ideal just because if we expect that a big proportion of future the kind of abstraction contracts use this car then this would immediately still be the the dominant portion of the overall overhead of sending a

transaction which just not not ideal given that you would expect like high usage of this pre-compiled slash even Max but my my original comment was was going to be more more a bit more abstract so just to give context for people who haven't paid attention to the VIP yet um why it's an interesting earpiece that there's a lot of interests by layer 2's to also add this functionality so we're basically in in the process talking with layers who's it might be that they they are interested in adopting this Erp relatively soon whereas of course if this ever reaches main net it will take a little bit

um so it it might be just an interesting first candidate in in basically just seeing in the standardization process and kind of like there's the interacting between layers and layer twos and so basically us paying attention relatively early on in the process would still be valuable um just so that we don't end up with in in a world where we bring a version of this to layer twos and then six months later bring a slightly different version of this to to layer one so one super basically just mentioned that this is like the Erp here is in an interesting place

Mikhail Kalinin: thanks for the comments also I heard that the casing fell an artistic are implementing the pre-compile contract in

some way and also I have another recommendation that's implements this pre-compile as a progressive pre-compile idea which creates future pre-compiles as smart contracts implementing the same pre-compile interface in in a deterministic address in Every Chain by create two so that different chains can implement the EIP independently in the same address I think it's matched with unscar's comments and usable

Tim Beiko: okay does anyone else have thoughts comments on this

if not then yeah so there's a discussion link and I was shared in the chat here we can continue the conversation there and yeah it's definitely interesting to explore the angle of l2s potentially adopting this prior to L1 that was the last thing we had on the agenda anything else anyone wanted to share before we wrap up okay well thanks everyone and talk to you all soon and uh yeah have a good day

thanks everyone [Applause]

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