All Core Devs - Execution #167

Transcript

[Music] foreign [Applause]

thank you

Tim Beiko: okay

um hello everyone welcome to acde167 um so a couple uh Dent Coons spec updates slash clarifications uh today then um there are some questions around some engine API PRS for the devnet8 um and then uh we had two people with new VIPs they wanted to present and to wrap up uh Guillaume and Josh have uh a big vertical update um to share sort of what they've been doing uh over the past couple months um but yeah I guess to start uh there

were three uh PR comments for four seven eight eight um and I guess yeah Martin you put up uh the first so do you want to give some context on that this is PR 7431 I think as I wanted on the call

hello okay

Tim Beiko: yes yes we can

Martin Holst Swende: right uh so about 47.88 uh first of all I made a suggestion let me see if I have that PM somewhere

here uh just so I remember what what it was about

Tim Beiko: it's so the first one was like the history storage address right it has Mount zero so

Martin Holst Swende: first of all we discovered this problem um that due to the definition of empty uh the bigger root stateful pre-compiled storage was wiped at the end of every block because emptiness does not require an empty storage route the the definition of absence does not care about what the source looks like so uh that's kind of wonky

and I proposed one fix for that which would be to set the Norms if the nons when we set storage check the loans if the loans is zero then set it to one that's kind of a neat way to solve it uh yeah then why we were kind of investigating that um some other people got their eyes on 47.88 and there was the question raised that we should turn it into not being a pre-compiler at all is that something we want to discuss now or is it something we should

postpone to a later point

Danny Ryan: I think the question about the first the the conditional

Tim Beiko: yeah let's do the first yeah and then we can discuss the

pregabal

Danny Ryan: yeah is there should this actually be conditional and if so should there be tests where it's already non-zero before the fourth like it's nine

Martin Holst Swende: and so though it on mainnet we will only ever have it be zero once and then it will forever always after B one test Nets that people might spin up they can set it to whatever they want I I mean it's it wouldn't be

it's a very simple thing to get right yeah I just learned about it and if we get it wrong it might screw someone up on some very strange private Network

Danny Ryan: okay but there should be probably a test case where it's non-zero and stays

Martin Holst Swende: yes yes sure

Tim Beiko: um I do think yeah so the question of do we want to even make this apricot ballet is something we should discuss now because if we want to make this decision it feels already pretty late to make like a significant change so um yeah Martin do you want to share

Martin Holst Swende: yeah

give it give a little heads up for them uh perhaps uh publish on the caller someone else who um can give it their thoughts about why they don't want set for picking parts but first of all then uh I think the question was raised long time ago by exit at that point in time the Eep looked very different and then the Eep evolved and now we're at the point where the whole of the pre-compile could just be replaced with a regular contract and the only magic that will be needed from the like client consensus point of

view would be that we that the system makes a call to it that start the block processing the Eep already today contains pseudo code that says what the this pre-compile is supposed to do and now all of us client implementers have taken it and implemented that in our respective languages did it go and other people will implement it in other languages I noticed yesterday when I was comparing them that our implementation was not according to spec that would have been a consensus issue and we need to write tests about that

yada if we instead of taking the pseudo code and put it into solidity it wouldn't have mattered if for consensus from a consensus point of view it wouldn't have mattered if there was one such type of error because from from the client developer's point of view it would all have been an OPAC Black Box we would just call it once on the Block processing but it fixed amount of gas hope that it does its thing correctly and for consumers point of view that people who write contracts that actually want to use this Beacon route uh it does not matter much at all for them whether it's a pre-compile or

whether it's regular contract the tangible difference I guess is that if it's a pre-compile we we can decide arbitrarily that hey the gas should be 4200 or whatever if it's a contract it's going to be a you know a little little bit of change it's going to be a few more codes for the logic and it depends on a bit on you know how we how they so it's going to be a bit less around number but otherwise no difference I think that going with the regular contract increases the security I mean it decreases the complexity of implementation

so it lessens the risk of a consensus split and in a separate way I think decoupling pre-compiles from and not having stateful pre-compiles next easier for plug-in architectures such as Aragon and even one but I'm sure someone else can talk about that more than I can so that's it for me

Tim Beiko: got it thanks uh Lucas you have

here

so if I understood correctly that would be at the end of the block we will uh call uh this kind of special transaction that would update the contract

Martin Holst Swende: uh as the best parent is specified to do it in the beginning of his book okay from the beginning of his book we would call this special transaction that would update the contract yes

Danny Ryan: so it's more of a special call rather than a actual physical transaction in the block

right

Martin Holst Swende: uh yes I mean it's it's semantically it's a transaction

yeah it's a transaction so um yeah

Martin Holst Swende: but it doesn't it it doesn't admit any receipt yeah and things like that so it's just

okay

okay give me a second

wait

Martin Holst Swende: wait but that's already I just wanted to mention that's already part of the currency regardless of you know it becomes a free compiler because

not

uh and what about uh gas mattering of this transaction it's I guess

Martin Holst Swende: so I suggested when I just suggested like we could then change the that which would just set the gas to like 100 000. is not going to be near that because it's going to do proof to store it is

but this gas wouldn't be counted for bloggers in any way

Martin Holst Swende: uh no

okay

Martin Holst Swende: and that's the same I mean there's no difference between the current where they eat

works and the and then what I propose because this system call uh goes outside of a gas

okay so just just FYI this sounds very familiar to uh what Aura consensus introduced as system transactions this is basically the same thing

Martin Holst Swende: yeah

it's implemented currently in Never mind already gone and I know that giram is working on gas implementation of this thing to work similar to support this um make sense uh so we will be we have been using that for for years now so it's um so it makes sense from the the coupling perspective I totally agree

um it has its own drawbacks because now there's something like shadowy going on that updates the state but it's not visible but it's similar as it would be implemented in the code so generally I don't disagree makes makes some sense uh just a bit funny that we are uh reporting this potentially to the original ethereum

from myself I

Martin Holst Swende: I think actually it's not that funny I mean of course but I think the original uh source for this is Eep 210 which metallic proposed back in 2017 or 18.

this exact Mechanics for uh block hashes so is it before my time uh yeah makes sense and it's very easy to implement from our site so and some some clients have already similar mechanisms so it's doable fairly easy

well you have your hand up

Paweł Bylica: uh yes can you hear me

Tim Beiko: yes

Paweł Bylica: okay so like one comment like what was said uh about the like technicalities how the system covers the I think there's there's also like special address where the the call comes from so that's that's the way it will

to identify that the system is calling contract from inside the contract um I'm sure this this hour I think is similar but uh yeah it's interesting that it's kind of kind of converged the similar design um so like comment from my side as a kind of evm maintainer um it's also like simplifies stuff on on the testing and implementation because otherwise you need some special um data structure like like somehow to transfer this data uh what the what the pre-compile will be uh would would have to answer to users

so we need to have this data somewhere and um either you need to get it from some API or whatever right and the same for testing if you consider like we have a Json structured tests you need to extend this Json format to also somehow encode this data the pre-compile might be asked for if all goes to State and yeah if all of that goes to state by a regular call then there's not really neat to do anything uh and yeah the second second comment I will just repeat is that we kind of translated the pseudocode from the spec into evm bytecode

so I think that's that's much easier to consume by the implementers as well

Tim Beiko: when you say the pseudocode from the spec you mean the current spec

Paweł Bylica: yeah I mean like uh that would be kind of replaced with the like evm something I mean we need probably we need to use high level but in the end the bytecode only matters that has to be deployed and I think it will be even less complex than the current sudo code because sudoku for example has to handle like ndms and conversion between different like types and whatever and when you specified with the evm inputs

and EVN op codes it's already kind of

Tim Beiko: sorry what did you say Martin

Martin Holst Swende: yeah well all the so the pseudocode a lot of a lot of view into bigger and then conversion but when I moved it over to solidity all of that just fell away it was no need to worry about it it was a bit fun so so yeah they they like and the code it turned out in my eyes simpler than the pseudo

cup got it that Daddy

Danny Ryan: yeah I

think this is a very fine Direction I just want to understand at this point the process what the security and kind of overhead of the process would be right like do if this were written today we have byte code how do we get comfortable with the byte code we need to have a test Suite which runs independent of um say The Hive Etc and we probably want a handful of probably ebm experts to be doing review you know when we did something like this for the deposit contract we also formally verified the thing granted the deposit contract handles Capital whereas

this would not um so I don't know if that's uh requisite but you know the just the the process of doing this is not the process of doing Hive and tests and things so like we have to like Define what the process is uh and how long it's going to take and what the overhead

Alex Stokes: one thing on that is if we deploy it and it breaks we'd have to wait till the next hard work to redeploy something so it's not like there's zero cost

Danny Ryan: yeah so I mean since it's like instead of a consensus split you get a broken up code

Alex Stokes: sure yeah

Martin Holst Swende: you don't actually get a broken up code because there's no old code for

Danny Ryan: sorry you get a broken system facility that people use

Alex Stokes: like the future the future breaks yeah like people want the feature and so if we deploy something in the bike go to sports then it was a

future yes and that's the

Danny Ryan: that's the difference between you you're taking either consensus split or you're taking a potential broken thing

yeah

Martin Holst Swende: yeah and me as a clientele I know what I pick but sure I understand

Danny Ryan: arguably it should be easier to get it right once

Martin Holst Swende: yeah on or this is also a very actual simple contract it does not have a lot of state it does not have a lot of paths and as

you point out it does not handle a huge amount of money the way the deposit contract does yeah and we yeah yeah I don't know where to how we should but we should yeah what's what process we need to follow for this I'm open to suggestions

Tim Beiko: I guess Alex I know you've talked to a lot of the potential users of this do you think from their perspective it matters

Alex Stokes: no I mean I think some of them have started working against the current EIP but this is a pretty small change and like to be clear I think this makes a lot of sense so

right um well like the address the address would change but yeah otherwise it's pretty much the same um yeah and then yeah my bigger thing with this is just yeah like you know if we want to keep this in ineb then we need to figure out the testing security or less informal verification story ASAP

Danny Ryan: I guess fortunately we could get a byte code that works into test nuts very quickly but at the simultaneously we need to be doing kind of a rigorous testing and Analysis and review of that bike by code

so we're not we're not blocked on like switching to this very quickly but we simultaneously need to be the doing a verification of it

Martin Holst Swende: yeah and then so I mentioned this but I don't think I mention it here today but we what we could do then is we could deploy it could create two we could deploy it across all networks with the deploy it on Main Nets long before Cancun and anyone who wants to can audit it and test it and check it on mainnet and then what happens in Cancun is just that we start to we bless it we start invoking it by the system

one more comment on system transactions

from me that I remember when implementing them there all the gas related things like uh there are some gas checks the uh like subscribing the value for the gas for example or refunding it was a bit of the a bit problematic to implement it correctly that it wasn't that easy it's easy to make a consensus error implementing that

Danny Ryan: and something real quick on what you said Martin um I had assumed incorrectly that you just intended at the fork for a byte code that exists kind of written into the EIP

um to be deployed at a certain address oh you're saying instead to just manually deploy

Martin Holst Swende: uh yes and I'm saying that what happens in Cancun the fork is just that we start invoking an address and I hope that everything is in place and I mean we don't really care if there's anything there listening but we're doing both here

Danny Ryan: why not have the fork deploy the byte code and not have a manual dependency I mean I I guess obviously additional complexity but then you know that it's like self-contained and it works um independent of human activity

Martin Holst Swende: I just

um think it would be nice to to remove it from the e and not have it be part of the

you know consensus

Martin Holst Swende: yes

Danny Ryan: before X human must deploy with energy

Martin Holst Swende: if you're on a network and no one has deployed it uh then you won't have the feature if you decide to deploy it it will start functioning because the system will you know the next if you do deploy it on the system

then the system calls will start functioning

Danny Ryan: yeah I understand that I but some of the like you know what happens to the failed system call that isn't doing the right you know right so so I I might put someone must deploy before and then sidestep those questions

anyway you know it's

just um wondering because the only thing that would require me in general I think it's a good idea the only thing would run me a little bit is kind of potential uh concurrent delay so just be curious in my mind it's mostly

the system transaction not so much that the contract code itself because we could basically have Audits and everything running in parallel as long as they finish by the time of that folk they're basically good and but with the system call obviously another method something implemented that could probably be adapted more or less as is but it just maybe would be nice to get some sort of feeling for how confident the other clients would be that this would not add significant timeline delays um in in terms of testing or bad and everything um we just said that's like the one big unknown for me

remember

Tim Beiko: yeah I I agree is there yeah doing the client teams want to

share maybe like how they think this would affect their Cancun development

I talked a lot to someone else when I want to go but I guess just to confirm do you feel like forget this one's meaningfully changed uh like developments timelines

Martin Holst Swende: yes I do okay it will yeah it will remove some complexity to remove one of the Great compiles uh yeah I I don't think it's going to be a problem time wise to improve this

Tim Beiko: got it

um yeah

Martin Holst Swende: I think when we talked about this uh earlier we um we talked about this ahead of some of the certainly the head of the the contract option so it's not something we really have any consensus on right now uh personally I think that the you know sticking with the pre-compile option is is going to be better self-contained and easier to reason about in in terms of delivery but it's not a strongly held opinion

uh nethermine

so for us we can definitely deliver it there are some quotes around cast economics for this call and like AP 158 for the system address things like that that's other guys would have to accommodate too I think Aragon also implemented that already so they should be fine

Andrew Ashikhmin: yes we have an implementation for system transactions uh or a system transactions used for analysis chain uh so we we can implement this one especially I think the the bulk of the

work will be in formalizing system transactions and ideally we should get it this like there should be no discrepancy between um ethereum mainnet and Analysis Channel like horror stuff that would be perfect

Tim Beiko: okay and so it seems like Danny and Alex would rather have the deploy of the contract part of the EIP they sort of keep it all self-contained so part of the hard Fork activation um if we went that route

does that significantly like make things more complex because then the hard Forks logic needs to include the contract deployment

Danny Ryan: I also just worried in testing like in Hive and in test Nets and stuff it

Tim Beiko: right

Danny Ryan: so we yeah for example even if we're doing like deneb and post dencoon test nuts in the future like now we have to figure out is that byte code deployed at Genesis who's deploying like it just it seems to bring like a whole thing to have to think about in any test net in the future

Martin Holst Swende: so there's still it adds one quote though and it's the same Quirk as with this nons thing and that's

why I maneuvered around that by doing it the check every time uh however so if we do the quote is if we configure that Cancun happens at zero block zero uh and there is nothing there into Genesis then we create block one so it's just do it then deploy the thing before processing yeah it becomes a bit of we need to do it correctly when we when we do the deploy it's it's block zero

Danny Ryan: right but if it's if it's part of the

EIP investigation it can be you know at Fork block which is block zero at before you're doing anything you essentially deploy by code and then it's self-contained and we never have to think about it you know once you get the logic right once

Martin Holst Swende: yeah and what if there's code there

Danny Ryan: well you put it at an address that is essentially reserved like a pre-compile but it doesn't have to be a freaking file address it could be any address

Parithosh Jayanthi: will we be able to use the same logic by using for the deposit contract on test Nets we currently just hard code what the storage encode needs to be at an address we decide and this is in the Genesis Json

yeah

Danny Ryan: yeah so you would have if we don't if we do the manual kind of thing then it looks it's going to look like the deposit contract and it's just going to be something that needs to be baked into tools rather than something that's baked into consensus logic

Parithosh Jayanthi: got it at least from a testing perspective this is super easy because we've basically set it up says that everything inherits Genesis from this one tool I know Hive is different and antithesis is different but yeah I I'd let Mario speak for hire of course but for testnets it should be a super easy change

Mario Vega: yeah I guess I guess if if they decline somehow makes it um so that the code appears

automatically at the allocation before starting tests that would be very helpful for testing because otherwise we have to we have to hard code it into every single test somehow before starting and I mean and and I mean for this the main issue would be the ethereum tests and type of testing where we do some pre-allocation so we have to be yeah pretty hardcode um uh the the code before each test but if the client itself does it at the hard work and the code appears where it has to be that will be very helpful in indeed

for testing

Danny Ryan: also and yeah also Apollo's point that kind of if if we deploy to the same address everywhere it it has a certain implication on tooling if it's deployed ad hoc depending on network then it has a different application on tooling like you kind of have to like the tools that want to use this the libraries that want to use this um have to be configured per Network um whereas the other they're just kind of configured singularly

I

Martin Holst Swende: I can go with either um I don't really have strong opinions about this

Tim Beiko: so I guess there's anyone still feel

strongly in favor of the pre-compiler it seems like we've like slowly shifted to how we do the normal contract rather than like defending the pre-compile um but is there anyone that thinks that we should stick with the pre compile I don't base you mentioned they have like a weak preference but aside from

from base two

Lightclient: did we agree on how to trigger the

Danny Ryan: from the system standpoint

Lightclient: yeah like does this account against block gas does this is this a transaction does it come from something instead of a Terran transaction hash

Martin Holst Swende: it

comes from a special system matters it does not count towards the block gas and it there it does not emit any receipt I think that's

Lightclient: and so is that is that call have it um that function have a conditional like assert must be from system address and then otherwise it fails or is it

Martin Holst Swende: so in the implementation that I wrote yes and there I wrote two well in digital system Addison psychopath and one which actually uses poor bytes it's easier nicer for addressing you know better ux Weedle this side I guess in the coming days and what which one we prefer okay thanks for posting it just yeah

and

Tim Beiko: so yeah in terms of getting to like a final decision on this um it seems like there's it's probably worth like discussing offline a bit to like work through the details of um the spec but at the same time it'd be nice to not cause huge delays um over this like do we think it's realistic to get to the call the CL call I guess do you think it's realistic to either have a decision and people agree

like by Monday on the testing call or the CL call next week I think if if we need longer than like a week to agree on um it's probably a sign that it's yeah it's too long okay Alex says decide by Monday does anyone think that's unrealistic that by one day we can't have a and so oh yeah please

Danny Ryan: I was gonna say if if we wanted to move on a definite without four seven eight eight which is not the current discussion um we need to think about how that impacts the consensus layer or tests and

release and stuff so I prefer to try to just get it sorted

Tim Beiko: okay and so the things we need to figure out by Monday are one do we put this as part of the hard Fork flow or do we have a manual deploy and two what contract we want at the very least to start with this is a bit more of a reversible decision but it would be good to align on yeah the deployment flow and the deployment flow our preferred contract and I guess to also have at least the pr to the EIP with the proposed changes

Danny Ryan: yep yeah

Tim Beiko: okay and what's the is there a channel that should we just use like awkward devs or interrupt to discuss this just so everyone sort of goes to the same spot I don't think we had the channel quite for this EIP

here

Alex Stokes: we've been talking and testing there's uh okay evm testing let's see sorry execution layer testing

Tim Beiko: okay so that's yeah let's keep using that then um so uh the testing Channel yeah we have many testing channels but okay so under the execution layer category the testing

Channel okay yeah

Alex Stokes: so maybe we can summarize a bit

Tim Beiko: yeah

Alex Stokes: uh so we're gonna need the nonst thing no matter what right so we can go ahead and merge that EIP

merge

Tim Beiko: so this is Martin Source PR right it's the one that

Alex Stokes: oh sorry

Martin Holst Swende: exactly it becomes moot

Alex Stokes: well you could still deploy this in some way could like delete it right

Martin Holst Swende: right but then then as if if there's non-enthy code it's not considered empty right yeah

Parithosh Jayanthi: for devnet devnet 8 do we want because we like do we want to start with that net eight with the current version with the pre-compile or do we want to wait until the the new csis

address is called beanie

Alex Stokes: yeah I think we would try to

weigh it

Alex Stokes: so yeah I mean unless someone else wants to I can make it pass and update in the AP like today and or tomorrow so I think by Monday it'll like at least look clear what to do and then separately there's you know the testing log in front but I think we can have the actual functionality pretty quickly but I just want to understand what we're all agreeing to so if we're sure about the code thing then we don't need 7431 um and then yeah I can update the IP with this my good approach

Martin Holst Swende: sounds good I can work with you on that

Alex Stokes: very great and one other thing uh there was another PR through the CIP to handle the Genesis case which I think most people saw but I just wanted to call it out oh yeah yeah the one that Tim put in chat and then otherwise I think that's it unfortunately

Tim Beiko: and then yeah it so for devnet eight uh it seems like we also agreed to wait until these changes are done to deploy the devnet um rather than deploy with the current

version and like change it um does that make sense to everyone okay anything else on 4788

um next up uh so there were last call we discussed the uh exception slash edge cases to the self-destruct EIP and so after checking with the l2s there's no L2 that breaks uh based on

the change so I believe optimism is the only one that uses the burn but they call it inside of a contract creation transaction so um they're they're like unaffected it still works under the the New Logic yeah and Dana was there more that you wanted to hot to to cover beside this

Danno Ferrin: no I just want to do last call if anybody knows of any other change that we need to look at I looked at the ones off of l2b um like you said optimism is the only one that uses the burn the other ones either just use exactly what's in or they blow up on um they don't Implement self-destruct or they

revert on self-destruct uh polygon zkm changed it to send all but that brings them out of evm compliance so I'm not too terribly worried about accommodating them based on the spec because they're already moved off the spec

s

Tim Beiko: any other thoughts comments on this okay so yeah so we we go I guess we can merge your clarifications uh to the EIP battle yeah anything

else on self-destruct

Danno Ferrin: I think that's it

Tim Beiko: cool okay yeah and Mario says that all the tests are implemented uh with the clarifications from that PR already okay anything else on the eips themselves for dencoon um otherwise there's some engine API stuff but on the eip's themselves any other comments thoughts concerns

um so uh Andrew there were three engine API PRS that you mentioned um were not merged and we were not sure

if we wanted them in devnet 8 or not um so uh they're in the agenda but the first one is adding blood gas used and block gas price that it receives for 444 transactions um second one is 426 which uh clarifies the Cancun payload Delaney and then the third is just a rename of data gas The Blob gas they're currently all listed in the spec but they're not merged I guess given especially we have this extra delay or a short delay um due to the pre-compile change does anyone see a reason to like exclude

any of those three from the devnet because it would potentially um delay things or or introduce Logics that we don't want to test quite yet if not then I think we should okay so we should keep them on and I don't know if there's any specific blocker to merging any of them um it looks like there's been some approval on the first there's

some discussion on this second and the third looks approved uh as well so yeah maybe if by Monday we can try to have a look at those get um get them mostly merged and uh if there's any discussion left on either of those three PRS we can discuss it on the testing call Monday does that make sense

Andrew Ashikhmin: uh I think I just maybe um if you have time we can discuss the the second one uh I think it makes sense and I think we discussed it uh a few times but I don't remember whether there is still opposition to it or not we can postpone

it but if we can agree now to merge it that would be great I mean two to four four to six yeah like to my mind it makes sense

Tim Beiko: yeah it doesn't seem like there's any opposition on the pr yeah the only one that still seems to have discussion is like their receipts PR um but the two other ones seem yeah the two other ones we should just merge um on the receipts yeah on the receipts there was like a

comment by Peter that's just I guess uh made obsolete by the the previous uh naming change but is there any other reason not to merge that or do people feel like we need more discussion okay it's already implemented in Basu okay so yeah let's let's merge let's merge uh let's merge the the last two for sure um and then yeah it seems like there's support for the first one as well but if maybe if like some of the

implementers Just Wanna give it a thumbs up we can we can get it merged as well so all through emerged by

one day

Andrew Ashikhmin: yeah I think all three make sense

Tim Beiko: cool um and then Mara says Hive can be updated uh to reflect the changes from 426 uh today awesome anything else then on uh devnet 8 or engine API uh specs

Gajinder Singh: I think there is one small change that we still need to do uh regarding for

Choice update uh basically we in the uh Indian API specs we haven't clearly mentioned that Cancun or words you should only call for Choice update 3 I mean on new payload V3 we already made it made a one-to-one correspondence of uh of these versions with regard to uh with regard to the hard folks but I think we haven't specified on fork2s update so I think that we should also get in and close it out

Tim Beiko: so the and there's no PR for this yet correct

Andrew Ashikhmin: but isn't it covered by uh four to six I

think it also has this um it says that ah no it has a fork Choice

updated with two

Tim Beiko: sorry so does this used to

Andrew Ashikhmin: do we need to use a focus updated V2 or with three for Cancun V3 only I mean we decided that Cancun hours will make sure that uh the hard fork and the versions will match because it makes for an easy validation uh on the inside

and I think there is we haven't really update we updated for new payload V3 but we didn't basically update the same for folk Choice V3 and there is no EIP ad but I can drop in something I mean it should be pretty easy to drop in right right so it should be do I going to do it on top of like on top of four to six or as part or it will are going to update for four to six uh I think we can update photos Explorations

Tim Beiko: okay cool okay so then let's merge the receipts PR and the

renaming uh basically as soon as we can and we can make that change in 426 to uh require the call to V3 does that make sense to people okay anything else on anything else on the test net or uh or sorry yeah devnet 8th or uh then VIPs or specs in general

Parithosh Jayanthi: oh yeah Mario so yeah I just wanted to comment that we have um The Hive branch that is ready to

test all the changes up to now before deep recompile um changes that we're going to make this weekend but if clients want to test uh I share the branch in the interrupt Channel and you should be able to run the execution clients with this and that's up to up to this point in time um yeah if you have any questions or help me into wrong do you have uh tested just let me know

Tim Beiko: um moving on uh so Perry you wanted to share some updates uh based on the large validator test that's uh that you that you ran

Parithosh Jayanthi: um so over the last couple of days we've been running uh some big validator tests so we've been attempting to have a test net up with 2.1 million validators and roughly 420 nodes uh we tried once with machines that we're using on other test Nets so those were four core 16 gig machines and that hit memory and CPU limits almost immediately um and in order to save some time we went really Overkill so we went to 16 core 32 gig machines and we've done a split such uh such that each node has roughly 5000 keys um and we're mostly mirroring what you see on mainnet so prism Lighthouse get

another mind account for roughly 1 million value data so about half slightly over half and you can have a look at some initial Impressions here uh the last one had a Regenesis about uh an hour ago and West we're still not able to finalize we're still noticing issues with uh late blocks or with um duties not being performed in time and we definitely appreciate help in triaging um everything and the whole purpose of this is we want to be able to launch the host key test net which would be roughly one and a

half million validators but we don't know if the current Paradigm supports such a large Network so we wanted to go with a 2.1 million validator testnet and see if we can if we need to make emergency changes or not

garlic

Tim Beiko: thank you um any comments thoughts bye client teams or others

we can touch on again

Barnabas Busa: this will not be online for a week by the way uh we don't plan to run this for

a very long time because they're quite expensive to us so you'd like to get as many people as well on them as soon as possible

Danny Ryan: yeah I don't mean to delay consideration but even if the test that's down this is a conversation we'll continue next week

Tim Beiko: um next up uh so there were two eips that people wanted to briefly present uh today so uh the first one was from uh 5806 I don't know if you are on the call

Hadrien Croubois: uh yes hello

Tim Beiko: oh hey

Hadrien Croubois: yes so uh yeah do you want me to present it or

Tim Beiko: I guess do you want to give maybe if you want to give like a minute or two background yeah on it and uh if there's any questions that you'd like answered uh yeah this is a good time

Hadrien Croubois: so all of you know that account abstraction is a is a big topic right now and and this PR is not really about the contextraction so this EIP is not really a company but it falls into the same scope of thinking of what EOS will become and what accounts per user will become and my intuition and what I

understand from from all of the discussion I've seen particular in HTC is that aoas are here to stay because you will still need them to start transaction an operation like that and currently EOS are very limited in what they can do because they can basically just send transactions there are any transaction types you can produce blobs that kind of things but it's it's pretty limited and and there are a lot of ideas of what humans will becomes I think they will stay here in the network and I think it's interesting to provide them with more capability uh while not starting to build something too complex and too difficult and there is already a behavior that I think is really interesting it's a delegate called

Behavior Uh and and just this proposal is about yeah let's just allow EOS that are just icons they don't have code but there are accounts like smart contracts to do a delegate for and that opens a lot of possibilities while we're using mechanisms that are already present in the AVM that are already pretty well understood so the possibilities include being able to do multiple to batch operations that that would be headphone 45 it's also Hallows a new way to to execute I create to by calling by delegate called a contract that that does create tools uh and it will also allow eoi to to emit events uh which might be useful for for

for social operations like like advertising data under your accounts that can be easily recovered by by Observers

done it

Tim Beiko: um yeah does anyone have any comments questions thoughts about this uh okay let's start with

Guillaume Ballet: uh uh yeah quick question because you say there would be two calls from eoa and I get the I get the point would it be possible to get it uh to send it from yeah no actually it's a system idea but

from a non-eoa account or at least to transfer it to a non-ua account and what I'm thinking here is could we somehow hijack this system to recover some funds that were locked in the contract that would be that was locked basically there was uh that was destroyed or incapacitated in in some for some reason

Hadrien Croubois: so to emit such a transaction you you would need the the private key that when hashed correspond to this address so if it's a contract that was deployed using Create or create two that that would not

be possible also there are current proposals that I think are going to be discussed later in this call about being able to create code uh in place of a new way to do a migration to account abstraction those transactions would not be able to happen because you cannot since there is there is an EIP somewhere in remember the name that enforces that you cannot emit a transaction if there is code at the address so that's I mean the current ecosystem means that this could only be done for addresses that don't have code and that never had food basically

Guillaume Ballet: yeah uh now I understand that I'm just wondering if it would be possible to somehow extend it this way but yeah I

don't see it working either so okay never mind thanks

Tim Beiko: uh Ansgar

Ansgar Dietrichs: yeah I just wanted to say that um my just initial impression would be that while I'm generally sympathetic with the idea uh trying to make EOS more powerful uh it seems like in the past when this came up like for example um it's one of the people who fought for Erp 3074 quite a while two years ago on this call um without success and I think generally the the skepticism was that executing um code

basically that that allows things like multiple multiple transactions from from one account within one transactions just is a pretty high security risk because then one one single transaction can empty out all the accounts and whatnot um so I think is the all the reasons that made us not go with 3074 also apply here unfortunately also specifically I think in the context of delegate calls from a new a there were some additional concerns around just executing code in the context of an account basically what the implications are for storage usage and all these kind of things so it seems like this would basically be a more contentious version of 3074.

yeah for these reasons also specifically because there are now some other proposals to completely migrate away from EOS even um even at basically from the from the requirement of using them for entry points of transactions it seems like this is probably not the way to go but I I could be convinced with basically but but I feel like this is not as simple of a using existing logic of the ebm as it was presented so I think it would be pretty pretty uh extensive change and with a lot of implications and would require a lot of basically justification

Hadrien Croubois: yeah if I can just say two things here uh one is about yes sir we are preparing for pass to towards migration I still believe that the migration while it's

very useful has also some downside like you are committing to a specific code that you cannot change later some people I believe will stay with uas so I think it's still valuable to accommodate that and about 30 74 is a very big difference here and what makes this less powerful but also I believe more secure than 3074 is here all the replay protection and the signature is built into the transaction by itself it's not an independent system if you sign a transaction like this it's only good for one transaction it's not something that is going to be used in the future if you sign that insert t74 there was a risk that you should sign for a contract that is malicious or buggy it could exploit you here like we're using the replay

protection correct currently built in the system it it's safer now for sure if someone signed a transaction like this that is malicious they can do a lot but but so is true of any other like more normal kind of transactions like if you have the private you have controller versus the

icons that's basically it uh battle

Danno Ferrin: so this is a bit more of a meta commentary about 5806 and 7377 and it seems like we're trying to get into accidental design of a good account

abstraction system um and before we do that I think we need to pause and consider is this really the best way to get the account abstraction system that ethereum needs I mean these are you know interesting solutions they open up interesting design space um but I think we should step back and think if we served better by deliberate design towards account abstraction so that's that's my concern with these going forward is we might be left with some some albatrosses when we go to real account attraction system these also might be the right Solutions I mean I don't know that's just my concern

here

Hadrien Croubois: here one point I made in the document that maybe I haven't made very

clear in this colleague I don't think this is a solution track on abstraction I think it's just providing useful mechanism for eoa and this is definitely not an alternative to the other account abstraction proposals

Danno Ferrin: there is that it could cause design constraints on the other proposals if they now have to account for delegate calls and doas and eoas having storage now um maybe it's the right solution maybe that's what they need at the end I don't know but I think we should make sure that we we put the big rocks in first before we fill in small rocks

Tim Beiko: um Martin

Martin Holst Swende: um yeah just something that Oscar and now also kind of mentioned I think this should be raised on the in the security considerations on this e the fact that a user might invoke some some mod to think or whatever contract it stores some things in into the storage area or the eua and then later on the user unwittingly might invoke some other delegate call thing which also interacts with the with the storage area on the eoa and users can you know invoke things in strange orders and be towards the slots May interfere in ways that are not intended

the same problem would exist in contracts except that contracts are usually written more I mean not as haphazards as the way end users do things so I think that's just we raises a point on the security security considerations that's just my feedback

Hadrien Croubois: yes I completely agree with that

Tim Beiko: okay thank you um so there's uh the each magician threat I think we can continue the conversation there um and then the Discord uh yeah just to be mindful of time um I have to move on to the next one uh

thanks uh for coming and presenting uh presenting this

Hadrien Croubois: all right thank you thank you for having me

of course um and next up I believe like client uh had an EAP as well but you wanted to discussed yeah I

Lightclient: I wanted to introduce the EAP 7377 which was kind of mentioned uh briefly in the yeah discussion with the last one but I wanted to explain the functionality very simply what it allows is it allows for an externally owned account to submit a transaction which creates a one-time code deployment to their account and the specifics are you know something

that we can debate on The Magician's floor maybe on Discord there's some ideas here that I think are kind of interesting like instead of deploying code and running a knit code we actually uh have the user submit a address which the code will be copied from I'm taking advantage of the fact that we usually store only the code hash as an associate in association with the account these are just things to try and make it as cheap as possible for users to migrate their eoa to a Smart contract wallet and I wanted to mention that I think there's a lot of demand for things in the protocol layer to improve ux I mean here we're talking about two different ux Improvement proposals and over the last couple years ERC 4337

has taken a lot of growth and seen a lot of deployments on many chains outside of just ethereum L1 and this EIP is something that I think really helps 4337 and any other kind of account abstraction proposals that uh that we might have whether it's in protocol or you know some sort of application level one because a drawback for users is if they want to use an account of abstraction uh mechanism whether it's in protocol or out of protocol they have to deploy a new smart contract wallet and move all their assets over so this EAP is really trying to address that issue by making it simple for users to just start using smart contract wallets by submitting a

single transaction upgrading their existing address to the smart contract world yep that's the general proposal happy to answer any questions hear any feedback thanks

Tim Beiko: thank you any thoughts questions comments okay oh yeah okay please

Yoav Weiss: I just wanted to edit that indeed we are seeing a lot of a lot of demand this is one of the one of the most commonly asked question with the 43 7 users and there was quite

a big ecosystem for 437 at this point so uh it's very often people ask about migrating an existing account so I'm not very opinionated on how we should do the migration but we should have we should have some form of migration so my main uh the main thing I think about is whether the right way to do it is a through a transaction type of an OP code but either way it's um either way it would be good to have uh to have a migration path

Martin Holst Swende: yeah yeah I just can I just mention quick because I read through this Heap a

couple of days ago and and I had to get the clarification from like on this specific point so after this migration there is code on the account and the transaction which where the sender has code is an invalid transaction so I just wanted to point that out but after you do this upgrade there can never be a transaction from that account again unless self-destruct still exist and in self-destructs I guess

Yoav Weiss: yeah that is actually that's actually a feature not a bug I think because if you migrated your account one of the primary use cases for account obstruction is

that you can rotate the keys so if you change the key of the account you don't want it to ever transact again with the old ecdsa key

Martin Holst Swende: yeah I just wanted to lift it up so

yes yeah yeah you're 100 right

Tim Beiko: Ansgar

Ansgar Dietrichs: yeah if you wanted to say that I think um maybe similar to the comment of the last eib that I think the direction is a fruitful one because simulator we should probably migrate or completely overturned a world but I think the CIP is mostly used for as like a concrete proposal so we can start

debating this and not something that we would just do in the very short term because it has very far-reaching implications so basically this is more of a set an ambitious goal and then start debating with how we how we get there kind of kind of thing let's schedule this for the next time in my opinion

Tim Beiko: yeah I think with that uh we're probably good to wrap this up for now unless there's any final urgent comments on either of the VIPs okay uh then last up we have Guillaume and Josh to give an update on uh the

work that's been done on

vertical trees blue

let me share my screen let me know if anyone cannot see my screen

Tim Beiko: I can see and hear you

okay perfect um cool thank you so uh in the interest of time I will go through some portions of this fairly quickly so we can get to what we believe to be the meat of it

here uh most of this presentation will be kept fairly high level but please feel free to flag anything of course that you would want to see more of a deep dive on and we would also love to encourage anyone to join the discussion on uh upcoming vertical implementers calls where we can dive deeper and we can also of course uh future acds as well so quick overview or quick agenda uh in the past five or six months we have hit a number of big Milestones that we are excited about so we will give an overview of that but of course there are a number of Milestones remaining and we would love

to bring more people in who would like to contribute to any of these remaining milestones uh which brings us to questions answered and questions remaining there are these are questions or general areas we think we have solved or have a very clear path to solving in the near future uh as well as questions still remaining and will require a bit more exploration the overlay method uh although most of this will be high level we will do a very quick mini Deep dive into the overlay method uh goal is to bring people up to speed here quickly the design and implementation of the

migration has perhaps unsurprisingly Downstream effects and will impact some of our remaining open questions here and then finally next steps how we will begin to answer some of these uh yet to be answered questions hopefully by uh getting more people into the discussions as well very quickly quick reminder on why we are doing all this in the first place won't spend much time here I think most people on this call are likely familiar with this but state is growing this growth is unbounded permanent even today you likely need a two terabyte SSD to

run a node but in a future where we have stateless it is possible that this could be something like one uh one gigabyte or less and making it easy for anyone anyone to run a full node is a very good thing so the key to unlocking stateless is small proofs which just happens to be something that vertical gives us so with vertical thanks to the much smaller proof size no extra state is needed to validate a block you can do it with what the block gives you also a

note here we are going for a week statelessness which means block Builders will still need to store the full state we can share more at a later date um or if we have time on why we believe that to be the best path or you can read a write-up that dankara has created here that I've linked to my notes so uh diving into where we have actually uh done over the past six months as I mentioned it's quite a lot a number a a number of notable Milestones have been hit on the performance front thanks to Ignacio and others the overhead of verkle is is much

lower current benchmarks at 20 percent compared to uh Merkel when we've replaying blocks uh the overlay method so this again is the solution for the Merkel 2 vertical migration we have gotten to us a place on the trade-off where there are no longer trade-offs like two exiting designs disk space which is a huge win and we have again validated the initial strategy and uh created a working proof of concept multiple clients have made great progress likewise on the snap sync front lastly we are currently targeting our

first Shadow fork for later this month client updates if you'd like to see a full list please visit verkle dot info also as a quick side note vertical.info is a resource where we point people to who are looking to get up to speed on vertical in general find the latest documentation and just see the current status of things but on the client updates front again just a very quick sampling here nethermind and ethereum JS both making progress on stateless which is exciting Basu has a small group working on making

sure that virkle will play nice with bonsai and Lighthouse and Lighthouse is deployed to mainnet and lodestar will soon be joining okay so with that I will hand it over to

Eugene

Guillaume Ballet: um I need you to try to unshare your screen so that I can share mine um but yeah I'm so we we noticed that there was a a lot of misunderstanding about our current state uh like this current state of uh development of Virgo

and usually uh it comes with uh not being aware what uh what the current state of the transition proposal is uh so I'm going to present uh like some slides actually presented at HCC I will in the interest of keeping it short I will go uh over it fairly shortly I'm going to select the right window there's too many of them um let's see can you can can you see my

like yep

Tim Beiko: yes

Guillaume Ballet: okay excellent uh so um yeah so if if something is not uh clear

um just uh I'll direct you to this uh to this talk I did that at CC otherwise uh feel free to to ping me um so yeah so the principle is uh is pretty simple the idea is that just before the at the end of uh like at the last block before the fork uh we have the MPT and uh we have uh all the internal nodes that are represented by uh by those things in red all the square the blue squares are uh the the values that were written to the state before the fork and we have this green arrow that represents an iterator that is going to sweep over the state

over um over a series of blocks so when um you you at the beginning of the first block of the of the fork you start with an empty vertical tree that is really that is a written right that is writable and the mpg like I said becomes read-only and so as you execute the block uh values get written too so they are represented by a purple Square which means personal squares are values that get written to the state after uh the fork so here uh first value got got written into the the tree and at the end of the block

a number of values so in this case two get moved from the well actually don't get moved um they get copied from the Merkel tree to the vertical tree and so if you want to if you're looking for data that is currently represented by a pink square and that data is currently not present in the Virgo tree but it is present in the MPT you first go to the to the vertical tree and if you don't find the value there you go search it through the through the miracle tree so that's basically the the principle each block more values get copied into the vocal tree some values that were

there before get overwritten and when the lpt the last block with the MPT gets finalized you can delete all the internal nodes so you already free up some space and as things continue once the the whole state has been converted you can delete the MPT because all the values that were present then have either been overwritten or have been uh just copied um so just to finish on this uh on this story uh the reason why uh we we're trying to to get people to to look at this a bit closer is because time is

of the essence uh if we decide to convert 1 000 leaves at uh per block at a rate at like and assuming that the the payload the total amount of data that needs to to be transferred is one billion leaves it will take six months so one billion leaves to be clear is an estimate of what uh the size of the tree will be in uh in a year um if it's ten thousand leaves it's 15 days so of course those numbers are uh an estimate of if we we perform this fork in the next year if we do it later it will be more so even with 10K with 10 000 leaves it can be uh more than 15

days um so yeah just to be clear we have answered some questions or at least we're pretty close to uh like we have we have definitely answered uh the design where sometimes finalizing the the what was it called the the like the details but most of it is clear uh we have good performance we understand how we're going to migrate we have I mean we nethermine has a prototype of snap sync with Rocco uh now the question is how do we distribute the pre-images because we need to rehash the whole tree which is where the uh the problem lies um we still have some questions about the gas schedule

how to update it during the transition and uh yes basically we need a lot of testing RPC or or not um so yeah what we're going to work on in the next uh in the next month is basically the shadow Fork validating the snap sync relaunching a test net and hopefully we can get more clients to to join us in that effort um so there's a there's a call the vertical implementary call and the channel vertical try migration that you can join the next vertical implementer is called if I'm not mistaken is next Tuesday

and so two hours before a CD like the time at which ACD starts I think um and uh so if you want to be invited let us know let Josh know um and otherwise yes we are always interested in the deploying more application more contracts to the to the test net to stress it out and there's also currently the the two big discussions are how how we are going to distribute the primages and uh the the gas cost uh during the transition and yeah that's I think that was the last slide yep so that's that's pretty much it

thank you uh Andrew

have you heard that and then Daniel has a question in the chat as well

Andrew Ashikhmin: uh yeah so for pre-images we can just introduce uh a new methods to the east protocol or like a new a new protocol and Aragon can serve them because as you know Aragon knows are all full archive notes and we have all the pre-images

Jim Joshy thoughts sir

Guillaume Ballet: sure uh yeah I was just thinking of something smart to

say after that but uh yeah we we'd love we'd love to basically that's uh um yeah if uh if we can experiment uh with Eric and distributing the primages like create uh create a protocol that would be that would be a great start a great starting point

Andrew Ashikhmin: uh right yeah so I think um we will try to find out a developer but you say it makes our job easy if somebody like just maybe pens uh the the protocol like something like like an extra um capability like like Snap is it or whatever but it's a it's a minor Point yeah we can do it

Guillaume Ballet: yeah so I think that would be uh that would be the topic of conversation on the next uh Vic and then we can we can do exactly that

um Dano

Tim Beiko: has a question what will state proof look like uh during the overlay period vertical only and all reads get moved over or is it rights only improves

possible um so like while the changes in in

progress State boost would still be large so it wouldn't make sense to introduce them

Danno Ferrin: well there already exists and need to get proof that will return a large proof from the Merkle tree um how would that transition I guess is my question would there just be nobody can do proofs until the transition's over I don't think that's a good solution

Dankrad Feist: I thought you may you meant block Witnesses by that okay sorry

Guillaume Ballet: so yeah the I mean my understanding so far was that there would be no proof uh we definitely know MPG proof um oh well okay except you would have to just uh I mean you could still get the MPT proof it's just that the MPT doesn't

get inserted anymore so they would be a bit less value in this um we could just provide proofs for the for the vertical tree itself during the transition

Dankrad Feist: I mean I think like it depends how on like how much this is used at the moment but there are definitely ways to have stay proof during that time so basically the complete State proof would be um a worker proof um and if it does not exist in the vocal tree then you would provide a proof for the MPT at the same place

Danno Ferrin: so I don't think we can design in this car but that seems like something needs to be discussed in the tooling

discussions and roll out

but

Dankrad Feist: I'm simply saying it's it's possible to do it

Tim Beiko: any other questions comments uh there's a question here about the Json RPC from Mario in the chat

Guillaume Ballet: uh I'm having some issues with the chat so if you could

Tim Beiko: uh should we introduce eth get vertical proof that returns

empty until the tree node makes it into the vertical tree

Guillaume Ballet: um we could do this for sure uh the question is is it going to be useful but uh yeah that would be possible to do that

Tim Beiko: any final questions oh how is the chapel rebase coming

here

Guillaume Ballet: it's painful um I just created a PR today

um but yeah I need some input from from Gary because we have this new uh this new uh like storage system or database system in guests that I need to integrate with so yeah I would say it's go it's it's happening

Tim Beiko: nice okay any final questions before we wrap up sweet well thank you everyone um talk to you all on the

Tasmanian CL calls next week thank you thank you

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