Changes to the L1 EVM versus L2s | Devcon SEA

all right uh can you guys hear me well perfect thank you so much for the introduction and thanks for joining us today if you're watching the live stream thanks for tuning in so this will be essentially um the last one of today's um evm related sessions that were um kind of structured like an evm Min Summit here at dcon uh last year we had a full day um of evm me during Dev connect um and a lot of aspects of today's topics were actually um cover there but we will see um what's new and um highlight some of the um takeaways from last year's pels as well so thank you for the panelist as well for joining us um today and I would like to first um ask you to be briefly introduce yourselves and your involvement with the topic and evm let's start with Alex yeah it works okay yeah my name is Alex um I'm part of the on team which you may have heard here a couple of times today uh we do research um focusing around the evm um and we also did research on web assembly um and obviously because we focus on trying to improve the evm one of those big proposals is eof the other one is evx I'm definitely very bullish on getting those out and uh you know we have been working a lot on Main net so obviously I'm in favor of getting these improvements to l1s as well not just l2s all right all right my name is Daniel I've been in the solidity team uh since 2018 I've been the lead of solidity for I don't even know how long a few years now I think uh and yeah uh so we are the ones that actually need to generate code for the evm so uh yeah we also would be highly appreciative to have EF everywhere because and including l1s because uh yeah we will get into that but uh but yeah uh we in the ethereum foundation right now we're spinning out of that in the Argo Collective is anybody is interested in that there is a recording of a talk the other day but yeah that's it hey guys I'm Matt I go by like clients on the internet usually I work on the go ethereum team and have been working on some of these evm ideas for a while worked with Alex quite a bit on phas 2 for eth 2 back in the day thinking about what new execution environments in ethereum could look like and and also have just spent a lot of time since this concept of the rollup Centric road map was released thinking about what the interplay between L1 and L2 uh rollups would look like hey my name is Mark and I am a contributor to the optimism Collective we maintain the op stack which Powers a bunch of different you know L2 networks our goal is to commoditize stage two rollups so that anybody can you know use our free software to deploy a stage two rollup really easily I've written a bunch of solidity and have worked a lot on you know upgrading smart contracts that are running in production that hold lots of money have hit lots of different you know edge cases with doing upgrades um and yeah I I worked on EIP 1153 a little bit um was able to stream that into gu so have some experience working with um you know the evm and yeah I'm interested in just scaling ethereum generally cool awesome thank you so much so um I will address most of the questions to one of you but if anyone has any additional thoughts feel free to just jump in after so right so um the evm has been targeted for improvements pretty much since the early years of ethereum um and there are several related elements in the road map as well but uh there were always some other priorities in in previous hard work so there hasn't been too many significant changes happened around the evm uh so far um but there are a lot of progresses made when it comes to R&D um if you listen to Dano's talk on Tuesday or even today he gave a really good summary on that um and there are a bunch of new uh directions and it's definitely gaining more attention recently um so Alex you've been involved withm R&D for very long time um what do you consider some major Milestones when it comes to evm Improvement also how do you see the future the current road map elements how do they build up on each other or how do they interact with other road map elements um and maybe also just touch a little bit on the ZK aspect like how could these changes make the evm a bit more zik friendly how much time do we have for this question well try to give very brief summary um yeah I think some of these questions were addressed in like previous talks ESP special to zek element um I mean as you said evm has been has seen like different stages of development and sometimes it had more Focus other times less Focus um I think generally maybe the first year after ethereum launch there were more uh quicker changes like uh reverts were added um that was like you know quite an important an improvement and maybe shifts where the sometime later uh but the most of the development on evm has been more reactive uh regarding State um so most changes were gas related how do we deal with the state how do we improve cost around the state um or fixing something like the Shanghai attacks um or making changes around like the beacon chain integration like the merge and focus was less so on improving the evm itself um there have been I think things I initial l2s some were more explorative um people were always really curious at improving the evm um but there was One Direction where people spent most time on is a pre-compile um they wanted these big features which you couldn't achieve in the evm and so they opted for like uh maybe an easier way it turned out to be not an easier way in some sense it is other sense it isn't um some of these pre compiles have a lot of complexity they seem simple turn out they have consensus bugs every year uh some of them have taken more than four years to get adoption like the BLS promile it's still still being discussed um and so with all these in mind we have been in epsilon we took like a detour to to see like wasm would that be an option we came back to evm that evm is actually not that bad but it does need a lot of uh help to make it better and you know right now we have a lot of adoption around evm so that's the reason we we really want to improve the evm um and to touch like on the road map as I mentioned euf and evx um I think is like a good um direction to go euf gives you like a Bas line to build up on um but it also introduces you know a lot of like improvements um if you look at some benchmarks there are some benchmarks regarding code size and gas usage there are improvements to be seen there um and there have been some other benchmarks regarding ZK um just to touch on it quickly one issue in in ZK VM is um they may need to translate the the code and if you translate the code you need to keep access to the the code you cannot only uh use the the new translated version uh with UF you remove like code inspection code introspection so this problem goes away uh another big issue is like the gas cost um the gas costs are really tuned to like uh regular computers and some of these um things the evm has they would translate really differently in terms of computational cost on ZK removing introspection in EF also removes this problem um so we've seen some good benchmarks um that a ZK application of EF reduces proof size AG reduces uh proof generation time as well um so all of this seems to be positive but yeah of course it's still a lot to to be done uh going forward I'm not sure if anybody has I I said a lot I'm not sure if you have any like response to these I mean we definitely introduced bugs in our Bridge because of gas interest inspection so um I'm a big fan of a lot of the simplifications that are coming with eof l2s also desperately need um some sort of multi-dimensional 1559 so simplifying call I really like that um yeah I think the one major problem that we have is how do we upgrade our existing deployments to eof cool thanks so much um Danielle um what changes do you want to see see happen um on layer one evm before potentially oying it how could this potentially um interact with um the vision you have for solidity um I know there will be a talk on solidity later so hopefully no spoilers here um and also maybe how could these changes impact others in the ecosystem positively okay I mean I would say don't aify the layer one in general uh but yeah if people want to aify the the layer 1 AVM then uh yeah I could enumerate a number of things that are wrong with it that make lives harder for any compiler and developer and any tooling uh uh person uh UF solves a lot of the issues so eoff is a good basic block that would uh in bulk uh yeah reduce the complexity of compilers seduce the complexity of uh tooling and formal verification on top of it and yeah I mean you also touched on a few points already so uh if L1 is to be rified please at least give us UF in it first uh Beyond UF there is still a number of things that would be nice I mean we could have better memory pricing memory Pages even maybe give us some registers or something like that but yeah at some point okay I would understand if you don't but EF at least please uh but yeah I mean uh effects on other people I mean uh I'm pretty sure that a few people have picked up on for example the solar initiative of rewriting a a new compiler to solidity in in Rust they want to Target EF because they know that it actually is much simpler to build a compiler in a language in EF so I mean that goes for every language that goes for every language every tooling will be much easier to implement for EF because it's much easier to generate code for it so uh but you mean they would like to only target the UF if they can I only briefly talked with georgees yesterday I'm not entirely sure what their plans are and they only so far have a part so I'm not sure uh but yeah it sounded like very foolish on having EF and targeting EF but I can't speak for them further than that and Mainline solidity when do you drop Legacy support I mean we would love to as soon as possible it's a mess to generate code for the evm so I mean uh we do have for quite a while I mean I spent quite some effort from the Shanghai version of have we wanted it then I mean we have a delayed road map already because it didn't get in then uh we now are in the process of finalizing production support for the new eof but there has been prototypes for ages that were usable uh thanks to radic also shout out to him uh but uh yeah I mean it would actually help us extremely in our road map for the backand side of the language to uh to have EF and as soon as UF was there we would try to we would expect users to move to it immediately because all the advantages in gas cost and everything uh and would like to drop Legacy support as soon as possible at least so you you would you would ask l2s to adopt it quickly too as soon as possible I mean yeah we of course would need to have a transition period ignore that uh it would probably take a while for that time we would have to but as soon as ever possible all right cool how fast as soon I mean luckily um you know due to the design decisions that we made with the op stack architecture just easy to rebase onto you know the latest gu release or the latest W release and get all of the you know functionality into the L2 itself now when it comes to the smart contracts for the op stack on L1 that's going to be difficult to migrate to eof I would definitely love to but you know there's backwards compatibility concerns because applications may have hardcoded the address of the bridge today and we would need to deploy a new bridge and you know figure out a migration pattern and realistically there's just other things that we consider higher priority than you know migrating to eof for our L1 contracts this is the specific issue you mentioned regarding the bridges which I think we just need to understand a bit more um so maybe we don't have an answer for but I do I'm I'm curious about like a different question the many users of the op stack now multiple chains they they diverge from the op stack do they have like some of their own changes or it's like vanilla op stack always oh that's a great question so um there's it's free software people are allowed to do whatever they want with it um but we there's um this idea of just using the vanilla op stack and with that you kind of inherit all the tooling that everyone in the community is building so uh my personal philosophy is that you don't really need to make changes to the evm there's so many lwh hang fruits with user experience and go to market and that's where the next leg of growth will come from and it's not the you know adding a new pre-compiler or something like that so that bridging problem would would be solved and potentially all these op Tech users uh would be sorted yeah I mean the the bridging problem um is like the Legacy you know bridge that we have today that's written in preos is good enough um it's really like the making the front end more usable and getting people to adopt smart contract wallets that's inhibiting more adoption you want to I mean I was interested in the argument of importing tooling uh from the vanilla version of of the op stch I mean I would say that's actually a nice argument also for EF because EF has nicer transpilation properties so I mean it's much easier without the gas introspection and whatever whatever mess the evm has to actually transpile EF to a more modern system so I think it would actually be smoother to have EF and then actually build a more fancy version and import the entire tooling stack built for a plain EF version by a transpilation process without having to carry Legacy cost I think that's also for actually a future proof system actually a very nice uh property of f have to be a basis for something like that right so yeah there's been a lot of talk on you of um today as well and some other days um this panel is not particularly focusing on that but it's the next planned evm upgrade and it's basically going to be the biggest change um in evm history um so definitely want to cover it a little bit so since it's a core protocol upgrade obviously it has to be well tested and I think concerns around security or even introducing some complexity on the client level maintaining both Legacy evm and UF evm I think most people agree on this concerns and they want to make sure that this all happen the right way but I think what's interesting is that even though it's in the road map profile um there seems to be a bit of a discrepancy when it comes to its impact um and I see two main perspectives here basically that one saying is that um e won't result in um too much performance Improvement um and the future art forks and ab brid should focus on uh other road map elements that would result in more settlement L performance improvements and the other one is that basically EF is not really about performance but it's just an absolutely crucial step to to make the EV to like a more mature virual machine even maybe help introduce um endgame features and make it more Z friendly um so Matt maybe uh let's he a different perspective here you you used to be um um you actually um published about EF after the merge and uh listing its benefit and um mentioning that it hasn't be happened because of these other priorities like the merge um that they were more urgent um has your perspective changed on on prioritizing the eof implementation um yeah I was really and am really excited about eof overall I think what it provides is the things that evm developers have been hoping for for five six seven eight years but the thing that really changed my mind about where I placed it on the priority list personally is thought that is it something that ethereum needs to have to succeed in the next 10 years or 20 years and I have felt since that Revelation which was a couple years ago now at this point that there are things that we're still trying to do today with respect to the execution layer and the consensus layer to me seem much more much closer more closely addressing these existential risks of ethereum not succeeding in the future and I'm not saying that it's time to aify the L1 evm but I do think that when we start talking about implementing changes to the evm that are very complicated I have to ask like if we do nothing if we don't do these things what is the worst case scenario and as we're moving towards this rollup Centric road map to me it feels like that is the natural place for the evolution of the evm and if we're going to really lean into the vision that L1 is a place to settle rollups I struggle to to be see theot motivation for making all of those changes happen on the L1 is there anything that maybe could change a perspective more Community Support impact analyzes um getting more people involved from the ecosystem um anyway I think the thing this is not a satisfying answer but I think the thing that would change my mind is if we decide that the RO of centric road map is wrong because as long as we're saying that that L1 is a settlement layer in my mind I feel that the clients should be the most robust pieces of that ecosystem that is the thing that cannot fail and we can probably most likely do eof in a safe way we are good at testing the evm we are good at introducing changes to the evm it will probably be fine but I just have to like ask the question we're adding hundreds of lines of code if not several thousand lines of code to L1 clients that just statistically adds more prob more surface area for attacks to happen for issues to occur not just today but in the future implementing new clients and I understand it's something that make compilers so much better then to me it's almost like saying you're taking compiler code compiler complexity and putting into L1 clients and when I have this thought I think I want L1 clients to be as thin as possible as simple as possible focused on providing one thing and right now that one thing is settlement layer for rollups can I say something spicy yet we like to add pre- compiles which have tens or hundreds 100, lines of code and uh and optimize assembly and all that and different clients use different versions of these I don't like pre- compiles that much I would love to have evm Max I think that to me E I would rather have evm Max in the next hard Fork than eof I think yeah yeah I mean we can go deep on kind of why it depends on EF technically it doesn't depend on it you can do it without but with ef you get a significant performance improvements um because you can remove a lot of the checks runtime checks and move them to um deployment time checks and in the end it this means whether it becomes competitive against promise or not and you know without EF it may not be competitive and then it's kind of pointless do you have a comparison between eof versus non eof evm Max or if Factor like a order of magnitude is it within the same order of magnitude for some of them so the checks you have to do I mean the bunch of there's also like code size um increase if you do it with ATF that may or may not be significant uh but you do get like a uh let's say like 30% code size Improvement um increase on every like evm Max instruction if you do it with ATF um you cannot like do any kind of optimizations for pre-allocation or anything like that um but the key difference is the runtime checks you have to do at each instruction um which you wouldn't have to do with UF I think there were some measurements for some of the instructions maybe it's negligible but it's also implementation specific for some instructions it isn't negligible um but generally no I don't have a proper number to tell right I I mean yeah I I think that even with the E eof version of evm Max there's been thoughts that it's not it's never going to be as performant as a pre-compile itself and so how much closer depends actually um rodex Talk mentioned one case libff one of the um b254 implementations used by certain client client or clients it's actually less performant than evx now I don't think G uses it uh so so there are much more performance implementations than libf but even now today uh with a pre compis different clients may have different performance yet we have a single gas cost for it right and you know in some cases evx would be faster but yeah if you look at like highly optimized code just in the context of the pre-compile highly optimized uh pre-compile would be cheaper but there's another factor that in many cases you have to use the pre compiles multiple times to achieve something you have to call like addition multiple times you have to call multiplication different times and it pre compies use a different form you have to you know translate back and forth the DMX you can skip all of this you can create highly specific implementations for the use case and so you may have better performance to because you skip all of those overheads as well so would you say the biggest argument like let's say the difference between eof evm Max and non eof evm Max is fairly substantial you would say the most important reason to have eof on mainnet is allowing people to implement whatever cryptographic Primitives they want without being blocked on waiting for pre- compiles for those like what is what types of things are you hoping for I mean eof is great but I'm thinking like why does it need to be on L1 and like one thing I'm hearing is that there are pre-compiled and I agree with you we don't want to put that many more pre-compiled on L1 but then the question is like how many more pre- compiles do we need is there going to be one more precompile that all of the zero knowledge rollups will be able to use probably not so then to me always one more so then to me the argument that makes more sense is that eof gives you this ability to write any kind of cryptographic primitive that your rup is going to need to verify its zero knowledge proofs yeah so I mean with these pre- compiles I think it's also like another aspect there were if you look at when they were uh proposed there were like a a hotspot I think 2020 was a hot spot where people were really 2019 2020 when they were like really uh feeling okay I can just propose this it may happen there was a lot of activity you know a lot of new curves and use cases and people kept proposing and then as time went on and nothing was accepted they slowed down why would I propose it nobody going to do anything about it um so there may be like this other aspect that if you open up the space the ability to prototype new curves and new use cases there may be you know a lot more stuff spinning up there as well and like another thing which never has been I think there may have been like discussion of the pre-compile but Stark verification that hasn't been covered but this would be able to also uh help in that um but generally evm Max span out e span out of evm Max so the core idea was uh steel bom trying to introduce remove the pre compiles and you know these are Primitives you need for it um and we had evm Max as like some kind of a idea specification uh and it needed something like UF to be really performant so this was actually the progr how it came about uh but we ended up those optimizations eof provides which are beneficial to vmx they're also beneficial to to contracts and gives like an upgrade path one to mention is you know uh address space extension which has been an interesting idea in order to do like State expiry uh eof would also be providing a path forward like address space extension even the current version addresses it mostly um and that could open the path to State expiry now of course we always have this question of legacy and you know it's like a big kind of worms Dan did you want to add something I mean yeah I mean I also find it always a bit surprising to hear this kind of like if L1 only is the settlement layer then why does it need any more changes I mean the settlement layer is very relevant the performance on it is re relevant and the correctness of it is relevant and I mean if people knew what compilers have to do in comparison to non uh UF code they would probably scream in fear and run away from any anything like that so I mean these things I mean of course for settlement layers you have a few contracts that need can be formally verified with large efforts but I mean still I mean all of that becomes easier the settlement layer becomes faster it becomes more robust and uh and verifiable all the way up the stack and I mean this complexity that I mean it's fair to argue that there it's good to have not that much complexity in the clients but I mean avoiding this complexity in the clients produces an enormous amount of complexity up the stack the entire way so I would at least be careful in weighing that now you might ask why doesn't an L2 just adopt eof so one thing is you know the L2 space it's still really early a lot of the projects are still kind of fighting for survival and it's harder to make long-term decisions when you're worried about just being around for the next few years so I think that we need to see more L2 ecosystems reach escape velocity before they'll be able to you know think longer term and do things like eof um there's also the problems of you know there's like barely any stage one Roll-Ups in production today right like most rollups they're stage zero still um it's really really hard to even get to stage one it was way harder than I thought it would be and you know we're not done we're still working to get towards stage two and we need to make sure that all rollups can eventually get to stage two and until that point it's really difficult to think about um you know pulling eof into um you know an L2 client yeah and that perspective makes me wonder if we are getting ahead of ourselves and we're not letting the ecosystem develop and we're trying to force something that is going to happen naturally on the l2s and sort of top down dictate what it should look like by pushing it onto the L1 I mean anything that comes to L1 we automatically inherit as l2s we learned that yeah I mean you know thank you for 7702 super hyped about that one um yeah I mean another concern is um you know it's way less likely that all of the developer tooling will get built if one L2 ecosystem adopts it so when L1 adopts a change there's basically a guarantee that all of the tooling will you know accommodate that change so that's like another risky reason as to why an L2 wouldn't want to adopt something before L1 does I still feel like this is a very near term focused thing like I think that if you take a step back and you think in five or 10 years I don't really see a reason that everybody will still be locked in on evm equivalent if we have reached stages to and we're comfortable like rups are going to want to differentiate and they're going to have more resources and they're going to find applications that reach a 100 million users or a billion users and once you get to that point then the developers will come and you're going to be able to create totally different ecosystems I mean there's still the argument that the transpilation properties of euf compared to Legacy ofm make all that easier so I mean even if that eventually is the goal will eventually happen it's much better to have a basis of euf for that sorry what what type of transpilation would you want to do in that I mean if you want to bootstrap a new set set of ecosystem for a new evm then euf can be transpiled to that new version and inherit all the tooling without building it from scratch and then you can import all the tooling and extend from there with Legacy AVM that's much harder I mean are we just not overly focused on reusing things and not starting from scratch I feel like we went I feel like you went down this path with ewm you know we were how having these ideas like let's just reuse the tooling around wasum and then we got turned out to be yeah I mean turned out that you know the time spent on that like how many years three four years during that time evm tooling caught up you know we had uh um what was it uh hot anyway you know we had all these Frameworks we had the buggers those were lacking um taking maybe a step back to to where you started the answer to I think yeah we started this question a while ago and you had a long answer you know what changed your mind and I think that was a reasonable answer and I do agree with a lot of it uh I think it just misses one point you know several reasons are are there why this ecosystem works and why the roab Centric road map works as of today uh I think one important aspect which we don't talk that much about is really the developer experience and that each of them have the same evm you write a you know a project an application once you can deploy it on any of them um you can you know you can optimize for whatever you're optimizing for whether you're optimizing for the given user based on a chain or you're optimizing for the cost for the speed um or you optimize for the longevity and you go for main net you know it's much more expensive but you can deploy the same thing uh not only the same smart contract but everything around it you know the RPC and everything is the same you can write once Loy anywhere I think that's very P powerful and if we start you know diverging in each of these because we hope that one of them going to do like bigger evm improvements um that can only realistically happen if one of them becomes dominating uh or they have some other incentives to get all of these developers and and tools and everything around it um do we want one of them to dominate maybe we do but I think this is going to really take some time before we get there uh while at the same time there's some maybe other l1s or other Chang or other directions which focus more on developer experience um and there's certainly people you know whatever you give to developers they're going to work at the r right there's nothing stopping them right so the evm is not stopping developers they they find the work RS um but you know if somebody comes around and they have a much better developer experience you know that can Kickstart some changes um and I do think that we we really keep forgetting about developer experience and we are not unlocking potential enough if we would give you know slight improvements I think we would unlock a lot more and we may be able to progress more rapidly all right so um yay um cool so let's maybe go back a little bit uh to that suggestion to to move um developer experience improvements to layer 2os and Mark um kind of answered the part of that question that a lot of layer to and C kvms are currently basically focusing on performance improvements as well optimization so developer experience is is in the plans but it's not necessarily in the near future um I think in the last couple of days there were a lot of talks actually that um surprisingly um they had a lot of um plans um to to improve uh developer experience as well um what do you think the timeline is here um and those so could things like standardization or or these kind of initiatives maybe help with this to to speed this up totally yeah I mean I think that right now it's the developer tooling the developer experience um and like the end user experience that is inhibiting the growth of the ecosystem as a whole um I think that at least um you know we're we're really starting to get to a point where the actual L2 software is becoming stable enough and reliable enough and there's still a long way to go um like I said previously you know there's no stage two rollups like that are actually used a lot in production today and getting there is the number one priority um you know we do want to improve developer experience along the way um and I think uh with regards to you know the ZK EVMS and um the kind of like the fault prooof VMS those are definitely getting hardened um you know I know that there's a lot of great um Z kvms that have come out that you can just take say rust code and compile it and stick it in the zkm and not need to implement all of the evm changes uh by hand at like a really lowlevel abstraction and interact more closely to all the circuits and everything like that so these uh as these zkv Ms become you know more and more optimized I've been being told that you know there's orders of magnitudes of optimizations coming over the next few years um where I think it'll be a lot easier to just take um any arbitrary you know L2 software and be able to create ZK proofs for it um I think the idea of you know ZK roll up and optimistic rollup is kind of fake there shouldn't be a distinction it's just a rollup this idea of like optimistic or ZK that's a property of the bridge and that's not a property of the rollup right the rollup is not the bridge they're two different things I think this is like a really big misconception and I think that um you know we we're going to get to a point where all the ZK VMS are good enough that the stacks that are based on optimistic rollups will be able to just adopt yeah Okay cool so I would like to talk about this layer to focused um evm standardization initiative which is actually an act actual practical step um towards U layer to standardization this was launched last year um introducing monthly roll call um roll calls and um RPS or rollup Improvement proposals um and they've been happening every month um and basically these are optional standards for layer to um to adopt if they want to um has your team been involved in any of those totally yeah we have um reviewed a bunch of them and um I've personally attended a couple of the calls and um we also adopted the I think it was maybe rip 7272 the p256 pre-compile um I think the RP process is really useful for kind of drisking frag more fragmentation between all the different you know rollup Frameworks um I do think though it is still pretty early given that you know all of the uh most there's no stage two rollups so it's hard to focus on you know this standardization when everyone is still you know trying to actually build real rollup software okay right so on a and dra call um there was also um something new um introduced which is called um it's like a layer to evm Common Core basically um I think the point is to uh for layer tws to be equivalent with each other but not necessarily with layer one anymore um and also handling together um future layer 1 evm changes and make sure that are no conflicts um with those changes um Daniel what's your take on these just generally on these um coordinated layer to optimization initiatives how could this unfold yeah I mean that's great of course I mean the only way that we could ever accommodate anything on Layer Two that's not layer one is if it's a coordinated effort but I mean the problem is that we're busy with working around the issues of the layer 1 evm we also still don't have the time to actually really look into doing layer 2 work specifically because the layer one work is an extremely huge mess so I mean of course I mean layer 2 sanitization definitely good thing and actually definitely necessary for having anything uh any tooling support for layer tws in common but yeah I still would uh say that there is more space to actually accommodate Layer Two changes with a simple layer one at this point in time right um sir we are running out of time a little bit but if you would like to learn more about this initiative and Scar actually the um qu of this initiative we'll have a talk on this later on today at 540 I Believe on stage one but make sure you check the schedule um right so um maybe just one more thing quickly um Matt have you heard of the roll up G uh initiative maybe just uh share a few thoughts on that before we close yeah they've definitely heard of the RO of gu initiative it's a it's a very super interesting project I think that what they're trying to do is what needs to be happening right now because we're not going going to be able to evolve l2s if there isn't some kind of coordinated effort and it feels like the best coordinated effort is by making their lives easier and For Better or Worse most l2s are based off of L1 clients so providing them an L1 client that is maintained by a team focused on maintaining the coordinated the accepted um proposals and coordinating amongst the rollups to figure out what proposals to accept and for that team to implement those things make a lot of sense I am just very curious to see how it ends up evolving over the next couple years like Mark said you guys are super busy getting to stage two and yes you can just change your Upstream to be a different client but I think that the reality is going to be a lot more complicated than that as these things always are okay yeah totally having um you know this kind of neutral rollup gu is great but it does add you know some governance risk to the supply chain so um I imagine that it will need to be relatively conservative with what actually ends up in it um and yeah like I think that in an Ideal World nobody needs to use a fork of gu and you can just import gu as a library and kind of you know decorate it with extra functionality um this is like one thing that that is kind of interesting about like the WTH project where W um is kind of looking at l2s as um customers or users and tries to like build abstractions that make it easy for you know users to or LT to like build into ref but with G it's important to be credibly neutral so there's trade-offs here all right cool so um we have three more minutes actually less um anything you guys would like to highlight or any take uh from this panel um all of you maybe let's start with Alex well I mean I have questions on okay I I'm not sure if you have time for those because we will have a bunch of um yeah maybe we have the Q&A as well um maybe some of this is covered but the evm Common Core um I mean even now the different l2s like they have uh uh differences between them mostly on the ZK level because they cannot support like each of those or you know there's gas differences are you I'm not sure maybe Mark you're the closest um yeah how do you see like evm Common Core what is the first goal of it and maybe what is the medium-term goal of it is it like making sure that even these differences don't exist or it's like introducing new stuff or if it's just too early to tell totally to be honest I don't know a ton of information about evm common core but at least what I would like to see out of it is um introducing new things as the there's desire to you know improve the evm then it's about doing it in a consistent way right like no L2 team um it's like we we used to maintain a fork of the solidity compiler very very difficult so like having one set of tooling that works across the whole ecosystem is really really nice anyone else any conclusions or things to add quickly because we running out of time no I like the first question oh okay yeah questions are um coming soon um Alex anything else I mean I could go on forever but why don't we just look at the questions maybe I okay um do you think that any of these ler to standardization initiatives could help with shipping um some of these changes faster on layer one like maybe some layer 2's um adobos and and it works and then maybe the GU team says like okay fine it works it didn't break anything could this uh do you think it could improve this I mean my fear with this idea is that L1 teams love touch the standards they love to leave their little marks on them and modify them just a bit to fit L1 perfectly and I struggle to see how we're going to do anything complex on the layer two first and then bring it you know bring it exactly as it is on the L2 on the L1 even just with the p256 pre-compile the L1 Dev say maybe it's at the wrong address maybe we should move it to a different place BLS we're trying to figure out like what are where what is the exact parameters that are going to go into these functions where are these functions going to live like what are the address of these promiles doing these things on the L2 is just going to constrain what the L1 devs are going to be able to do so you're seeing the level of nitpicking is a bit uh bit more on L1 or it's extraordinarily High Yeah it need to be high quality but on the other side do you think there's a different need of like evm changes specifically you think like L1 has different need of what evm should look like versus l2s I think L1 has different needs than l2s and I also think that incremental changes are the best way to change the protocol yeah but on evm do you think it has different needs on L1 I think there are different needs than L2 okay cool thank you guys unfortunately we don't have any more time but uh there will be time to answer uh questions from the audience so thank you so much for joining us for today's panel don't we have time for the questions yes they are coming up from yeah can no and thank you very much for our wonderful speakers uh my name is Khan Al will be your MC for the next three hours for this stage um let's move on to questions before taking more time I will start with the topmost one this question goes to Matt uh why do you consider compiler bugs less scary than execution client bugs I have written both I written both and testing compilers is a lot harder than testing evm implementations they really really wanted to ask this question um so the way that I see it one I'm a client developer I try to keep the L1 safe that's my primary goal so I don't want to like belittle the job of a compiler developer it's thankless and it's very difficult but similarly to like keeping their codebase safe and secure like I am trying to focus on keeping my codebase safe and secure I don't want to try and then you know have blinders on and push all of the complexity on the L1 into other places but my perspective is what does the L1 provide what do blockchains provide that no other facility in the world provide and that's a platform for Unstoppable trustless execution of code and to me what you need to have happen is you need to have a blockchain that works doesn't have faults and if you need to write applications on top of that yes it's great to have a greater developer experience it's great to have a great compiler a safe compiler but we do know ways of writing code that's safe formally verified it's just extremely painful so I know that in the absolute worst case if we provide the L1 people will develop applications on it maybe those applications won't be as nice as people want them to be or they won't be developed as fast as they want to be but I believe that if we give them the platform to develop the applications they will build the applications that actually use the platform in the way that the platform is trying to provide and why should the they use the platform of any other competitor that does have a better layer one instead sorry I see the first part no I mean if you also who's to stop starting a new layer one chain that actually has the better experience on that level as well and then people moving to that because it has the same guarantees just only in a nicer way I mean we'll have to see how these types of things play out like you can already see there is a bit of a there is a comparison of ethereum and salana and ethereum is as Josh said in his opening speech the thing that does not go down many of the eth competitors have the meme of like going down salana goes down Iota goes down these other chains are not as resilient as ethereum and how do we maintain this property it's by being extremely thorough with the types of things that we put on mainnet that's not to say that we should get stuck in this mindset and totally aify but I think that it's like something that we have to balance very carefully and what ends up happening is you have people who are farther on my side who tend to think that we should be more aifi we have people who are trying to accelerate what's happening and we end up somewhere in the middle it's just not a fun process everybody on this panel is extremely reasonable and pleasant to be around but we just end up up here arguing about what the ethereum evm should look like there um so the next question is around in incompatibility around the VMS our um attendee asks that they don't understand why a bunch of a in bunch of incompatible modifications to the same VM AC acoss different L2 chains is considered beneficial isn't it good to have everyone on the same high quality VM anyone wants to take this I think we all want the same VM I mean we all want the same VM but um at the end of the day it's a free market for you know scaling ethereum that's kind of like what the L2 uh Centric road map is all about so you know any project has the right to modify the EV m in any way um but you know the reality is that there's a huge cost to modifying the evm just because the tooling is so important I think this goes back to to what you said earlier that um if something goes to L1 that's inherently coming to L2 we don't we haven't seen yet it happening that other way around uh maybe with the one pre-compile now maybe that could be the first occurrence um but this basically you know this question is if you do get it on on L1 the same high quality stuff we ensure that everybody gets it um if some L2 adopts something maybe another one adopts something else uh it's unlikely to ever uh reach L1 so there's going to be you know a lot more uh diverse version of FMS we have new questions coming in and the leader Bo changing the next question is what will be ipsilon Focus after eof I guess I can take this it's evm Max thank you the next one is in what ways could alternative languages I.E move or others bring new functionalities to ethereum deps that the current evm lacks I mean I guess I can try to take that but I mean all the languages have the problems of the evm as long as the evm is the Target so I mean language there's only so much the language level can do I mean you can try to have complex compilers that try to work around the issues of the evm there can be languages that are designed in the way that are more in which that's easier but uh but yeah I don't think that the language level is the level to solve the issues that AVM currently has adding an ALT VM um you know at the end of the day if we think about alt VMS like one of the big bottlenecks in the evm is you know like IO like reading and writing in a new VM is not going to solve that it's still going to be just as expensive to read and write from disk so like uh like adding an ALT VM maybe where um it's easier to you know build like a emit native code that you know Works off of you know 64 bits instead of 256bit math um that's like a way to like optimize you know the execution but it's only really useful for things that don't read and write from disk so the next one is around the evm again the evm going to is evm going to stay overall the same throughout the next years or is there any possibility for radical changes to update to modern architecture targeting smart contract needs I guess there is one list listen to the panel yes I guess there's one change upcoming I hope at least yeah right then the next one um discussion here suggests the rollup Centric growth map reduces the complexity in L1 yet with the diversity it means compared compared to Native homogeneous e two shards isn't the opposite true whose complexity on L1 his not mine at least moving on with the next question our attendee finds it funny that somehow L2 is going to innovate but we just heard they need to be conservative about guess changes why do we think that l2s are going to innovate more than L2 you know I think it really depends on the particular L2 ecosystem um you know some l2s like you know fuel um Stark net like they're very very different so anybody has the right to build really any sort of L2 that you want um there's just some l2s that you know want to be more similar to L1 so that they can adopt all the tooling that exists and you know maybe uh contribute improvements to the same tooling so that L1 also gets the improvements so yeah I think that the reality is that the bottleneck for adoption today is based on user experience in go to market and not improvements to the EV um I also think in general like with l2s you have the opportunity to try many different flavors or have different focuses whereas the L1 is this singular thing you can't really be super fast super decentralized you have to sort of choose on the different axises that you want to focus on whereas for L l2s you could have something that's you know privacy focused only you can have something that's extremely fast but might go down something that is you know Central points of failure and I think that the l2s like have the opportunity to experiment on those different axes that the L1 just doesn't have I think like can L1 specifically it's a bottleneck issue that uh you know there's only as many people there uh which are and they don't really have time for some of these proposals even including UF you know a couple of years ago nobody had the time to like dive deep but everybody had you know their views and opinions um and it was really just uh uh information access issue nobody had the time to Deep dive into it to have like a proper discussion and and you know get any of the opinions closer um I do think that UF could have been like you know couldn't shouldn't have been like this big of a debate and this big of a change and could have been done much earlier if there would have been more Bandit um that's ultimately what we are fighting around um so we're running out of time that that will be the all questions we'll be answering but feel free to catch our speakers after the talk uh let's give a big round of Applause for all of them