All Core Devs - Execution #192

Transcript

[Music] you oh

for e

e e uh I think I can give a quick update

from the def Ops Team uh yeah over the last week we focused on local testing with the ctoas package and we are still waiting for the remaining client images to get ready uh we found several small issues with various clients but most of these issues are already fixed by now and we also have received images um for pectra definit one from all clients now um but we are still facing problems with two of them specifically uh prism is splitting out with some pairs at slot 32 and Aragon is splitting out with the first block with uh deposit requests um so yeah um unfortunately we

also reached a limit with uh local testing because we can't spin up all the client PRS anymore locally so yeah next stop is probably definit one and our account plan is to launch defit one next Thursday with all clients pars if they're ready by then so yeah that's all from us from now awesome thanks okay sorry uh yes the sound for YouTube was muted um okay so tldr uh we've received all of the client pairs um for all the image for all the clients for deth one uh some issues with prism and Aragon and we're hoping to launch this uh next Thursday with all client

um any of the specific teams want to share an update okay um and then I guess uh in that case yeah if we launch deth one next week um we can see how things go and um if things go very smoothly and we don't find more issues then we can put us back together for defit 2 uh next week um but yeah it seems like we're in a good spot for deth one any concerns other comments okay

um in that case uh is Marius on the call yes okay Mars do you want to give a quick summary of your eof blog post and we'll start things from there sure um so I've said in the past multiple times that I not a big fan of EF um and I decided to write my thoughts down why it shouldn't uh be uh imp Petra and uh so I did that in the post um basically my argument boils down to it's an extremely complex change um

and the benefits are small um in my opinion or not enough to um to uh to uh to justify such a large change um and especially because we can never get rid of the Legacy evm uh we will all always have that and now we need to uh maintain two versions of the EV evm in perpetuity um at least two versions uh with every

larger um update of EF we might add some new version of EF um that we need to be uh uh maintain in parallel um and yeah that those was kind of my thoughts um feels like a bunch of people are sharing my thought uh sharing my general feeling um but also a lot have uh come up against it um at this point um I'm kind of tired of arguing to be honest um I've I've uh said my griev

grievances multiple times and it seems like um people still believe this is a worthwhile change um that is worth taking the risk um I don't believe so but uh I would like to make it very clear um that I'm not for this change I think it's risky and I think the risks out outweigh the benefits and if we decide to do it um then I will don't want to be held responsible for anything that basically this is my

pos position I would still keep working on it if we decide to do do it I will provide the code uh for GU um but I don't want to be involved in any anything if anything breaks or if uh if minute goes to then I'm I have a clear questions thank you also there's a really funny threat uh on ACD if you want to read up on all of the discussions that we had thanks and off like that um yeah I appreciate you putting the blog post together and out there and sharing your perspective uh even though uh yeah

clearly um there's you know High disagreements around it um I think yeah we should encourage people sharing their views uh especially when uh yeah it evolves as you've like spend time working on eof itself um yes so there was many many messages exchange about this on uh the R&D Discord um I guess one thing that came up a lot was around just like the support for eof would like solidity and other teams you know actually support this um does it benefit them it seems like it it clearly does but we do have Danielle on the call from the solidity side so do you maybe want to take a

minute or two to talk about um yeah how solidity thinks about this change why eof makes things better for for you all I know know you posted a few message about this already but just so everyone here has the context yeah of course uh yeah I mean we've always been strongly in favor of EF the previous version that was supposed to be going to shangad already and the current version uh definitely also uh there is a few aspects that were raised in the blog post and in the Channel that I would like to get into that claim that there would be alternatives to solve the technical Problems by UF which I would try to debunk I mean we have swapn and DN which significantly simplifies our compiler

infrastructure which and we have been trying to get into uh Legacy AVM for for years the IP number is 663 uh but yeah it can't be done without immediate uh arguments which rely on uh on eof there have been a lot of arguments about that for years Deno made the point in the in the chat and I think would be happy to elaborate if any questions about that the other thing is getting rid of jump test analysis and bending relative jumps that's also not possible without EF we have function calls that have return locations which are inherently Dynamic people build jump tables and whatnot I mean all these things rely on uh on a construct like UF I mean even if it

was theoretically possible to build all that that would be a series of hacky changes which would never get the support to actually become uh be done in uh in in Mainline uh evm so EF is the proper solutions for these issues so I would say EF is in that sense for us and the spe below us the superior design by orders of magnitude that's not only compiler infrastructure that we get simpler but also verification and auditing uh bite code analysis uh all that becomes simpler with ef uh there's the other arum quick question like when you're saying all of this becomes simpler will you not support the normal uh Legacy version of the evm or

will you move the whole compiler to the new version or will you just need to uh maintain two versions in solidity as well we will uh move do you have by default because it's Superior in all metrics uh once it's available uh I imagine that we will need to maintain uh the Legacy compiler version for sometime until uh the community has caught up with the change but long term I would prefer to only uh support an EF back end and there is no incentive once EF is live to produce more uh Legacy contracts because yeah the metrics are superior in all aspects

really so Els will need to follow EF at this point uh yes I would I mean that that's also a interesting question about l2s in general I would say I mean uh there is this idea that UF could just be done on l2s but uh there is no evidence for l2s actually going Beyond main compatibility that's the first and foremost goal of of layer twos at this moment which is understandable because we are not the only things that you need to actually use an ecosystem that works on layer 2os there is an entire stack below us that also needs to have that support uh so

youf not only has in general invaluable properties for L1 in gas cost simplification of B Cod analys and whatnot but l2s actually can uh if you want to have more development of l2s uh actually putting l uh EF on L1 makes things simpler because you can use EF contracts and transpile them to new kind of uh execution engine I mean Alex made the point for uh CK implementations earlier I mean all that becomes simpler once EF is on Mainline uh on on Main on on L1 so actually I would even argue the opposite that if you want to have uh Layer Two in uh Innovation and want to facilitate that putting EF on layer one

is probably the missing link that actually makes it possible to import the entire ecosystem to you Layer Two while still innovating on it without losing the entire infrastructure that's built L1 okay thank you um Peter you had your hand up as well yes so um I think Daniel mentioned um a few things that basically U simplifies that we don't need jump Des analysis that we don't need a lot of stuff and um or gas introspection or code

introspection and all in all I think the world that e kind of brings is a better one so completely agree there and my only concern is that when we're talking about how much how many things we won't need after eof I think that's kind of a false fallacy argument because as long as we don't have a way of deprecating Legacy evm stuff I mean we will still have to support basically everything apart beside UF and U and basically there's been um some arguments that um that even though I mean yes eof can be better in a

number of aspects I kind of agree but um basically it will we will just end up with having two independent EVMS having to basically having to maintain them and um and plus we will need all of a sudden care about the interplay of those two EVMS and every argument which says that well we can solve this or that or whatever thorny issue that um might crop up in the evm is not really true the moment we allow evm and Legacy evm sorry eof and Legacy evm Co to cross goal each other because you can just uh so for example re removing the gas introspection in eof is completely pointless if I can just call a contract

in Legacy evm and that one just has access to it and um I don't know so personally I kind of I would say that EF is probably a good idea but I don't know I personally would feel a lot better if there was a way to transition out of the Legacy evm so that we should either stop supporting it or we should somehow prevent people from running basically if we would have any sort of mechanism to transition everything towards eof even if it's midterm so not immediately I think it would make the case for eof a lot better because

nobody's arguing that eof is on its own the merits aren't worth it just the problem is that we're we're just creating a very very large risk surface that we will have to maintain thank you um onar yeah I just wanted to say because I I definitely agree that on mainnet with kind of the situation that we have so many Legacy contracts already and we'll have to support both of these versions forever that the kind of the benefit cost trade-off is a little unclear for you app but I I I definitely think like Bally that's why I think really at the core of this issue is the question of the relationship between L1 and L2 and I

really think that we have quite the responsibility here to acknowledge that at least for now L1 still very much sets the defaults for L2 right in terms of client but also in terms of solidity all the tooling everything and just if we don't support something on mainnet for now for the next few years at least it will just not reach ler twos it just won't and we can always say well it should but it just won't so hope we can work on changing that and hopefully in three two three four years lus will be in a position that they can ship things independently but so our decision here would be to say well we are kind of delaying progress on layer 2 EVMS where it would clearly be a beneficial impact for a few more years and I think this will not only come up

in this context but for example in the future with account obstruction and things like that it will be the exact same question same with with with where if you have a chain that already has a lot of U EAS and then you move them over to Smart accounts basically now you also have this extra complexity to manage both of them and it's much messier than new chains but basically we just have to that we have responsibility for the overall e evm ecosystem um so I would still very much be in favor of bringing youf to one thank you just to interject I kind of agree with asgar on that um L1 basically says the stage for L2 so uh if you want EF on

l2s you need to get it into L1 so that's kind of clear whether that would be whether that would be an ideal in an Ideal World or not that's kind of un irrelevant it's kind of the reality we're in and I think this is at least true like for now you could imagine a world where you know four or five years from now like the second e V2 or whatever is something that l2s can ship on their own but I agree that today we're at the level where they can ship their own pre-compiled basically and maybe coordinate on like a standard address for of them um and so yeah there's clearly a few years to um standardize things a bit more um

Danel so one of the questions that was posed was what's the plan to get rid of Legacy e of ebm and I think we totally should do that and it would start with just Banning new deployments at one point and then once we have that we can get a better hands around um what uh bad behaviors that we're Banning an eof then we would then need to figure out uh basically s some contracts that we could do compiles or whatever or we could just freeze them in place and just support them um with with another one of the problems yeah um sorry for that Biden moment uh but one of the one of the problems is that eof has got the mandate to ban certain um certain things that that Legacy eof has deployed today and we have to support So

no matter what that ban looks like we're going to have to support that for existing contract um even if we expire contracts is all expiration proposals had Resurrection involved in in those expirations um so if a behavior is out there we have to support it we can ban new prop new new uh new deployments of those but we can um manage them so that they're they're limited set we know what those issues are kind of like you know um the empty account in account number three so right and I think yeah obviously step one towards Banning Legacy deployments is having an alternative on Main net um and then if you just think in terms of

like our Fork Cadence it's like okay if we ship eof at this Fork um you know I don't know that like next Fork Banning uh Legacy deployments is like quick enough or long enough so it's like you probably wait another 3 years or something before you ban these deploys um and then the time that it takes to to um to to figure out the backwards compa is probably another year or two so realistically we're saying you know maybe in five years we could do this transition um not that this is this isn't like a good or possible thing but it's also something where most of the people on this call you know for the foreseeable future should assume that

we're going to have to maintain both um yeah uh Peter yeah I don't really think that's um realistic honestly so if you're going to ship EF now and you expect to maybe potentially uh address Legacy evm stuff in five years well in five years time either if ethereum dies a horrible death due to the chain split or if nothing bad happens then basically everybody will say well okay screw that it kind of works don't touch it right and so I guess that's my point is I think it's maybe I think deploying evf sorry eof with the premise that we can then migrate from

the Legacy evm feels wrong um I think what ongar said that like L1 might just have to accept more messiness um because of its like higher historical uh State um is is like what we should accept as a status quo and then maybe we come up with a solution for legacy contracts but uh um I would almost treat that as like a bonus in a way and not like our base case going into this um yeah um um another thing I want to address is the notion that we're maintaining two separate EVMS we aren't if you look at the code of all the clients um it's all the same one Loop we are adding a new

container parsing functionality that is new and only supported by E by eof but when it splits it out and we have the containers in the code the loop runs through the same set of operations we just have more operations that are contact dependent whether the current stack frame is eof or not certain operations will be valid and C certain operations won't be but the memory model is the same the transient memory model is the same the storage model is the same um the PC model is the same the stack limits are the same a lot of the stuff between the two EVMS is absolutely the same to the point that it even uses the same Loop got it think yes but it's 19 new off codes and in the past we've shift maybe like two op codes per per hard F

and even then we had issues with uh with consensus splits EF has already had three consensus issues introduced not in the eoff code but in the Legacy code um and I don't know it's it's just a risk that you guys apparently are willing to take I'm not comfortable with that risk of introducing so many op codes so many gas computation uh the the um code verification the St verification these are incredibly complex changes in a very important part of of ethereum and um I don't see it being tested super

well there's been good tests but it's like the risk is in my opinion extremely high it turn tested super well when there's only two complete implementations just in the past week we've finally been getting more complete implementations of clients now we can do the real testing now that there's implementation out thanks and I think maybe on that one thing that would be valuable is to think uh even though we don't have the full test coverage uh today and you know we depend on implementations for that is think about what does our ideal test coverage look like so um you know if we can sort of come up with our what like

our bar for feeling comfortable with this is ahead of time um that might be a good a good way to like yeah not um yeah not have to like make a decision in like a very local way where we just look at what exists today and and and keep asking yourself is this good enough or not but like um yeah what would we want to see um like I assume we'd want to fuz this extensively I assume we want want to you know we have already a lot of of static tests but are there some test Suites that we think are missing that we think we we should have um and maybe this is a better discussion for the eof call than than this one but um yeah I think defining that like bar ahead of

time can be useful to yeah and by no means we're not done writing tests we're like maybe halfway through the test cycle maybe so to judge this the quantity of the test by being halfway done I think is a bit unfair right um let's do G and then we'll do Andrew and Lucas uh yeah yeah just uh Point uh when danu says uh we don't have to touch the state that's true maybe today I'm not I'm not even sure you to ask Marius uh but it's definitely not true in the future so not that it's a showstopper in itself but I want to remind everybody

that this claim is not uh going to last very long like to hold true for very long um Andrew um yeah I think I agree with marus that it is a very big and complicated change but uh but I think we have time uh in pectra to actually concentrate on it and push for it and ex extend the test and make it work like the merge was also complicated but uh we managed to pull it off uh and uh uh yeah I'm sure that if we spend enough brain cycles and effort we uh pull uh yourf off as well uh and uh I think U because

if we don't do it it basically um we freeze the progress on evm development and uh I kind of uh to my mind e EF presents a coherent uh Improvement to the evm and it opens up further potential improvements like evm Max uh and if we don't ship it in in in pectra then um a lot of like like people will we've been uh postponing it for so long and um basically a lot of people will give up and will they they will give give up on evm Ma and other EV improvements and

it it will be a bad outcome for ethereum and blockchain in general thanks uh Lucas so well I'll agree that the changes are very complex uh they need to be complex because we don't want to ship this in in parts or even can't in some in some places we don't want to create even more future fragmentation so if we want to ship some impr big improvements to evm we want to ship them as one so we cannot kind of uh do it in any other way than having a big complex uh change uh if you wanton ship it now we probably won't ship it for

years so uh that's another concern in terms of testing I totally agree that uh it's not yet tested but I'm also a bit optimistic in terms of that we found for example in never mind multiple issues based on the current testing setup already so the test are doing a pretty decent job of of showing those we probably have more that haven't been yet uncovered between the clients um in terms of benchmarking and dos we had never minder planning to do uh dos benchmarking for all the new up codes and see how what uh kind of megag per second throughput we can get and we

have a we have a tool that we can do this cross cross client so compare all the clients and the last thing I wanted to say I asked that few times but didn't on the chat in the discussion but I did didn't find an answer is uh fuzzing I I'm I would love to have very extensive fuzzing between clients on this but uh to have the the fuzzing working well we have to have multiple implementations we which we are just having uh so um before someone answers me that how is the fuzzing going and the how's the fuzzing state my opinion is that we should continue as is uh and just

revisit it later if we if we find it uh if we still will be finding U not we will be not convinced we will be not confident in this in E we might want to remove it but it's a bit premature in terms of testing it's still in progress like it's it's half done uh the most and that's fine that we are uh that we are doing it at the moment and I don't see a problem with that yet my my question would be are we going to delay the fork if we decide or if we find more issues with ef well it depends when we get there in

my opinion right if when we find issues will address them and if uh if we would have drastically delayed the fork maybe we'll remove it from the fork and move it to a second one I don't know we'll see it's like we speculating right at the moment so yeah I'd agree with this that it's a bit hard to make a call about like the relative Readiness of things especially with something like pias on the CL as well and a lot of other big changes so um yeah I I would keep the conversation around like is this valuable at all and rather then um yeah is this the right

time or if we find a bug at this time you know do we do we remove it or not um yeah um do uh dragon uh yeah I see two arguments against against UF one is it's too complex that argument can be mitigated by making new tests um basically the current test suit is not enough but the argument is we are basically making new ones and adding it and improving it second argument against EF is it deduce complexity that's maybe needed not needed for

L1 and against that argument I I I'm if a wants to improve itself to improve l2s change needs to come from L1 on complexity of the changes uh what I want to say is uh EF introduces adds and extends uh op code sets that already present it's not introducing new complex logic to the Legacy bite code it introduces new validation that's outside of the bite code so complexity it's not that tied and overlap with the Legacy

bite code so even if we have uh two versions of UF uh two versions of the B code inside the evm it there are not going to be a lot Divergence between those and just to mention again we all we are adding new OP codes and we have good framework for testing your evm so we can reuse those that's it for me thank you um yes please there are a bunch of bite codes that are different so for example X call X delegate call uh x uh the other call there is there is uh

I mentioned those there is sorry those have like they almost do the same thing but they they uh change in the way the the gas is uh is calculated uh they change in the arguments they have all of these subtle changes that it's it's a new up code it's not it's not just take call and and modify it slightly it's you have a new call up code um basically so yes there are some there are most of the op codes most of the 80 op codes are the same um but uh there are 20 new OP codes 19

sorry for example in RBM implementation I'm using the same framewor for the calls the change is that the gas is changed and how gas gas not gas B Gas limit is changed how gas limit is calculated there is additional code that's duplicated but it uses the same framework as the ordinary calls additionally uh interaction between Legacy and the eof is between how the external code is fetched and additionally there is change how the UF gets created with create create intersection those like intera in uh basically the points where the Legacy

and you have cross pads there're not a lot of those okay let's do G yeah um I actually just wanted to ask a practical question although I would like to note that I can see another issue with eof it's the lack of future proofiness and I would like to know if uh when Daniel says it's going to make things simpler for ZK oh was I was was UN muted the whole time sorry no no no you you were fine you we lost you for like half a second but okay um yeah so I would be

interested in finding if you have references about this that uh UF indeed makes it easier for ZK stuff but okay my my question was actually um when eof launches will we already have uh compiler support or not or do we still have to wait a bit longer for for that we will have compiler support and just quickly the point about uh uh CK is also in general the point is that uh EF code can be transpiled to a new execution engine be that an ck1 or an improved uh non CK execution engine and whatnot that's possible by the design of eof that's a nightmare or impossible for legacy

evm thanks um Andrew um yeah uh I'd like to note that um I don't want to delay pectra but maybe delaying pectra is not a bad thing because um from the um a panel on account abstraction it looks like the design of 7702 is not settled yet and um people need more time to figure out um the the proper design a good design for 7702 that's it thanks uh like yeah I feel like the conversation is very focused on

the practicalities of shipping eof but I don't think that's like the right direction for the conversation or at least the conversation that we should be having and you know eof is useful like I don't think that we're generally arguing that there is not usefulness in the things that e provides and I think in general we can ship eof given enough time and resources so I'm not there are questions about like how long will that take and you know we've been talking a lot about that and like will we be able to get the testing done in that amount of time and you know if we spend a couple years on eof like I think we can ship it but we're not asking the question as much like should we be making changes to the evm should

we be making this big of changes to the evm why are we actively making L1 more complicated for a proposal that you know clearly is not necessary to the survival of ethereum uh and I would rather as focus at L1 on doing things that is necessary to the survival of ethereum looking at an inclusion list reducing the size of L1 clients making it easier for people to run L1 clients um we are as a core Dev group have sort of said that we want to focus on being a settlement layer and allowing l2s to take the Baton on developing the execution layer for

ethereum yet we are trying to like centrally plan the future for them and I don't think that that's our place I don't think that that is useful for the future for ethereum thanks um Dano thinks it's actually necessary so I don't know if you want to maybe expand on that yeah um I think it's you know it's not a two-year threat like inclusion list some those things might be a two-year threat I think it's more of a 5 to 10 year threat for E theum if we don't improve the basee case of the evm because I very reasonably see a future where if we don't improve the evm and

there's other alternative VMS out there I won't name them on this call there's some really good ones out there that the recommendations from Smart Contracting aits are going to be use a modern VM and if l2s use those modern VMS we're draining a mo that keeps ethereum being ethereum these are evm chains we're talking about and if the recommendation is don't use the evm chain then we're draining them out so I think it's a 5 year to 10 year threat I don't think it's a not a threat it's not a next year threat but it's it's it's something that we need to keep in mind as we go forward building ethereum I really don't like that framing that we're we're forcing the entire Community to use this new VM just so that ethereum can retain use users

and keep aot and keep a strangle hold on the innovation of execution that's that's not that's not what we're trying to build here like we're trying to build an open platform for people to experiment and to build different virtual machines and if a good virtual machine comes that doesn't start with E then we should be very supportive of it and that still exists in the world but the default of l2s is to just Fork an L1 client and work from there so we're not foreclosing these other VMS they're building they're going to be out there but the evm is the Last Choice it's you going to be then why use evm as a main layer um we need to make make it better for l2s and l1s to align and if they if they're not aligned that's the 5 to 10

year threat we're using it on the main layer because it is what is on the main layer no one here is going to say that this is a great VM the best VM ever built you know it's just what we have and we should try to make some incremental improvements to it but we shouldn't ever like go back and say this is the version of the evm like we're past that point now it's time to let the l2s make the second version of the evm or whatever other VM they want to make and I I don't get the argument of saying l2s will move to these other EVMS or these other VMS and we can stop them by making EF on on Main net because if

they see a benefit in moving to move or moving to whatever stylus or or whatever then they will move there and no amount of EF will ever um uh make them make make them reconsider and um if eof is like this great improvement over the evm then there should be no argument for l2s to adopt uh e what we're doing is were bringing the evm up the standards established in years like 1941 and 1996 with some of the container structures and static

jumps I mean we're not no one's getting a PhD off of eof we're just applying stuff that is known to be good and that is if we don't have that good base it's it's about remaining competitive the base has clearly gotten us to be one of the biggest blockchains in the world one of the most successful development blockchains in the world so I don't think that we need to go back and like rebuild the base from first principles I I don't know if I agree with that I think maybe there is a case to be made to rebuild the the main blockchain from first principles but is is that what we is e what we would end

up with is this the best version of the EV or a virtual machine um or or is something that is really not evm doesn't look like evm at all um uh something better for for L1 um G did you have your hand for another comment or did you uh yeah I just had two questions but um it's okay can wait if uh okay debate let's do ongard and then Dragon but I guess my sense at this point is the get team is still opposed for a bunch of

different reasons and other teams still see all in favor so I my sense is at this point we would keep it in and obviously focused on testing um and and whatnot um but that's if I yeah if I may descent we actually started the the conversation by saying we will let it uh we're not going to try to block it we're just not going to support it like we usually do with the rest of the forks what does that mean meaning uh other people will have to do some testing as well s can't find it yeah and if soilon and I myself have been writing most of

the test for eof we're already there and if it blows up on Main I will not send up on a Saturday at 2 am and and try to fix it I think this this is like the decision that I'm going to take um if I if it ever happens might not happen it might everything go perfect but if it happens then I will not be there to I'm sorry okay okay and yeah I think there is uh uh like the capacity from other teams to

help with the testing and shipping this um so yeah um I think my sense is we we would keep it in the fork for now um and obviously like with any change we'll revaluate we re-evaluate as we get farther down the testing stack you know like is this too complex do we think that there's you know uh far like too great a risk of bugs and consensus issue um but given that we don't have like full finished implementations yet we haven't started fuzzing um there's still a lot of stattic tests that need to be written um it seems like there's still a lot of work to do to even get it to to a spot where we can have like this final call around security um and other client

teams are in um other client teams seem to be willing to take on that work yeah that I think yeah that's my read so far um we can close with the Gom Greg and Matt and if anyone has any final comments on it we please uh yeah raise your hand so that we can uh yeah have them all on the screen but otherwise I think we can we can move on to the rest of the agenda um yeah yeah so I'll I'll try to be quick but I had a question about the conversion like deprecating Legacy in the in the future uh what if we had some kind of uh I'm just uh

basically throwing mud at the wall here but if we had some way to deactivate all the introspection uh instructions before we actually deprecate um our Legacy code would that be an interesting uh medium step let's say I'm just curious I would like to ask the EF people and the compiler people there's a whole category of contracts data contracts that would break so we need to put in special handling for that they start with code 00 and they just put data on there because the gas schedule currently encourages it that's going to change with vertical but the data is out there and they still want to access it so even if we deprecate it we need to have

facilities for them to access some of these things that you know they've been building their nfts off of um so we would definitely need to audit it and make sure that we know what we're getting into and that is you know the first step is to um ban Legacy deployments and then we can analyze what the close set of what the real issues are and what we really need to fix rather than having all possible trolly issues come out when they find a new way to cause problems with the solutions we proposed okay thanks um Greg um yeah I just wanted to go into one paragraph of marius's uh critique um which is static program analysis and

he points out correctly um that as long as we have non-static jumps the analysis of a program is in the worst case order N squared eof removes Dynamic jumps which reduces the analysis to order n in the worst case and over and over people seem not to get how very important this is Marius goes on I'm not convinced that the difference is significant um someone not being convinced doesn't mean that it's not significant the people who care about this are totally blocked the difference between linear time and quadratic time is the

difference between being able to do something and something being impossible in particular this is so important what do what do what what do you want to do Greg I want for 9 years to get rid of static jumps and introduce a sub routine instruction and um this I believe is pretty much our last opportunity to do it it's bigger and more complicated than we'd like because we haven't been able to do it incrementally over the last nine years but it is good enough we can't just keep trying to get it perfect

it's good enough and if we don't solve the problem we simply create a dead end um for all kinds of research and improvements um involving this it's very diffuse you asked on another Channel I'm not hearing people complaining about this no they've gone away they have work to do pushing on the core devs to make their life easier is a waste of time they have they have to improve the speed of their code now they have to validate that their customers code is correct now um we can help them hugely um the ZK people some of them are going to heroics

using GPO gpus in parallel because their proof size is blowing up quadratically when they hit these jumps um this is a small kernel that's very important to get in if eof fails I'll happily write a proposal that puts in again just those two instructions and a validation routine um but I'd rather see all all of the O go in because there's so much work and support and so much good that can come out of it um that I I understand that you I understand that you want to get this in my question is why what is the use case that you're trying to make

that you need to get rid of the the the dynamic jumps for I've been trying to explain this for nine years lots of people have been explaining it for nine years I I don't even know how to answer a question that's I I don't know where to start then yeah sorry we're we're already pretty deep into this um I think let's and you know it seems like we're just going to keep working on it for now so um yeah Matt you had your hand up as well yeah I'll make it super quick um we keep talking about in many instances trying to push this Innovation to layer twos but in in very real circumstances

they're ryant on the L1 clients for you know most of their infrastructure and operations so it's it's not ites it's not worth understating the fact that you know if we ship it into the clients themselves and use the kind of L1 mechanism to get that forward and push all of this stuff then it opens the door to this type of innovation on layer 2 with the evbm specifically I think this is what Dan was discussing when he talked about the moat that we would have uh and you know there's proposals for basically being able to extend the capabilities of the eof container and The Virgins um so I think that you know it's it can't be understated that right now the developer push on Layer Two is you know broad compatibility so that people can deploy their uh daps across all of these chains uh and making sure

that we can meet people where they are now is I think valuable as opposed to saying let's kind of Punt this Innovation and see what shakes out because you know I I think that would kind of remove the reality of the situation that we have now with the with both clients and layer 2's kind of marketing and positioning with developers so at least that's my that's my take here um one one last quick thing what is what is stopping us from merging it into the client and not activating it on mainnet then the l2s can take the code and and run it and do whatever they want with it and I I don't get this argument that we need to do the work for the for

the l2s and we already did the work for the l2s they literally just need to take our code and run it I don't know I it's it's fine we've we've had this conversation it's it's still in it's it's going into Petra um I'm I I don't think we should uh we should we should should have any more discussions on thanks yeah I think this is a good spot to move on and especially given there's no l2s on this call speculating about why they won't uh support it uh probably isn't super productive um but yes the recap uh we keep it in uh we keep it in Petra I think gu has been

pretty clear that even though they won't you know like opposed change uh even though they disagree with it that uh the amount of test and uh security work that they usually perform should be performed by others who uh effectively want to Champion the U and this has already started um this has already started happening but we should uh basically double down on that um and then as always uh you know if we get to the point where we're close to shipping the fork and we feel uncomfortable with the safety of eof we keep finding bugs that we don't think um you know we're going to fix in then we should reconsider having it in the fork um yeah we should continue working on it testing it and um

yes as soon as we have multiple final implementations start fuzzing them against each other to find other bug does that make sense to people okay um thanks everyone and appreciate people being uh civil uh in this discussion on the call I know that a lot of people have very strong opinions about this um yeah and so moving on to something else where people have very strong opinions um account constraction um so there was I believe a Meetup around 7702 uh near Etc um a proposal came out of this um to add the code reset

functionality um and then there was a response posted on the agenda sort of opposing um opposing this I've posted both of these links in the chat I don't know if any of the supporters uh of code reset um is on the call and wants to give a a quick overview hi I um can you hear me yes yeah so um I'm I wrote some of the proposal uh in the doc and I can give a brief overview of uh like the overall discussion and what was proposed um so hi I'm from Frontier I do research over there and uh to give some context uh the proposal is uh with respect to some of

the concerns few teams have about the latest version of 7702 which makes um like the smart contract code persistent um so before before this latest version of 7702 or before even the 7702 there are generally two types of accounts in ethereum eoa or smart contract accounts uh we we believe that this uh the current proposal basically adds a new type of account where in eoa you have a private key which can which can issue transactions in a smart contract account you have code on chain which basically needs to run and validate before things you can do things with that account uh with the 7702 spec you have a new type of account

which has code uh but it also has the eoa private key which is basically the super user of the account so so it introduces this new type of account you had EAS you had smart cont contract accounts but you have this new smart contract account with eoa as the super user eoa private key as a super user and it makes U there are two issues with that firstly because this is a new type of account there are some uh ways in which you can Doss the network layer U and I'm sure like there are proposals to mitigate that but uh one of the proposal that we one of the suggestions that we make also uh uh reduces that network network Le do

and then secondly because you have uh the eoa private key which can behave as a super user you can bypass all the constraints that you have put in place on your smart contract account uh people also call these policies uh and just and just move users assets using the eoa private key and so this makes some of the use cases U un viable so to give an example uh if you have a multisig now your now now the security of your assets is still dependent on the obsc of your private key and not on the obsc of these multi or if you have something uh some some type of resource lock mechanism

which will be beneficial for uh instantaneous multi-chain transactions the user can bypass these resource locks because because they have they have the way to unilaterally move assets and so the proposer what is the proposal proposal are basically three things uh each a little bit independent with each other but they try to solve these issues the first one is um there's this line uh in the current 7702 spec which basically says that uh we should remove uh basically EOS should be able to generate transactions using the private fees if you remove that and that is a very simple change you would remove this new type of account you would also uh resolve the network layer dos because

the network layer understands how to interpret transactions coming from eoas or smart contract accounts and so the propos overall The Proposal is instead of creating this new account you should only have these two type of accounts which the network layer can understand and give the give the users or the wallets the functionality to cleanly switch from one one type of account to another um and so proposal number one is removing uh EA's ability to initiate transactions on its own the second one is uh if you want to switch from the smart contract account back to the eoa you should have some way to uh Delete the code and that's what that's what uh we call us code reset and

then the third one is uh it's not dependent on the first two but basically right now you don't have a way to automically initiate the storage in the smart contract account when you do 7702 and that's the option call data so those are the three different proposals each trying to tackle different things um and so that that's the that's the overall proposal spe thank you and I believe uh yeah there was a response to it um I don't know if the authors of that are on this call um if not uh yeah Ansgar uh you also have some concerns GM oh okay julan and then we'll

do yeah yeah yeah I won't I won't spend too much time um and you know thanks onit for the for the um you know for the proposal and and and everything I you know I I thought I would provide a a small analysis from the other side trying to you know I think balance both I guess technical stewardship but also like the end users and the and the actual like account holders and what they actually like want um at the network where um and I guess like since anid did as well um you know I'm the the the CEO of Tim Labs we spent the greater of the past nine months uh thinking really deeply about like what H how do we get to the this next future of like spart accounts and you know um you know

broadly speaking we spent a lot of time implementing 3074 on the contract at client level obviously you know moved on to 7 C02 spent a lot of time you know thinking deeply about that and you know have been basically been there um end to end for for the process and seen um The Proposal you know the proposal grow uh I won't dive too deeply into it our Doc is obviously like posted like in the chat um and and obviously there's there's clearly a couple things here um that are extremely important like what number one is like obviously ephemeral delegation the the concern for like Bas which which obviously I need to do some more reading on my end to to better understand um and then also like just

like the greater high level of like what this like prop propal is bring bringing to the current um to the current like spec State um you know we're we're firm Believers that actually you know given this new proposal you know actually being able to take the step back and think back to the original proposal or the current proposal that Matt that Matt wrote you know it's it's I think more in favor of like uh you know open Innovation um obviously it's not going to push back like 772 which obviously we would you know absolutely hate um and you know not introducing like additional additional things like this would be technically a new OP code I

understand it's a it's a variant of of um of self-destruct um but but understand that you know the current version of 72 doesn't actually touch or edit the behavior of the VM rather it's something like more um something that doesn't involve actually like uh inter acting with it we propos we propos a a potential like alternative if people want to act like if if femal delegations must like proposing a flag to add um to add two delegations in the authorization list that would designate this particular thing as ephemeral and then clearing the code hash um you know at

the end of the execution you know we've been writing a bunch of experimental contracts on on some 7702 implementations and been thinking about like yeah what are other ways that we could do this without touching the VM Etc um there's other things about like shared storage we've obviously read the names space the namespace pr which has obviously gotten some push back as well um and and yeah I'll kind of stop there I try to keep it as high level as possible but feel free to take a look at the the dock and I'm happy to you answer answer any additional questions in the chat thank you um ancar yeah I just I just wanted to say that um

I also wrote it down in chat that I think I personally don't like this this new uh idea with with quote reset um primarily because it basically goes 90% of the way to a permanent upgrade but then stops you know 90% of the way um which I think is a really weird spot to stop because it still has this now the special type of contract that in principle at some point in the future can return back to becoming in UA which just makes it so much harder to reason about um you also might have the false sense of security that you can actually do this with your account but then it turns out maybe there's some bug in the implementation and actually the code path you relied upon for getting there doesn't actually work and so you are stuck after all so it basically creates

this false sense of extra security over a permanent upgrade that really isn't there it's basically the same security guarantees as as a permanent upgrade um so then I think if we want this if we like this then we should just commit and making it a permanent upgrade and the alternative should be that so basically just just for people that maybe haven't followed this you know because I feel like we have been we on level 20 five of the of the discussion now so basically you know if if you stop paying attention a couple weeks ago initially it was that the the um swapping in the code was only done within the scope of a single transaction and at the end of the transaction basically you you're back to an UA and then we changed that specifically because it is kind of nice to actually have the legation targets

stored in your account but my proposal would be instead of just because we're storing it it doesn't mean it has to be active all the time I I think storing it was an improvement but basically now we decided now as long as it's stored it also has to be active I think we should store it but then still only flag on individual transaction scope whether that it should be active and by default it should still be an EA while it's sitting there I think that would be a much cleaner version that basically is closer to the original idea in terms of what we should do next steps I just want to say I think clearly that we keep having these discussions means that we we don't we're not close to superfinal spec yet um so we should keep having breakouts I don't think ACD is

necessarily the right forum for this um in the meantime I actually think the current the merged version that is the kind of the the change from mat from a couple weeks ago that that basically did add this onchain storing of the delegation Target I think that's a very reasonable Target for testing um because I think any changes we will make from here on out will be relatively small so my proposal would be we just stick with that version for now we keep with dep Nets targeting that version and in the meantime with breakouts we we try to get to final spec and only once we have an actual final spec do we then move to that for testing thank you I agree that um yeah there's a lot of like context in

these conversations and we may not be able to resolve everything here um and uh yeah before like accepting the change in um yeah we we should have teams like be much more uh confident in in the actual proposals anit yeah I agree um U this was this uh I just made this proposal to get basically get feedback on where everyone's head is at uh uh I yeah I agree this is this proposal is not to hey let's change the 77 and2 spec right now but I also wanted to highlight some of the things that some of the

smart contract wallets care about which is if you give the user the ability to bypass the onchain policies that they have encoded then it uh basically uh makes the current migration path less secure and also it removes some of the use cases uh like instantaneous Cain transactions unfeasible for these type of accounts and so I wanted to highlight that I'm happy a lot of people who were in the whiteboarding session and there are list of names over there as well who have reviewed the doc are happy to basically come to another breakout session where we can have a video call to basically update the spec or or propose

changes um whatever what I want to say yeah I guess yeah this is a question do we think that we can resolve this async in the next couple weeks or do we feel like we need to have a breakout to discuss this more thoroughly um uh Pedro yeah I mean like I oh sorry let's do like Cent and we'll do Pedro yeah in the chat and on Discord this is something that just reopens the concerns we had around eoa migration specifically like how do you deal with the fact that a user might think that they've migrated their wallet to a more secure access control policy yet the private key still

is able to sign messages that are accepted on chain via EC cover so there is a reason that we stopped going down the path of full EA migration is because we didn't have good answers for that that's not to say there isn't a good answer it's just that we couldn't really come up with something and it felt like the right thing to do would be to give users the sort of hybrid ability to both be a smart contract act as a smart contract in some cases but always have the EA private key as the master control for the account and allow to originate transactions that's why we ended up on 7702 I don't really think that there's something that we need to do here to change that direction because we spent a lot of time talking about it earlier

this year and didn't find a better solution to the EA migration so unless that we someone finds a better solution to full EO EA migration dealing with EC recover then to me like this is just not not really a possible change to make the 7702 got it I'm Pedro Richard were your comments were either of your comments about this specifically yeah yeah it's about 7702 as well uh basically I think the the most problematic thing that this proposal addresses is that on line exception in my view it feels a little bit like 3607 made it very clear that if there is contract code then it cannot

like send transactions and then that on line exception overrides that and it makes like 7702 do 3607 but if it does has a delegation then it still can send transactions I think that one should be addressed where you're either with contract deployed or you're not you you shouldn't be like in this in between you're a way but sometimes you're a smart contract either one or I mean you have to look at you you have to look at why 3607 was implemented in the first place and 3607 was implemented because we were worried about somebody potentially deploying a smart contract where they found the private key for in secret and the smart contract looks like an application and then secretly later on they use the

private key to drain the application's funds whereas with 7702 allowing them to submit transactions it's very clear that this is not an application it's got this delegate designator in front of it and so you can just see on chain that this is not an application is a user wallet so that's why it's okay to break the 3607 requirement but then do you still have the ability to revoke because the idea of code reset is that you're able to essentially come back to being an EA experience and the reason it was chosen to be an OP code is to be able to do that either after several transactions or atomically in the same transaction

and that's why like this proposal is like broken down into multiple pieces because it's trying to address users who want to have Smart contract capabilities per single transaction uh some that want to have it for like multiple transactions and most importantly to have the ability to unmigrate as well yeah I mean you can unmigrate by simply setting your delegate designator to the zero address it's not possible in the same transaction currently but 772 is not designed for users who want to have execution abstraction on the single transaction level it's supposed to be helping users use a Smart have a smart contract wallet like in

experience for the longer term and if they want to like completely turn that off there is a way but you just can't do it in the same transaction why why is there why is there any concern of doing it in a single transaction because this this proposal doing the same transaction to be Epal yeah and one thing that we sort of realized is that if you make it ephemeral this is the problem with 30 74 so is that if you are allowing people to make things ephemeral then you're sort of allowing them to have this different user experience from how smart contract wallets work and you know one thing that we have shifted the thinking on a lot in the last 6 months is that we want users

to however they're going to interact with the chain like whether it'sa 2 a smart contract wallet whatever then in general we want them to interact with the chain as if they have a smart contract wallet and that allows us to streamline a lot of the way the tooling works and the way that applications can expect user accounts to look if we also have this other alternative path for users to do ex execution abstracted things then now we have this whole other um you know ecosystems side uh Quest world for developers to go down and like build out different experiences and it's just like not something that is a priority for uh the the people working on accounts

abstraction I just feel like there's two two camps though right because I was also a big component of making it permanent because single transaction was not sufficient and that I'm glad that that change went through but now the single transaction is not possible as well so why isn't there a solution that essentially makes it optional you you can do it in a single transaction or you can do it in mult multiple transactions and the up code approach which is actually just a rename of self-destruct seem to be the Best of Both Worlds that you why do you want the single transaction approach so one one example of the single transaction is because U some cases like a little bit more

institutional they already have these policies built off chain with NPC and other infrastructure but they still want the batching in the gas sponsoring so they want some of the functionality that is enabled by 4237 without actually having the permanent uh contract code on chain that kind of puts the policies on chain but then you have like a little bit more the retail case where the smart contracts would like to be more permanent and I think this is a more op inated case where we went from single transaction to like permanent and I think we can have both and I don't think it's problematic to have both this I we can add everything we can put the whole kitchen seek in there but like everything we add makes proposal more

complicated and so now what we're proposing this code reset this has to add an a new OP code we have to deal with implementing this instruction and we can do these things like there's not like theoretical reasons that we can't do them it's just like everything that we do just adds more complexity and I am one Trying to minimize the complexity of L1 as you heard with eof so I don't think that we need to add anything to 772 that's not absolutely critical and two I don't think that we should constrain the way that we design the L1 protocol to support business business use cases that already exist out there we need to do the right thing for L1 today and not care too much about the types of businesses that are already built around the things um well I think that that's one

point of view um I I'm not going to reply to the fact whether or not we should cater to businesses that exist today but one thing that I wanted to point out is that the op code is actually bringing back it's more like a renaming of self-destruct actually it's not realistical just adding a new up code uh we Tred to actually make this proposal in a way that was a little bit more frictionless by bringing back self-destruct uh with a code reset that is specific okay um yeah I think we we're not going to like resolve this on this call um

we have the Discord channel to continue discussing it and it seems like there might be other ways we want to modify the spec like onar was uh was mentioning so um I would just move this conversation back to the Discord for the next couple weeks um and yeah I think um you know we don't even have devnet one fully launched yet which is still on like an old spec of 7702 so um yeah let's let's keep keep discussing the spec uh I think and then um yeah once we reach something and we're discussing the future that net we can figure out what we put in um but yeah can I ask a quick question to this

topic especially on this comments that you make it feels like the specs are still moving extremely and why you know I'm a smart contract I'm come from the smart contract uh smart account perspective so I'm actually I would be happy with these changes but I'm more concerned about the timeline actually and for me it's really like moving specs and changing the specs constantly makes it very hard to build tooling and I mean I'm have talking with Julian I think since two months now to get a test net up obviously if you change the spec constantly this doesn't make this easier and um it's very hard to reason about even how the current IP would turn out because nobody has a test net we cannot play with this at all on any form and don't know any implications really what is our timeline until when

when we really say okay for now let's really first freeze the spec launch like maybe a defet where we can play around or test net where we can play around it before we make further changes it's it's very hard for me for my side as an application developer we we have a devet that's launching next week with I believe an old version of the spec so we've effectively already done this and then I think maybe the way to think about this is more um from the client side we do these Dev Nets to find bugs and resolve issues so then when when um you know when we ship Dev one I imagine we'll find bugs we'll find some issues we'll fix them we'll see whether or not it makes sense to

like fix them on devet one or relaunch devnet 2 and I think when we launch the next devet that's a logical point to look at what the spec is and you know are there changes we want to bring in um so realistically you know in a week we're going to have a 7702 version live on a devet with an old spec um and then I don't know a couple weeks after that probably another devet and whether or not we update the spec uh on that one I think depends on just do we feel like there's something that's stable enough at that point that we learn more by like changing implementations than we would by keeping the old version um and I know that's not like ideal um in terms of just like building tooling on it um but

I think in terms of shipping the fork as a whole that's probably the best we can do um and then yeah like pairing and meus are pointing out in the chats there's a bunch of ways we can launch like local Dev Nets or just run you know Dev branches that have specific commits or or spec versions in um but yeah for the dev Nets as a whole I think we have to consider like the entire fork and then when we plan the next one what's the state of 7702 and is there something we want to pull in um and then yeah we'll have an old version of it live next week um Okay so so we only have 8 minutes left uh we did not get through nearly everything on the agenda um I think um probably what makes the most

sense is that for the three other proposals uh that were there so basically uh the log system contracts the coupling blobs El and cl and then uh 7212 have you know the the champion just give a quick update and then uh invite people to just review and discuss async and uh I I think we need to make a decision about any of those on today's Callum um yeah so like client you had the logs proposal for the system contracts uh you have a PR for this yeah I'm not the original proposer I think uh PK was the original proposer but we sort of said sop yes to this last allore devs I just wanted to get a

double check that for devet 2 and going forward that we deploy the system contracts with the events this is an event that happens whenever the user submits to the queue not anything related to the system call go it thanks um and you post yeah the pr was like a bit recent today but what I yeah what I'd push for is that if we can get people to review it async in the next week and then on the next CL call we can get it merged at the lay list that sound good okay um next up uh so Alex has a new EIP uh for Petra uh

7742 I don't know if Alex is on the call um but theas the decle blobs uh de decapo The Blob count on the El and cl um and then yeah have this just be a concern again this is a pretty new proposal um so I think yeah having teams review it in the next week and and um and discussing it on this C call makes sense I don't know if there any quick comments on it um okay and then uh next up so ripip

7212 uh Ulus um uh yeah wrote a summary of the current state of things um I think yeah so I think like Anar saying there's like a couple decisions to be made here first is like do we want this on L1 um and then second is like if we do what you know how do we approach it um I'm personally a bit skeptical of adding more stuff in pectra given we spent basically the entire call discussing in Pro process spec changes about like the core things in the fork um but yes I don't know youus do you

want to give a bit of context and yeah if anyone else wants to share their strong views on hello yes um yeah uh first there were some debates around the EIP and R rip stuff and I want to First mention that the EIP documentation is outdated and we have migrated all things to an rip and the last and final spec spec is there and this final spec has been accepted by most of the rollups and already on the main net in most of the most of them so even if pectra is very

com complex hard work from now but this proposal is already on Main net in some chains and and if we want to add it to L1 it will be and EAS easier as it's on Main net for some change and it's relatively very very small change and we have nearly all of the client implementations which some of them are used on on the rollups and I can mention some of the significant use cases about adding support for this alytic C the first is we know the account abstraction things are getting stronger

and if we are adding more power for account abstraction we need more signing methods and if we don't allow using this curve in more efficient way the account abstraction will be less powerful and this curve is supported by almost all of the device and Native Hardware so I think it's important and the second is ens team is willing to support this elliptic curve to use for DNS SEC and verify web to domains and I have read lots of

documentations from lots of rollup teams including scroll Tao and also flash BS and they are using some trusted execution and environments like sjx and these environments only support this elliptic curve and it's a proposal that can improve how they do remote attestations for different purposes like some verifications for their mechanisms or private encrypted mles so I think that it's a very valuable proposal for for also the L1 and very easy to implement as it's a basic change and already in live by all of the

rollups thanks um yeah okay we only have two minutes I think uh yeah any quick comments on this otherwise uh yeah it seems like there'd be a ton of work on devet one and then eof and 7702 before we can uh consider um consider other stuff um Marius uh there was a cter proposal to um in the RP rep uh I think 7969

7696 um which adds a generic verification precompile uh apparently it's much more expensive I don't know I just want deflect this here but there is something um else I would rather also do specific pre compiles instead of a generic one because generics are never really used we did with the pl to F and it's not used so just just wanted to thanks um and okay we only have one minute but any updates on 4 Forest that people want to

share or things that uh someone thinks we should look at outside of this call okay guess not um well in that case um thanks everyone um yeah please review the like three last proposals we discussed iyn and then um yeah we'll discuss them further on the next calls any final comments questions okay well yeah thanks everyone talk to you all soon thank you thanks thanks everyone

bye thanks all bye GL