RollCall #8.1 Breakout: Future of L2 EVM

Transcript

okay um yeah hello everyone um welcome to the let me just briefly make it so I can see the screen okay welcome to the kind of the break call um the the idea is to to basically talk a little about um kind of our general um thoughts on um on the topic of of evm equivalence in particular and that's kind of um a big part of of of what we've been thinking about from the roll call side um the motivation behind roll call to begin with and and how we basically see the path forward um so yeah I want to basically split it up

into kind of chronologically kind of first first talk a little bit about like how we got to the concentration um uh and then a little bit about uh our our vision forward and and specific next steps uh a few quick disclaimers um just just to mention it um so all all of this is just our perspective right so I'm um if I'm ever sloppy in like wording a little bit to definitive um really this is all just about kind of how we see things and we would love to to kind of get feedback and obviously there on the second half of the call there there's going to be like an open discussion section um but yeah it's really just just kind of like our view on things our here also very explicitly being just like um k um k y

and me um not not representing anyone else not the not not any other larger group um Carl and I in particular have been kind of uh had been kind of thinking about this for long time and then you kind of specifically had the very similar thoughts and so we kind of aligned on the thing but it's really just just us um and then specifically on the scope as well uh here specifically we're talking about um the evm and execution broadly like I'll I'll use the term evm but what I mean with that um for the call is really more like anything kind of execution related but but specifically not not touched by that are like there two specific concerns or um

interoperability standards this kind of thing um and then also last disclaimer from my side um my apologies this this presentation won't have many Graphics or anything uh it's a little bit text based but uh if you if you keep keep the attention up it's hopefully going to be interesting um and then just to get it out of the way um we have an announce M and I don't want to basically throw that on you like halfway through the presentation so I want to mention it now already briefly and there's a new um Team a new client team uh specifically um called rollup gu which will maintain a um fog of GE that is more specifically aimed towards the um L2 setting um it it's a team within

nethermind um I'll talk a little bit more throughout the presentation of like what the what the specific vision for them is but I wanted to basically already start with start with the the announcement itself to get it out of the way um uh yeah and also by the way if you I think actually it's best if if we do questions maybe at the end of the presentation um okay so so quick quick history like like um how did you get here um so basically three sections first the evm itself um and then I want to talk a little about the L2 side and the client side so on the on the EV itself right um before before kind of like the the beacon chain launch there

there were all these these ideas for like a more comprehensive kind of like E2 um um um setting including execution charting and all these things and and the idea back then was to basically have e one basically just retire um and specifically also like the evm tied to that kind of more or less retired and um have E2 launch with new new execution environments and and and basically overall overh hold execution and that all only changed with the kind of the pivot to the rollup Centric road map um roughly I don't know for four five years ago um where basically people um where the idea was basically hey we already have an execution chain it's it's good

enough for for for the settlement requirements that you need from from a base chain uh in in a rollup Cent world let's just reuse it and so that's how kind of the the idea of the merge came to be but but implicitly with that also basically came came like a um basically giving up on on on these at least on the L1 side on on this kind of this work we had the easm team that then and and now it's called the ion team that's then then end up focusing on on other things but physically we sto working on like the next generation of of kind of execution um and not only that but also like since the merch um basically on the uh We've we've really kind of like um slow down progress

specifically on new El Centric features it doesn't mean the execution layer on ethereum doesn't chip things anymore but the things that that we ship are mostly focused on like execution layer consensus layer interoperability and and these kind of things and not So Much Anymore like actual execution um improvements and for example I just mentioned here like two two specific features that I worked on in the past um for example where um we we we for a while kept going on on This research on more advanced execution things like St ex bar native account obstruction we also did like 30 Erp 3074 all of these basically just ended up in this category of hey those are nice features and in a in a more kind of like high throughput

or um or otherwise more ambitious um evm chain we would probably ship them but but basically on the L1 at least for this moment we we don't see a need for them anymore so so so really the the the L1 evm has been has been kind of oif fying quite quite rapidly um so now uh why is that relevant in the L2 context of course that's kind of the um the the the the topic of evm equivalence so how how did we get there for the l2s Well from basically the L1 point of view the the initial expectation was that L2 basically would all focus on experimentation with novel execution environments basically take off where way two left left things um but but it turned out I mean of course there have been

especially like Al in in in the first wave of of of rollups there were a few experiments like that but um it became very obvious very clearly that basically um while ethereum as a whole could have with with some effort pivoted or like like like iterated to new execution system any individual like um L2 especially one that only just now got started just didn't have the the network effect um the kind of the weight to actually get anyone to to care or support any any kind of Novel features and so really kind of the only choice was to stay to to for for for for many L2 was to go with evm equivalence and basically just um make sure that you have have feature parity with with with the L1 um because that that's the only

way to really make it make it convenient for for users and developers to to unboard um since then of course we've seen a lot of L2 Innovation I mean it's been really quite the success story it's it's been amazing but but on the L2 side that has really kind of like mostly avoided this specific topic and and or the specific area and and for for the same reasons so L have heavily innovated on like most most specific functionality and and on the evm site on things like evm extensions um you know things like stylist just to name an example um right but but but not not not really kind of the core execution system and itself so much um and then the third part of the of the history that um I want to briefly

touch on is kind of the uh client um picture so so historically for the alus that has been very heavily dominated by by G um and that was just for for kind of obvious reasons by by the time that most alus got started G was kind of the strong L1 majority client kind of the obvious choice very very stable um in made sense um and so so ended up as kind of chosen as as the primary client by most to um but actually um yeah it it turns out this is not necessarily an ideal fit specifically because the um the GU team is is is very opinionated about wanting their primary and and more L sole Focus to remain on the L1 um and

so so basically they they just um don't usually aren't usually willing to to implement or support any kind of features that are only um relevant in the L2 context and so basically the client as a whole is very much um basically still a one Centric to this day um so so that's kind of like the the the three history pieces so basically the evm as a whole kind of aify and but at the same time being the the the kind of the the shared Target across the at least the L2 equival the evm equivalent um part of the L2 ecosystem and then get itself also as a as the the main client not not particularly um L2 focused um and so that gets us kind of to to to

today um um I would say what I just described was more like the um situation say as of the beginning of the year kind of like well covering the first few years of the r c gr map since then things have started to shift a little bit um and in particular um but but but but but but many things also are still kind of in a s spot so on the um L1 we we continue to basically only ship new El features um with relatively low frequency there are a few now though that are basically in the pipeline that I would call um a little bit bigger changes again but there would also say that um even there it's not an ideal fit for this kind of tight coupling of L1 and L2 specifically

because when we ship those on the L1 they're always very specific uh specifically kind of like tailored around what we need out of them on L1 um I picked kind of three examples of like the three main kind of bigger upcoming outside changes that I see um um and I think they might also cover the next three hards basically um U and I would say that the first ones 772 might might be the one that's the most kind of also reusable um on the uh on the L2 side um but of again that also still was was very much centered around the fact that on L1 the vast majority of of um users still use um EAS which might not be true at least on many of the l2s um and then a little bit later down the timeline we

have EF which um I personally am quite hopeful hopeful for also in the L2 context but for example we've already heard feedback from some of the l2s especially on the ZK site that that are quite worried about the implications um of euf and again point being here not that it's not an amazing features for for for f2s it's just that basically um L2 compatibility or czk compatibility was not a primary design concern um and so now it potentially causes issues and I think even better examples of that is ver where we we've had kind of Ro conversations in the past about um will L2 one to move over to verle as well once L one does and and then then that situation is is very very unclear and again one more of these features that

that that changes DM but changes the evm um based on what L1 specifically needs um now if we kind of look at uh the situation with with um evm equivalence um they definitely is still uh this this this resist this login effect and in particular I just wanted to briefly kind of categorize the the ways in which I think this Prim this this specifically really leads to a mismatch of of kind of priorities um or like not priorities but basically just like a Mis mismatch in setting and and and and kind of differences in what would be optimal for each layer um and in particular the the the four that I think are are dominating here are I for one just like the the um

long-term throughput uh levels uh I think um many l2s really would um in principle want their chance to go to you know just to you know basically G gigas levels um or something something on that on that order at least um L1 definitely does not have equivalent Ambitions and and that partially or like to to very weak part is also kind of driven by the fact that the full not requirements frankly are just very different right like L1 needs to basically be able to to to run on B more or less on a Raspberry Pi or at least some some some some similar machine and and that then I mean that's the whole point of of kind of the rollup Cent gr map the the execution compression that specifically gives us

the trustless on the L2 that then enables the l2s to have say even if you go to the extreme you could you could have an L2 where they in order to run a full note you you need to basically be in a Data Center and that would still of course now you have to make you have to answer some some other questions around how can users basically then get this specifically kind of get assurances but but in principle you you could have a setup like that that's still safe um but that only works because the L one um runs runs on such a diverse no set and but of course what kinds of what kind of VM you run uh optimally would would be different in these settings and then there is kind of the topic of of block building and in another one of course we

kind of we have this um um this rotation every 12 seconds different B producer um it's a very specific very opinionated um setup which just frankly obviously is already not how l2s um do today but but again it's basically a lot of these assumptions are kind of baked into the evm at at the Basel and then last last point of course um that that's a that's a very big one and very obvious one um um a subset of the L2 space and of course a growing subset over time probably like all of it um is is is is thek based and and and that brings its own kind of set of um requirements um things in which ways in which dbm is is

very much not optimal there um and and things that would be done differently if if one were to to T the BM around that and then as a last point I just wanted to mention it's not all just the differences in settings there's actually one one more factor or like that I see that also really kind of drives the the the um this kind of this this this tension between the kind of L1 needs and L2 needs and that is just that like L1 by its very nature is extremely conservative right um we we we very very very much never want to to to kind of to to um ship change features that that not just break the other one but even just like put us in a position where we we are not 100% comfortable having covered

all the edge cases and everything um it it leads to very slow moving L1 and that's just like and not quite the same kind of level of willingness of risk tolerance that that we see in the L2 um space um and then um on the client side they actually it's that I would say it's the um part of the picture where the the where we have seen the most kind of improvements recently and and and and that's been primarily driven by by WTH um which basically as a new major kind of L1 client came in and and and and and um started to be more explicitly um L2 focused um we've also more recently seen seen other Alon clients as well kind of Express more explicit interest in in in

kind of like supporting l2s so we we now have like a basically a um a broader base of clients and clients that are basically natively um um focused on the space but for now at least most L are still um still still based on G and and and don't have immediate kind of plans to to either kind of add support for other clients or even like deprecating get those support and in particular and what we've heard even from those that are looking into kind of support for new client a lot of them have expressed strong um I guess I can say a lot of you a lot of you have kind of expressed um in principle interest in and basically even even if you were to move to a to

client that that's more like like focus on on the needs of L2 um that you'd prefer to still then in that world be multic cined um and so and so keep have a way to to keep G support um yeah and and that's basically kind of the the the the picture of of um how we see the situation today this those are kind of the dimensions that I think are relevant regarding the kind of the situation of the evm um and that's kind of the basis for how we kind of made our plans might kind of have have our perspective of what to do um how to unlock L2 here in some sense um so that's kind of the the next section um and and just to now basically go back to the the initial

announcement specifically kind of roll up gu and and and start there right like start basically on the client picture side um so as I was saying like a lot of the system still based on gu um the idea here and it's basically uh to to to got this set up and started was basically collaboration between um the nethermind organization and kind of us from the roll call um side um so so the idea is to basically have a long longstanding longlasting kind of um L2 focused for of G um nether mind seem like like an ideal fit basically the um because of their own client they have a lot of kind of

strong um um experience around around the evm um and and have already worked in the past with with with with elus have have some some some view on these uh things as well um and and so really seem like an ideal partner there um and and basically they they will kind of uh host this this uh this team going forward also um after the presentation um we have we have we have some of them on on the call here as well so so so they all kind of briefly introduce themselves afterwards as well um the idea really is to basically have a client have have this client have or like this Fork have have a a collaborative relationship with G we

already kind of have talked with with with Marius um for example I'm not sure actually I can't see right now the participation participants list if if Mar is on the call well but basically we we've we've already talked with Marius um and um had uh had in principle kind of got the feedback that that g actually would would would would appreciate right like basically having having kind of that um um uh diversion of focus basically taking away from them and there would be one streamline team that they can basically interact with have have talk about upstreaming features these kind of things but basically have have this connective tissue between them and um and the2 um and so and then of course

the idea would be that this could would then um could then basically become a uh um basis um for for to support more L2 specific functionality and that can be someone is unmuted this okay um yeah so basically that that would cover both just like con convenience functionality more tailored around what l2s would would need out of a client um and then of course also um going forward basically L2 specific features IPS these kind of things but of course but I want to stress there just that like all of

that um will very much then be opt in so if you basically think this is interesting you would like to have a client team you you can talk to but but you're not sure yet whether you'd actually want to have a move beyond the scope of of of of L1 in terms of feature set um that would not basically that would be a separate question right so that that's not a um it doesn't come this this C doesn't come with a commitment to some sort of um new feure said um yeah and and in particular I want to talk about that point a little bit more so basically we we we and the the the hope would be that this way we can establish a kind of like a basis um with across the L2 ecosystem of of basically several of like a set of of L2

native clients um and and and and that way we can really basically we then have a kind of practical path uh to to to to get around to actually um shipping some some more advanced IPS in the past we basically we um when when we launched roll call we already were thinking that probably until we figured something like this out um we we mostly be blocked from actually doing meaningful um things and and indeed um if you've if you've attended any of the kind of the the the last months of of rooll call it it was quite obvious that well there were quite a few interesting kind of ips presented by different teams that that had interesting ideas um most of that is

sped by the fact that most l2s just have clients that have a client that that would not um Implement and maintain um a a feature that's only relevant in the L2 context and so if everyone has to um in their own kind of branch in their own Fork of of get maintain maintain a feature that that's basically nonstarter so um up to this point we haven't really been able to to to to support and kind of shipping any any IPS um but the one caret here and I'll I'll get back to this right on the slide but basically um on its own and this of course does not change that specs wise there's still the same kind of forcing function of the kind of L L1 evm equivalence where basically um just because now we we on

the client side have this unlock um and can basically start start looking into more advanced features um on its own this would only be a good fit for like say isolated small features like like pre-compiled these kind of things um and then more like under the hood features that that that might make bigger changes but in a way that's not exposed to to deps or users directly um because that way you could still kind of remain L1 evm equivalent um but and this is basically the the the second part um of our vision um we have thoughts on this as well because we really think for for for the reasons kind of that that outlined um we we really think that kind of this continued uh L1 evm equivalence

is not the the right path forward for the L2 ecosystem this again is just our our our perspective but so so basically what what we what we're proposing here in Edition so so basically the the uh roll up gu team will get will get started it's already set up they'll be around no matter what but like this this part this part is more opt in this this this part here the L2 evm common corn that I like to call it and I I personally am very excited about this I I think it's really would really be a crucial building block for um for having bringing evm Innovation back back to the l2s um but but this this part is op in if you if you don't think this makes sense then by all means um right um the idea here is that basically we would um we think it

would make a lot of sense to basically have some sort of shared set of of iips or otherwise kind of um evm changes that um that everyone who wants to opt into this uh Common Core um would would commit to supporting right so basically you you have some sort of shared base um shared extension of of of the L1 evm and that way basically you could you could really think of it um right like it basically gets you the best of both worlds you still are equivalent with with everyone else it's just that everyone else is is is is also now equivalent with you and your kind of enhanced feature set no longer with the L1 right so basically we are um the idea would be to really create a basically L2 evm which is basically a super set um I

mean of course over time there might also be some Chang from the breaking changes from the L1 evm but basically like it's it's mostly you can mostly think of it as a superet of of features from from from mainnet um that becomes the de facto kind of new basis um for on the L2 side um and so that means that like because because of the combined weight of of of of of um if of of the participants um it it it would become the primary kind of Target for for wallets for tooling for for things like solidity basically everything in the ecosystem um which would really kind of take take away these concerns around um around the inability to to to to make

changes because now we we would have the basis basis for that um one one one aspect of that is also would be that then that would be a good platform to kind of harmonize the um the way to how to to handle these upcoming Al one changes that I mentioned for example verle that would be um a group where we could these decision could decisions could be made um and just to kind of like give a little bit of of of a of an intuition of like how we think about this or like would think about this the the idea would be to to have basically The Best of Both Worlds right like have the standardization that you get from the L1 but the ambitiousness that we see today or in the individual al2 in terms

of um kind of like a rate of of new new features kind of ition and scope of of new features and and basically on on the Spectrum sit kind of in between in between those like in between L1 and L2 um the one caveat or the one kind of point I wanted to mention here is if if we inde need go down this path the path of the Common Core um and of course by by the way like none of this um like like in a common core world like just as today right like every L2 or every L2 stack would then still on top have their own kind of additional features things that AR specific to to an individual L2 this is just really about the kind of the shared base but as as such a shared

base it would require some sort of governance mechanism right because it would not just be a one-time kind of list of changes but over time kind of keep iterating and this kind of this question of how how do you kind of come to agreement on like which which new features to include into this kind of uh set of of of of um globally supported features and that needs governance of course of course at any point if if if you're part of the common coret and then a feature um gets added that that you really hate um you can always leave but of course then then we're back to kind of the the fragmented world so so really kind of the governance side of things is something that would need to be figured out um just to give you a little bit of an impression of because I've been

talking for like the entire talk now about like the the the ways in which the the L1 kind of evm equivalence hold St back I just wanted to give you like some impression from my side of like top topics that I see and those are really kind of like mostly kind of things from my from my wish list that that but that I've been mostly thinking about in the L1 context so far but just just just examples none of none of this would would end up having to to be say in the common coret um some of these could just be IPS that that separately are supported by the clients um if if if any else who's want ship them but it's things like um right say basic repricing right now even most thec

rollups really um feel the need to to to strongly follow the the pricing schedule of L1 but of course it's um it's in many ways quite quite mismatched if you compare to the the actual um resarch usage but it's not not only the ZK context it's also for example um the the relative balance between execution cost and um execution and data cost right which which where this trade of is very different um in the L2 context than in the L1 context these kind of things um just like like like a kind of like a onetime um way or like maybe even like a a more General kind of mechanism that where where individual altrose or chains can could could have their own kind of pricing table um something that I personally think would be a great unlock

for the L2 ecosystem of course that depends on to what extent people would want this but but I think basically and having some sort of basic two-dimensional transaction type that natively expresses both the um execution within the L2 chain but then also the L one settlement cost basically as a as a two-dimensional kind of cost Vector with within within one transaction type I personally think that would having something that this standardized across the L2 ecosystem this would not replace existing transaction types at least unless you would want to deprecate your existing transaction types it would just be a new one to support that basically would be standardized um I've I've been hearing a lot from from from people I don't know maybe I'm I have a biased sample of people I talked to but like that that that really um are struggling

with having to basically um um support the different different transaction um formats on on on different l2s um so so so that's something that also I think could could be exciting exciting in the in the in the short term um and then things like it's just like a topic that recently came up on the L1 side I'm I'm sure that would also be interesting to to to look into on the L2 side something like State Ro computation but really those are more mous examples in the long term there's even more examples to mention here like I think Native C obstruction is a big one we have in IP that's actually how the like that was a big part of like how how the roal IP process got going kind of you of coming coming to car and me and and specifically with this um this idea and

also expressing that the basically the need for for the IP process but as we've seen it's it's one of those features where if if um the the the main client used by L does not implement it then there's it's kind of completely INF feasible to ship um now kind of um or already say as just based on rollup gu um that that might change but but but Mo most importantly of course it could be a very natural fit as part of the Common Core um then things transaction paration um I mean meaning guaranteed one of course clients have already experimented with with with optimistic paralyzation um statelessness there's the different

kind of the flavors of course the statuses you get from something like veral trees but then also um say ways in which you can you can manage the state size even for State full nodes um specific kind of state expiry maybe in combination with State Rand we we basically out of the L1 context we have a fully kind of functional um um um um spec or not not fully spec yet speced out yet but like we have a version of St exper that would work um maybe there could be newer ones now but we we just decided never to ship it on a one um and then things I've been I've been looking in the past into multi M dimensional pricing that that would basic would further basically just um allow l2s to or any chains really including L1 to to

basically just um make more efficient um use of the available resources so yeah these are just again kind of to give you some examples I think I think the idea would be that that that there would be a lot that that that could be done um and I I assume most most of the things actually to be done would would actually come out of existing L2 needs and not just from from of side um then one more one more kind of um quick uh topic there on the on the vision side um and that's kind of the the the the role of roll call in in in this kind of now going forward um I was I called it season two because I just

want to B kind of like illustrate that like basically because of these constraints of uh that we have had so far that basically there was not really a way to specifically to ship IPS other than the ones that are trivial to maintain um basically uh roll call in the past in season one has was was was pretty pretty Toothless and so in in in going forward it would both kind of retain its existing role so kind of overall L2 coordination um and and uh and in a platform for IP um um IPS but uh and and there's this this this extra one that I've we've been trying um recently to lean more into which is kind of like trying to be this connective

tissue between L1 and L2 report a little bit from the L1 governance process bring feedback from the L2 side back into the L1 governance process these kind of things but of course um now in going forward there would also be um it would also be a platform for coordination across the uh clients that that that want to focus on the on the L2 kind of topics um if we go down the path of Common Core it would also kind of like be the kind of the anchor for for the governance there um and for the kind of the the the the research process andd process for for these kind of more advanced features to to to to not bring into the L2 evm um although just to mention this it could be that like maybe

this is a bit too much of a scope for for for kind of one process for one call so so so going for so once we kind of get this into mature State um it might might be time to kind of split that up into individual processes um yeah that's kind of our vision I hope I was I did a kind of decent job presenting that it really kind of like the two main kind of takeaways there are the um rollup gu the team that that one will will be a thing it is a thing now it it's something you should pay pay attention to um and then of course the the common core is is something that's more more ambitious more more optional say um requires op in but that we're also very excited about

and next steps rely on those two topics um on the roll up G side uh if you are in Layer Two that's currently using G you should internally kind of like decide your strategy around this would you move to want to move to up um how and one what basically what reassurances what you first want to see these kind of questions uh you should connect with the team again they'll briefly inro themselves in in a second once I'm done um and figure out like start figuring out the kind of the migration process and for other clients if you are re for example um it I think it would be a good moment in time to start kind of like establishing some some kind of ways of some some ways for collaboration across these these clients um and then last

slide um on the Common Core side um I think the most important thing would be initially for us to just determine we' we've talked with a lot of you individually in the past about about this and and have had like some general kind of um interest um but of course and that was all very noncommittal now the question is um with this more concretely kind of now scoped out is this something that that actually makes sense for you um how how viable is this basically we obviously this this this this is um makes only sense to to go forward with if the group of L that are willing to join the common core set um would would basically have enough traction um and then if so basically there's this governance to be figured out um and and kind of on the research side kind of

like to the idea here would by by the way not just not be to like necessarily have all the research on on kind of new features live within this this this this coordination process it's really more to just have a platform where the individual researchers from the from the elus can come together and talk about their individual work and and perspectives um and so kind of like there the questions of like what would be an initial scope for the Common Core um again the relationship between Z and optimistic I I kind of only touched on it a little bit for the talk that the question is does it even make sense to have a shared common coret there are like how to basically handle that question um and for all of this so just one announcement there we will have um a kind of a kickoff call that's more

focused on like hey what what would be a good kind of initial scope what are the kind of the the burning topics what what to focus on there um for the common core and that's going to be um the um after after Defcon December 4th um and then the the next roll call I think because because the the upcoming one will be right doing Defcon so that will be canceled so then the next dra call will be the week after basically um yeah so that's all from my side again I'm I'm terribly sorry that there was not a single picture in the entire slides um uh I don't know that's kind of more my style for presentation but I hope I hope it was still uh possible to follow and um yeah then that would would be all from my side and I guess we could first briefly have the

rollup gu team into themselves and then um we can have questions and open discussions and feedback these kind of things thanks hello everyone or man here so I'll be part of the r of gu team along with Nicola who is also part of the ne mine core team uh yeah with support with the rest of the team so yeah we we expect to to move forward with this project long term and actually grow the team as we go awesome

um yeah so now would be good time um to just basically open it up and um get some feedback like talk about to what extent does this make sense for the individual teams um maybe ways in which you disagree with our perspective there how we presented it these kind of things um I think I if you raise your hand and then we can n yeah thank you for the presentation just maybe a quick feedback if you are

to to do the same presentation at at Defcon make sure to include some pictures in the slides and uh yeah don't forget to to submit the presentation um I'm hijacking the call for a quick reminder but yeah the thean team is waiting for your presentation yeah yeah that that makes sense and uh to yeah to be clear that this this one I really focused on the content more because it's more like a technical audience um we we'll have a kind of more General kind of version of of of the talk of like the roll core vision for for um evm equivalence at Defcon and and that one will be very Nory friendly with with a lot of pictures thank you thank you

I see a question in chat um Vision slide uh slide 18 should I briefly I don't know um Let me let me first read some of these example are great but what happens if one L2 team pro one feature um is more valuable than than C differentiation no so basically um the the idea here would be to really have this be um the kind of the only the absolute subset of full agreement right so basically the idea is if there's features on there that um now that say the on the client side you you're no longer blocked and you have a client that is very that's willing to to

basically support a new IP that that you are interested in um by by all means the the the idea is that that um if you are com comfortable with with going live with that feature even if other l2s are not um and so then you you basically in that sense become have have some some sort of subset of features or behaviors where you are kind of have different behavior from other lus and but if you're com comfortable with with that and um kind of like users having to be aware of that or developers then then the idea is always that that you're supposed to kind of ship that and that like basically you still get the benefits of now having clients that are focused on supporting these types of features um the common coret would only ever be basically the subset of these

features that um l2's broadly kind of agree that that that they want to support um so that that for these features basically just for de Developers for users the it is clear that all chains that that that are part of the set will will support that feature right so basically it's just it removes that headache but but it's it's it's really just trying to extend the current situation like by no means would would is basically the idea that now you you you'd be more restrained in um in shipping features on your own um and the follow-up questions what about the cases uh where we all agree but the order is not agreed upon yes so of course there's lot a lot to be

figured out here um I I think I I'm again I don't think it would be on us to be too opinionated here uh because because clearly we don't want to um make decisions here for for the ecosystem um there could be many different variants of this right you could imagine that say the Common Core really reles a new um version once a year once every two years or something it comes with or once every six months I don't know kind it comes with some expectation of what timeline L's can ship the set of features this this all um would be TBD I think maybe if there uh I wanted to go over questions first um but maybe

I can present something that I had um not sure if I can't even share my screen but I can go over a few things that I wanted to say about the approach that we're taking for rollup get in general and how we envision the future is that okay or do we want to take a few more questions um yeah no I think that would be very valuable so go ahead okay I will try to share my screen although I'm not really sure if I [Music] can um I think you should be able to okay I'll have to rejoin sorry rein moment

um can you see my screen yeah yes I can see a screen okay so yeah this is what I wanted to to kind of cover an already covered uh most of it uh so I probably only wanted to go over our approach to to roll of G so yeah just to rorate a little bit on what Anar just said um yeah we saw this growing interest in the ecosystem in having like a common core repository where we would have basically we would serve as the base for all of the work that ler 2 is have uh so yeah the idea was to create a fork of gu that will serve this purpose as I'm as got

explained um so yeah basically rollup gu rollups that decide to use R gu as as their base they will be basically getting all of these features kind of for free uh and and then they would have only have to implement their own unique uh features like for example maybe arbit will Implement something like stylos or I don't know each layer two has their own thing that they Implement on on on the rollup uh that it's not necessarily something that we as a community want all their toose to have so so yeah that's the idea H longterm short term we're currently focusing on you know basically gaining a good understanding of the get the get code base at this

point uh so we're we come from core development but mostly with internet of Mind client uh I have some Fus experience with with G but we're basically right now uh trying to improve a lot our understanding of the G the g code base improve our understanding of how the different layer twos are using gu so we have been looking at the code for multiple layer tools out there how they use get how they Fork it what what they modify so what are the things that they need and trying to identify the different challenges uh that that roll up get will will have to face in the future right at the same time yeah we're trying to to figure out where the the eaps the RPS that that Mak sense um trying to get feedback from

from in general from the community from from different l two teams uh to understand what are the things that that we should focus on when we should build that energy because most of these CPS are actually not in their final form so we're trying to prototype them uh figuring out where are the things that need Improvement the things that need more work and so on so so yeah that's kind of the goals uh our approach right now the things that we're doing so we're trying to follow an approach where we are uh as less disruptive as possible with different layer toos so basically we're doing this thing where we try to uh whenever we can we're trying to basically Implement different theps in the way that minimizes the amount of

conflicts that the layer two would have to solve when merging with roll of G if that makes sense so basically whenever we want to implement an EIP we go through the g code g code base we figure it out what is the how how we could try to tackle the CIP in a way that has the less amount of modifications to the core uh to the core parts of the client so maybe we create new files rather than modifying uh existing files or we try to uh create hook functions that then we can Implement in different files or implementing different uh modules so that you know we're as Les as less

disruptive as possible we are also after implementing these eips we right now are going through multiple of the layer two forks uh we are trying to we're creating a PR that kind of merges the layer two changes with the roll up G changes and basically this PR would serve as a Showcase of what this layer two would have to do if they wanted to integrate with R up Gap today right so we have implementations right now in the repo for EAP 7706 and the which I don't remember the name the the number which is the S1 l1s load and we have the implementations for dcips in a PR for roll up G but then we

also have PRS that try to merge different layer two forks with the branches that contain the cips right uh these PRS are also kind of like test said We Run The rollup code to make sure that we can still sync the rollup Network that everything works fine uh but we're minimizing conflict so the amount of conflicts or the things that you would have to change uh in your code are minimal with respect to if you want to to actually integrate with r of gu today uh so it's not like you would have to just go over hundreds of files soling merge conflicts or anything like that uh so that's that's our main focus at the moment uh yeah so let just say so regarding this third

point like I said we're trying to to test uh everything make sure that the the rollup code still works although at this moment testing is not our focus and you know we will have to develop good strategies for how to to go about testing for all the different layer tools in the future right uh yeah so this is diagram for how branching strategy looks like I think this is uh something we're putting a lot of thought into because uh we want to basically we we don't want uh so we want to bridge this Gap that exists between the GU core team and multiple layer two teams not

only the big layer toos but also there are smaller layer toos and maybe don't have like such a big team so we want to help everyone kind kind of like have this this repository that can showcase how different implementation of different eaps would look like not only for G but also how different layer TOS could integrate with this code and how we think they should integrate with this code so that it's it's the least disruptive for them right so that we're putting a a lot of thought into that and we would appreciate your feedback uh with that yeah so for the future uh how do we see this R of G and different this synchronization process

so um from our perspective this would have have to be something like a governance process similar to to the AL deaths when we reach some form of consensus and which features we actually want to merge uh like we said uh we we hope we expect that in a couple months maybe whenever we we want to actually start uh getting roll of G included in layer twos we what we plan to do at some point is we want to agree on the set of eips we maybe want to agree on some kind of for prioritization of the cips and then we'll put up PRS for the implementation of the cips PRS for how the merging of this roll new rollup get

code would look like with the different layer to and then we would put those PRS just on hold uh until there is consensus that we want to to merge the different features into into the main branch and that we we might even be there to help layer two teams integrate with the code right so that the idea right that we will be kind of like the team that's there to help you out with anything that you need with the get code with r of get code with anything um yeah so uh like I said uh sample PRS for the integration of M layer twos uh one can go over see yeah so yeah basically this rting the same thing you can go over the PRS in the layer twos and see the

changes required to implement this uh so yeah maybe from time to time there will be things that uh for example there might be an EIP that we decide that uh in order to implement it introduces a lot of changes in core parts of the client so maybe we might be in touch with the GU team we might try to submit a patch Upstream that somehow refactors part of parts of the code so that it allows us to uh implement the feature in a way that it's you know it's less disruptive with the code base and and you know allows better Integrations particular ler twos I think this is something that the guest team might be open to to you know accepting F from time to time that makes our life easier

uh so yeah that's part of kind of our our plan right uh yeah so as part of this uh Ro of gu initiative I guess one other important thing is that we would be basically uh pulling updates from gu uh so uh so basically you would in case you wanted to integrate with r of G you would basically sh change your Upstream to be Ro of gu and and then we will be the ones that in a timely manner like every every few months or every couple of weeks or whatever we will be pulling the latest upgrades from from G we'll be making sure that if there is a security fix we will ship it as soon as possible so all of this right uh so so yeah we'll kind of like like aner say try to Bri

the Gap that exists right now between the GU team and all of the different l two teams yeah and with that yeah what do we need from you in case you're interested in the project well we will need feedback in general uh we have repository that you can go over right now you can take a look at the code that we're be doing you can I can also get feedback from from the approach that we're following you will be very much appreciated uh so yeah and in general you know we would like to hear from you what would you see as a blocker if you wanted to make the switch tomorrow uh to from get to roll up G what would be a blocker for you why not do it like what's holding you back what are the

things do you see that there are no gains or maybe the gains are not enough and those sort of things and the most important thing I would say also is um getting a list of the raps RPS I guess this is part of uh the governance process that we agreed that had to be F together somehow uh we are you know coming from the layer one in general and I'm I'm have I have some experience already with layer twos but I I'm sure that each layer two has a unique set of features that they would like to see implemented and it would be very good if all of you shared what are the features the main features that you

would like to see implemented in this Common Core so that we can take a look at all of them uh explore them a little bit and maybe come up with a prioritization somehow which of the ones that should be implemented first so yeah I guess that's everything um so yeah we can keep taking questions if you have any thank you very much and one thing before we go to questions very brief want to mention because I I already got the feedback privately that this was not clear when I said in the presentation by that um basically I'm not representing the EF in in kind of like in in in these General kind of thoughts I was I was talking more about the the broader

approach here um specifically I think it does make sense to stress that like the the RO up gu team specifically is a collaboration between nethermind and thef and um so basically it comes with like a kind of longer term commitment um to to to basically to make sure that this this team um is is in a place to to to do its job so I just wanted to stress that so that part actually that does come with um overall EF endorsement Kev you wanted to say something also by the way we are running up towards the end of the hour if people have to drop off that makes sense I think we can otherwise run over a little bit um yeah could you explain the

difference between um as a L2 if I wanted to use op ref versus rollup geff um is it that now I'm relying on one code base um in order to implement a particular feature so okay so roll of gu is so for example right now uh if you wanted to to run on OB stack you have Bas basically three choices you could use either op re uh op or op n mind for example right if you if we implemented roll up G so rollup G would basically bring a a common set of features uh that for example now op gu rather than being a fork of gu would

basically be a fork of uh roll up gu right so we would Implement a set of features on roll up gu that op gu would basically be getting for free these features will be available in op get uh if they decide to if you decide to to switch to to roll up G it's not like you're using roll up G to launch your rollup it's like you're using op still but now op is based on roll up G and it's inheriting all of the features that are roll up is that that your question um I I think somewhat I was more getting at like uh if there were two different l2s who have forked G then they have two different implementations whereas now it

seems like if they all rely on rollup gef is there one implementation that we need to make sure it doesn't have any bugs no so for example uh let's say that right now everyone needs uh account instruction let's say everyone was interested in account instruction right so but but Aon construction maybe is a huge implementation effort and no one has actually had the time and the resources to to to implement an Aon construction on their execution clients uh so what we would do is that rollup G might Implement a con Construction in the rollup G and then all of these layer toos that are Fork of G they would basically start uh you know merge the updates from R up G and now these all of

these different forks will still exist but now they would have a kind obstruction right because they inherited it from R of G does that make sense now uh yeah yeah so they they're relying on rollup GE in this case to get account abstraction in their Forks yes okay um I haven't heard any l2s speak is it possible for uh someone from an L2 to sort of say what are your general thoughts on this at the

moment um I see Proto DC don't mean to call you guys out if you don't want to talk I'm happy to comments um it's very new I I think I want to see the outputs before committing to to anything this can go very well or maybe not as well I do think the pattern of having a version of Gaff Upstream that layer twos can take from as a a way to standardize layer two features is powerful that share development process

makes sense but then we do have many more client many more implementation specifically um ref NE mind Aron all these things have to be maintained as well and I'm a little bit concerned about enshrining gav too much and I'm also worried about gav not being able to establish or how to put it not keeping up with the performance need needs of layer TOs and uh other efforts to try and provide this bleeding edge experience like

itaka are uh in a way competing with this design and I'm not sure if that type of competition is what we want if we are trying to standardize so so regarding different implementations I think I think this rollup Gap is coming because uh so the need for R of G is coming because uh most layer twos are started as a g fork and when you wanted something implemented in all of these L to um basically the easiest this easiest way would would have been to have it merged Upstream but the G theme is not like uh

it's not one to to to merge things Upstream that are only like relevant to L so that's the the the Gap that R get is coming to bridge but uh the other implementations like for example I can speak for net mind the net mind client would support uh automatically all of the features that we decide to implement in R up get so if a particular layer to uses NE mind client to as part of the their client stock uh they would get the features that roll up get gets um pretty much at the same time because we'll make sure that everything that goes into Pro get goes into the Mind client so that ler to using theine client can also you can keep using the Mind client and be

compatible with all these features uh I'm not sure about re for example but I expect that you know if a ler two decides to to start to to use R up get as an upstream it's just now you're basically inheriting features in the same way as if you would have Implement them in op for example and these other clients would be just keeping up with be G in a sense right the same way that they have been doing so far and all right one question about Sir go no I just wanted to say just to be very explicit right like the idea here is not that roll up get would be the client for rooll call or the client for the IP process or something it's really

just to make sure that l2s that a either today are in a position where they rely on get specifically and don't yet have a choice don't have an option to to to go m mul client or that choose to want to to have G as one of the supported clients that they have a way to participate to the extent possible kind of at least on the Common Core Set Side um but but it's totally fine for example if if one of the outcomes is that over time a different client say re I think re is kind of the front runner in in that space um just basically has many advantages and to just naturally choose to over time discontinue their gu support and are exclusively based on W that that that is totally fine like the client basically is here to

um have as large or as little of a role as as as it is useful for um and it's no no sense trying to basically like long-term have have any any specific role for for for for GU or G based code base in the L2 ecosystem very much just how what where the demand will basically bed this um and and and on the other point you said earlier I just wanted to to to briefly say I I totally agree that this can basically go well go not so well I think from our side we would just very very much appreciate any kind of feedback in the form of like hey this effort both both say on the rollup G side but then also on the um Common Core side hey this would be useful for us if it turns out this and this and this

specific way right so basically like anything that we can we can do to now to to guide it into a direction that ends up useful for the ecosystem we would be more than happy to do um and then just again try to find a way like a that that requires minimal kind of opt-in by by everyone to to basically just fill fill a useful slot and to the extent that you always want to continue having your own features in a more kind of like individual way or something that's totally fine this is really just trying to basically pild some extra role that right now is just unfill all right about the go ethereum like client as a base do we still maintain the exclusion layer

specifications what does that look like do new RPS go to rup G first or do go to the execution specs first because I see you know more prototyping more more of a feedback loop of users if it goes to rollup gav because you can test run it but I think that then harms the the multi client idea of ethereum too I agree with that that that one we would have to figure out but I would say I mean a I'm already expecting like you know with ether I think re for example is already doing a lot of like prototype

implementations of features as well um I think the healthiest thing I mean yes of course if we can have a more specs based kind of um approach there that would also be great I think alternatively also if we just basically over time have a some sort of collaboration Forum um across the kind of the the clients that are more most actively kind of targeting the2 and uh have coordination there on like which which kind of new and advanced features they are kind of implementing and and testing that that also I think um would be useful in that context but yeah I think having having rooll up get now play some sort of

outsides role in the ecosystem or basically some some role beyond what Beyond any other client that that would explicitly be a failure case that that specifically is um I mean it's good that you're pointing out because I do do agree that like it's easy to to just forget about but I I I I really think that this very importantly would be a failure case also you mentioned or I think you hinted at a way to compare which layer twos adopt which rips and eips this comparison type of website or something like that um is somebody working on this like where do we track the this type of thing

and also will we track the the rollup G diff in a in a similar way is that the same type of project or like how does that come together so the question is whether we have like a website where you can track the different that basically the changes that we're making to R of gu and different branches that we say we have for the with so adop changes yeah so we do not have at the moment uh such a website we could put it together actually I think we we we run the I think it's optimism that has this diff uh generating websites thing that

we can use and we used it locally to kind of go through the deps of few layer toos um we can we can probably put that up uh with without too much work uh right now the closest that we have to that is PRS so you can go through the diff in the pr because we haven't merged anything so you can basically go through the the div in a PR that implements uh EAP 7706 and then you can go through the div in a that basically merges op G with the rollup G EIP 7706 implementation so PR is PRS are the the things that we that we have right now and I think it

wouldn't be too hard to put together some kind of website and we could work on that potentially the main thing see see go wrong is that between opack and between ethereum layer one there's just one diff to keep track of but then once there are many different rips and it starts to look more like a tech three where there's a three of changes that might have some dependencies on one another and then keep keeping track of how that all fits together and what is needed to adopt a certain change might uh you know it's uh something that I think needs dedicated support to do well in the long

term compare this to ecosystems that use plugins for example you can browse the plugins like a Marketplace it's a lot more documented in that sense whereas if it's just get diffs it might become very messy very quick yeah I think I think with a lot of these questions it's really the case where like we have to figure figure this out as we go I think it's hard to set this up in advance because we just don't know yet what the demands are um but but I in general totally agree but I think this will be unavoidable if we end up ramping up kind of evm execution side Innovation overall on the the L2 space this will be a problem we have to face

and we'll have to find solutions for um I you know I I think I think the the alternative of basically just like the alternative of course would be that we just only ever have um innovation in each individual like L2 stack um which also works but but I I think kind of the having some sort of at least shared base would would be desirable enough to to to warant figuring all this out um DC did you have an opinion on this uh not not representing World coin

obviously yeah um I mean like for us the the I mean this is like I have a very different view of this because of like more of like app driven development like for us we we want to um like we we obviously care about the op stack right like we're part of the super chain therefore we have to like upgrade as everybody else does in the super chain so this is sort of like standardization effort um my personal like worries are the ones that have been voiced like in the chat as well like all the dependency tooling like solidity Etc all the downstream effects um to the effect of this um I mean I'd like to see just like the some form of diff um that is curated and then distributed to all the like respective tooling um I don't know like my views of this like I just need to

think about a bit more I don't have anything specific just yet um but yeah we would love to move to anything that makes the l2m experience faster I'm happy to support wherever possible and Nico you still have your hand raised I'm not sure if that's from an old question or if you want to say something else uh yeah that was from an old question but yeah actually I think the there is a lot of unanswered question and it's good if we could have a tread on ethereum magicians and discuss further there because it's it's going to raise a lot of um different topics and yeah maybe some of them can can be even site

projects like the website to to track everything but it would be great to have a a followup um dedicated topic on his M yeah that seems very reasonable um I guess oh sorry um I don't know ifto in here is the Roberto that I think it is if you if it is do you have an opinion on this hey Kev yeah um I mean I'm I'm very supportive of this initiative one of the things we've been worried about on the base side is we think we're going to outgrow gu at which point we'll be potentially um no longer multic client

um dependent entirely on W so I would love to see a fork of gu that keeps up with the performance goals that we have I'm glad to see you're thinking about things like delayed State Ruth I'm I'm also really excited about an L2 specific transaction type which I don't ever see making it into Gap so um uh and I would prefer that to be in a more standardized repo rather than purely an OP uh stack specific extension because obviously if you inod new transaction type needs to be supported by multiple wallets um and I don't think that would happen unless it's a standard that's uh accepted by not just op stack chains but you know the other prominent rollups as well um so for these Reasons I'm pretty eager to

follow along um also still thinking about this digesting what it means but initial Impressions um pretty positive thanks for do we have any maybe uh other it's funny now that the three um three people talking well op ST which which which which which is great um but but but do we um also have anyone from any of the other ecosystems um would be curious to basically see if if those are similar concerns or then maybe from a different perspective other concerns or um I think Derek from off chain Labs

had to drop the call yeah yeah he's not here anymore I was just about to to Ping him but then I could hear yeah yeah I think he had some concerns uh if I remember in the chat about like how this basically could slow down new features because now say there would have to be agreement on even if there's General agreement on like which features say to add to the common cor head but like it could be that that there's disagreement on on on ordering or timeline or or things like that and and there I just wanted to reiterate that this is really like this is supposed to just like p a role that purely adds value right this process so if there ever is disagreement or an individual al2 would prefer to ship something on a

faster timeline of course this is always a choice um um the the the idea here is really just that like this this could be could be a great platform for features that otherwise don't make it at all or where basically there specifically um I value in in sanitization so um if if you prefer to to ship any specific features on your own um absolutely right like and and ideally now um you have one more client that is um willing to um to implement and support IPS that you need for that what is the first course of action for

rup G what like how many team members are there currently and what feature will be implemented first I would say we're still on experimental phase so what we're doing right now is and I think that's what we wanted to focus on at least until close to end of the year so we couldn't we we chose a set of eips just from a list of eips very pretty much arbitrarily and started implementing eips that touch different parts of the GU the GU code base so that we could give us uh some insights like we trying to identify challenges like in eips that for example

touch the state transition code or EBS that touge the M code or whatever right so we're trying to trying to get a set of VIPs that implementing them would basically cover different parts of the code base so that we would get an understanding of what are the different challenges that we would face with implementing different types of eips uh in some sense and also familiarize ourselves with with the g c basent yeah so so that's that that's the idea right now so it's more like uh understanding learning uh experimenting with everything uh breaking things a little bit uh for for a couple of months before we actually get to okay we want

to implement the CIP for real let's get it uh working let's test it let's do everything so I guess this is the the time where the best contributions uh the best contribution from from the r two side would be uh reviewing our process so taking a look at what we've done uh you know giving us feedback what do you think we could do better what things would you like to to see changed uh how would you like this to to look like in the future uh so that maybe we can move in that direction yeah and in terms of new

features I do think that like say the if we have the breakout call um early December that would be a good place to like specifically talk a little about are there any specific features that maybe are flowing fruit that that are not don't require like a one-ear kind of research exploration first that that um elus many alus are interested in that basically could be could be good features for for not not just um rollup G of course but like all clients that are willing to to to to to spend attention on the L2 side to to implement and support um even before say we we get some sort of foral common core of the ground just to basically have these these Fe there and available um and I think again

it makes much more sense to actually go by what people want what teams want rather than to just be opinionated about um which features to to implement and chip okay do we have um anything more for the

score we so 23 minutes over the official window um otherwise again I think what would be very valuable for us in general like I think we we've now heard um Proto thank you very much that was very useful feedback um also from a few people in chat from um Roberto and from DC here um any continued kind of feedback of like skepticism is probably the best like what what what are the reasons for why you might not be interested in either like you know say rollup gu or or Al some sort of Common Core participating in kind of like like ever moving off of say the L1 as as your target at all um but also maybe Beyond skepticism if you think in general this is interesting and

you you you maybe specifically would but under some some specific conditions you think this this this would be something you want to participate in then that's that's of course also very very interesting to hear so basically any any thoughts any uncertainties any kind of um ways in which this could work best for you all um I think we would be very interested in hearing and yeah there's a question maybe goe with you if you could uh I think yeah I saw the question yeah so I think in general if for example one thing that would be super helpful at the

moment going over the the we have two PRS so and they're not that big uh taking a look and seeing the things the way we implemented them looking at for example if you're from the super chain looking at the pr that tries to merge op G with the features implemented in R of G and you know taking a look at seeing if you see some kind of red flags or we wouldn't merge this because there's a change here that it would break this other things for us right so this type of thing uh and also um giving us like some kind of hint of where the where the eips things not necessarily eips right but anything that you would like to see

implemented this this Ro of G I think those two things would be tremendously valuable for us yeah and uh I mean I think from from our side the the primary thing is really just basically the uh feedback on primarily the Common Core basically the the specific specific of the Common Core um is that something like because at some point there will have to be a decision like at some point

reasonably soon there will there will have to be a decision point of like hey this is kind of like some some initial set of features that that um people would want to be part of the Common Core and then which rollups actually want to support that those features um and so uh it would be nice to kind of get a feeling for under which circumstances would would would people be willing to participate in that um yeah okay I think then um this is probably good stopping point

for now I think uh we will set up some sort of uh discussion place as well over on E magicians um or something but I think e magicians is a good good place um but also of course we have the telegam group as well um so feel free to then continue the conversation as for now and uh hopefully see um many of you in person uh Defcon and then on the breakout call on December 4th thank you everyone thank you bye