RollCall #8.2 Breakout: L2 Common Core

Transcript

um hello everyone welcome to the um Roo breakout on kind the basically the kickoff for the L2 evm Common Core um project so basically uh the idea would be to um have two two parts basically first start um and as as with as the agenda and the GitHub issue so that first basically start with with a meta section on um discussing um now now that people have heard uh the idea um from from the the last roll C breakout from from a while ago and then also um at at Defcon there were some more conversations um basically how much interest is there in general basically

we have the um uh the the the r up gu project as basically a way to make sure that we have a version of all major clients now that is willing to support IP specific features is this enough for like a pick and world or would we would it make sense to have some sort of shared feature set defined that um that mple elus basically opt into supporting to make it easier for tooling to to to to basically support so so that's kind of the first question and then if we if we basically do think we have critical mass here to to move ahead with the Common Core um basically what should be the the general kind of scope or type of features um there was some interesting conversation there at the uh interop uh day at the end of

Devcon and then in the second section uh more concretely talk about um assuming assuming people people do think would at least make sense to work towards a common cor version one and then then um make a go no go decision once we have that um concretely talk about what what features um meaning existing existing eips existing iips or or iips that are yet to be created should be part of of that kind of like first version um and uh a concrete decision like what what version of the of the L1 evm should that basically be based on which which heart fog if that makes sense so then um let's let's start with the first section the

The Meta section um assuming maybe people on this call have had some some time to think about about this um are there any thoughts any updated thoughts that that that people would want to briefly talk about um on like where for whether for their projects um in idea like a like a shared um evm standard as as a bases across Al would make sense or not yes Eric hi uh I hope the noise here is reasonable please tell me for doesn't um

so uh okay perfect uh so uh I'm with fire blocks um so from the wallet side we obviously integrate a lot of blockchains right like we integrate more than 80 blockchains today a lot of them are what like you know we refer to as EDM compatible uh which is a complex uh um statement um so I think for us it's meaningful to have standards that combine multiple blockchains and the fact that we have some definition if it even if it's not perfect of evm compatible is what allows us to scale uh um Integrations of evm compatible chains much more quickly than new l1s uh to

some extent we like have a different clue if you're an evm compatible or not an evm compatible uh uh blockchain same goes for some other compatibilities like cus comp compatibilities in so having additional standards that are uh appli able to a lot of blockchains and not just one blockchain in by blockchains I mean l2s as well just means that we can be much more uh uh scalable in supporting those new features right so instead of each and every single blockchain having to comes to us separately and asking if we're willing to support this Erp or not support thisp or those kind of things when we know that there's basically 20 blockchains

that are going to be supporting some standard like PR and cor and they're all asking for the same feature that feature can be better prioritize um so I definitely think that there's value in those additional definition layers uh if they get meaningful traction from the entire system right thank you yeah that's actually a really um good perspective we haven't really heard much from the wallet side yet in this process so that's actually very useful um and yeah and I think it it that mirrors kind of the the attention at least behind behind the the Common Core approach so so that's good good to hear that that seems Seems to to resonate uh

Harry um hey just um and I'm I'm i' still haven't been as quite as involved in this as as I as I wish I had just because I'm excited about the effort and definitely looking forward to it um I think one one thing that comes to mind on this is definitely sort of like just the the question of sort of Aragon already exists we already have one case where we kind of started with gu and and said hey let's start making improvements to it and kind of like fractioned out and like they are sort of they they think went in a direction of like relatively substantial changes so I think you know in in presumably in in the kind of rollup gu mindset um the goal will be sort of a much more limited diff just because sort of the thing that

gu has going forward is is stability and and kind of how tested it is and it'll be interesting to sort of modulate um how how substantial like the willingness to maintain changes um are and I think this is going to be interesting because it's going to come up a lot in terms of various performance related questions so like for example I think the GU team historically has not had much interest in optimizing for Block times that are faster than ethereum block times just because they're very focused on having the best possible ethereum experience um but whether or not kind of there'd be interest in in roll up gu in in optimizing more for certain things that you you care about a lot more when the block times are are

faster right yeah um so so basically the way I would think about it is that um to unlock more having more more IPS ship ship L2 basically they two in a way two pillars there's the the client side and then there is the um evm standard side and so um basically what what what rollup G was was aimed at was basically to to to unlock um the client side and make sure that um no matter which clients kind of uh the2 choose choose to go with that there is um kind of um there's a client that that's basically out of the box

focused on the kind of the dl2 um specific challenges um and and and so yeah I think the the the the intention here would be um I think we have we have both uh people from from the GU team and from the from from Ro up gu on the call um I think maybe uh if someone from the from the r up gu team would want to briefly kind of talk about their they approach in general to like basically the the aim of rollup gu but then also say the the support for for common call project but but just to to clarify right that this is all more like as a bit of a recap of the general roll call um um process there because even if

the Common Core basically ends up if we decide that that that there's no no need or no room for the for the Common Core as a shared basis that even that then still having clients that support individual IPS would be would be very useful but but if do we do have anyone from from Rock gu okay absolutely sorry just to clarify like the the the sort of purely just implementing the common po core rips I think is very exciting and and definitely like I think we're we're quite interested at in in offchain Labs I was more just kind of interested in sort of the where the scope was cut off for kind of what was being considered I think we you can think of it uh I would like uh if people hear thought of it uh the other way around so

instead of uh coming and asking uh R up get team uh are you planning to consider this or consider that think of R of gu as the place where if there is consensus am among layer to about a particular feature a particular Improvement particular whether it is performance related or an RP or whatever we will support in the r up G so instead of thinking about this team that you go and you ask whether they are willing to support a particular feature uh basically go to the other layer too so let's coordinate let's think oh do we all want this fature in particular uh if if the answer is yes roll up get tee will implement it doesn't matter what it is right or or at least we will engage in the discussion and we'll but it's not

like we're here uh in this far away place and you just come and ask oh are you willing to do this are you willing to do that no it's not like that right so we come together here every Layer Two uh every rollup uh brings up their their opin iion uh we discuss it and if there is rough consensus that uh the feature will benefit the majority of the rollups we'll implement it and that's it and and of and and and and so of course the nice thing is that the the

common core is basically like a good starting point because the Common Core by the definition is basically the on the on the evm feature side that basically like this the the the the the base kind of agreement of of features that are that are interesting for for several l2s and then of course there will be individual IPS on top of that um that say are still uh implemented by several L but not but not say by everyone in the Common Core um that will also be supported presumably by all the um L2 clients um and then there might there of course also things Beyond just M features or or like execution features right like things that are not spec changes but but more more General um um um usability improvements aimed at L2

specific needs um yeah and roll cor basically is supposed to be like a coordination place for for all of these right um back to the kind of the the more narrow kind of Common Core um ideas were there any any further kind of General um um opinions or or takes on it or otherwise I can I'll I have some some more specific questions to to get to get us more down the path there a list of suggested R these for common core already like uh you recently joined right yeah I mean um so basically that's that's that's in a way what this

call is about I have some maybe I can I don't know let me briefly uh share my screen I just wanted to get to to get started u with with with making sure that there's there some sort some general agreement that that going forward with this videoa makes sense but let me see let me share my screen [Music] um sh screen oh new okay can see screen or there was some new micos pop up I'm not sure if yep we can see you okay okay perfect uh yeah this is this is just uh

this was just basically so so so so in in the the last um um Roo breakout uh presentation and then also like this this this is the version of the slide from from the um the Defcon talk I had some some in general kind of examples for types of changes that that that could be relevant for the Common Core like um but but but those are those are not not specific to the version one but but more as like a general sense of types of features so uh repricings Native transaction types things like uh small specific changes like like the delay State computation but then also like bigger features like native account abstraction transaction paration potentially um some some sort of

solution to kind of state growth uh multidimensional pricing all of these none of none of this would definit like all of this of course it's just kind of my take of of of of potential questions and then I was basically I tried to come up with some specific list of of individual um candidate candidates for first version and this is not a non-conclusive list of course right so like actually be curious to to um to get people's takes on this but um maybe before we go into the the individual kind of candidates here like like the first question would be um like what should be the general scope of of a of a common core right so um uh in particular I think Proto is on the call

um there were some some conversations at the um at the interop day at Devcon where basically the one of the questions that came up was basically there are well I would I would say maybe in a way like three different versions of of of common cord what what my initial idea was is basically that that it really is similar to like hard for on on mainnet that it is like a full like a set of full features that have reference implementations in the individual clients um and then of course can be adapted um as as as usual by the individual to but then there's also the the alternative versions of um so so so Proto from the from the op side was was

saying that there might be more interest in just saying only base um evm um changes that that allow for better extensibility so um specifically on this list there is uh the second the second e mentioned is the 7685 which is general purpose El requests I'm not sure how many on the score are familiar but it's it's it's it's basically like a um um feature in the upcoming pectra hard for that um Proto mentioned as something that happened to be uh imp like like designed in a general enough way that it really allows for much easier exens of this part of the of the execution system and so so basically he was saying

that a common core that is just focused on these Ty of features might might be better that then Le leav the individual features on top uh up to the to the alus um and then there would there was also like an idea of a of basically say having having the the Common Core only Define interfaces and but leaving the implementation still up to the to the individual so yeah so so maybe before we dive into the individual questions the individual Fe fees do people have opinions on like would it would it make sense to to have like a common core based around actual features or just like making the evm more modular more more extensible for for the l2s but leaving the extens extensions up to the

L2 um yeah I guess makes sense I mentioned Proto that that that was your take so so go ahead yeah I think we should stop conflating the EFM and the rer excusion layer I think extension points are especially valuable in The Wider exclusion layer but within the EFM we have tooling that does not have many interfaces to work with and I mean there's only a limited name space of op codes and so on and it would be bad to diverge there so within the EPM I'm very much for uh more Collective uh feature iterations whereas outside of the EFM

but within the exclusion layer I think there's a lot of opportunity for good extension points right yeah that's that's actually a good take I keep reverting back to saying evm because it's just mimetically so simple but but you are you are right we should actually maybe start calling it the execution like the the ethereum execution Sy common core or something it's it's a bit more of a mouthful but but yeah so basically specifically maybe maybe that's also good to clarify for people who are not part of the conversation so the the the intention would be for this to for the scope of this to um include all things

execution so so there there might be some um some Logic for example um I mean in a way even even the transaction type right like like most of that logic is is from from outside the the the evm before before before execution actually gets started um and there are the other parts of the broad execution that's not just the narrow ABM that would be part of this but yeah it's it's it's a good kind of clarification to say that like within the evm actually focusing on on features makes sense um do other people otherwise I think we can just talk about the individual features and then things things will get clear there as well um yeah let's let's maybe

let's let let's yeah Harry you one more oh just just just a small comment I definitely agree with u with most of that I think the only thing I was going to add is like I definitely think yeah either like the set of things that are kind of not of interest to ethereum so like 2D transaction type um being a great example or the things that are kind of like generalization are definitely like more exciting to me than things that ethereum is actively working on like eof where like rollups could front run a little bit but I get more nervous there versus sort of working on things that are are not as as much interest elsewhere yeah that that makes sense I

think in general front running front running main at eips is a dangerous game and because you don't want to be in a situation where where where then you you can't um like once it's actually shipped on L1 uh you have issues with with with different versions um slightly Inc compatible version or something that is in general a question that of course will at some point be unavoidable um because as we start having more IP IPS shipped I know several of you for example have have already shipped the IP 7 to2 the the i1 curve um that is at least a a a very plausible candidate for a future mainnet um Fork as well and it's not guaranteed that it would be shipped in quite the identical uh form

um so so in in small ways this will be something that eventually we'll have to to deal with um anyway but but of course trying to to keep those those conflicts minimum makes sense um yeah I don't know Charles um yeah so if you if you have you know a decent set of implementations of something like 7212 uh and and you the main net is actually we want to do this too then you would hope they do it the same way and and largely that's a case of if you've designed it reasonably sensibly and thought you is this going

to work on Main net uh and a bunch of people who do l2s you can answer that question then it's it's much easier or you know or C to say yeah we will pick this up and do it the same so if if you're working on something that might you conceivably be a front run of of a main net EIP part of the thinking should be uh we should probably think about how to make sure it's going to be compatible with main net if they decide to pick it up but yeah you yeah no I mean that that sounds that sounds very reasonable actually so

basically the idea was to to use the R1 curve specifically as like a um um example for figuring a lot of this process out uh for now as as kind of the IP Pro got off the ground um L1 was the on the CF side was was not willing to necessarily commit to to to basically taking over IPS in an unchanged way right basically like just because they wanted to see kind of how how that process got going so so I think actually it it's it's a nice kind of like small enough change that that it really I think will be a good good way of testing how how people feel about this and then as these questions become more apparent then then also like we we will start to

to to to save to to find better ways for L1 CFS to maybe be a little bit involved in the in the L2 IP process so that they can be aware of the kind of changes that are in the pipeline and maybe can get feedback on which version of that at least has a good chance of of being um being being being a able to then be be taken over by the L1 in an unchanged way um but yeah I think all of this will have to be figured out as we go and so like for for a first version of common C probably indeed makes sense to keep it at least relatively light in terms of um features that that that might also be relevant for one um yeah with and specifically if if if you could look look at a few candidates and again like

if you have ideas if you have specific uh things you would want to see on there that's not on this list you know like that that would be really good to to mention here um but basically what I came up with so the first question would be in general like any Common Core version would have to Define which which version of the mainnet evm um it is based on uh the the the obvious candidates there would be um basically dun which is the version of the of the evm that is live on mainnet today um or the upcoming um but but close to being fully locked in spec spec wise kind of pectra release um which is the next hard for coming up um and then there's already there's already um individual

features in the pipeline for for the for fork after which called fusaka and but there I would recommend that we would if if there's interest in things like UF that we would pick the individual eaps instead of basically trying to be equivalent with with with what is still very much a moving Target um yeah is there any I don't I don't have a very good overview of like the exact evm version that all the individual at2s are using so um I don't know for example what the latency there is in terms of General equivalent with with um with the pectra evm um is would would it be feasible to to use kind of pectra as a as a fof point or or or would it be like would it be more practical to to to take

the the the today's dun evm and and only only add individual eips from from that from from pectra do people have opinions on this uh yes hi yeah so it's I think starting from pectra makes sense because it's not like if today we decide we start from Petra then tomorrow we have everything merged and ready to ship uh it's going to take uh sometime and assumingly we'll like still have the option to not use Spectra features even

if that's what like the it seems like there is some confusion between what's the code base and what's the standard right so um the codebase should absolutely have everything pectra that it can have like there there is no reason it it shouldn't um as for the standards I assume different rollups can still uh uh find what they need and enable what they need but eventually if you to start working now on some code base it's still some time ahead before people

merge it and then sometime yet before that gets shipped into our rollups yeah so in general I think um pretty much the same like uh there's I think there's no point in trying to shoose which evm we for from because like the version of the evm that you or or or the version of the client in general that you start that you that you use is just something that you configure when you launch your chain when you start your client on the chains speec on your Genesis file like that's nothing to do with the codebase that you use like uh if people if someone doesn't want to use Spectra feature they just don't enable it in the configuration when they

uh launch the client that's not something that you need to make a decision uh on the codebase like codebase is always up to date with the latest uh gu uh version and that's it right uh the exact version of the of the of the spec that you use is determined by the the the things that you activate when you launch your client that's not something we need to worry about we don't even need to think about that right so but like I think I think it makes sense yeah to to to explicit make that distinction between the code base and the and the standards right like with the the idea specifically with a common core would be to to have as like a spec Target that that that is a

set of features that all the AL that choose to to to to to follow Common Core and and uh and say uh announce Say by by this this time this date we we we will be on Common Core version one or something um that would mean that like all the features all the features that basically are part of the Common Core spec then would have would be expected to actually be supported by by the individual to so for example if there's anything in pectra that people would specifically not want to to be part of of that initial Target so for example if someone was like Hey BLS seems interesting but just a lot of cryptographic overhead we don't actually like it's going to take us a while we we wouldn't want that to be part of the

initial feature set or something um then it would it would be preferable if we say okay like we we the the the um uh the set of features that that everyone basically supports does not include this we could of course and and this is be curious to to hear people's feedback we could it could of course also make sense to define the Common Core as purely like a a diff so basically just a set of features um and it does not does not specify diff 2 D2 word version of the evm I personally yeah I'm not I don't know I'm not I'm not I'm not sure if that makes sense but uh if if if if that is if that fits better the kind of the the needs of the l2s then of course we could we could

basically do it that way uh you have uh I think uh it's I the question about pectra it's it's it seems really clear that we should start from Petra because uh because it will take time to uh to launch for anyway but uh more general question is what happens in future L1 Forks can we uh can we decide that Common Core always starts from the

current uh so it always includes all the current L1 features so like when we move to fusaka it's also assumed that the common core is now based fusaka I think we are um you know uh having few misunderstandings here like having something implemented in if if the common core is the r of gu code base uh then that code base does not define the spec for what's being wrong on the rollups like even today like multiple layer one chains can be using the same get versions and they can have different eips activated on each chain right like

the fact that you're using the same version of the client that you're using the same Ro of gu or whatever does not mean that you have the same spec of the chain the same features on the chain and that's even if so if you want to agree that all of the rollups will have a set of fure activated uh at some point in time that's not even a decision to be made on the Common Core perspective like we from the on the code would not have to do anything different to support that like that's that's something that has to be coordinated on the social layer that the different chains chains will the fure at the same time but that's not something that you do on the code not right I think I think it's I want to

make a distinction just just to make a distinction Common Core and and rollup G are two different things so rollup G is an implementation but there are also other implementations other clients other clients like Aron and aror never mind and others will to implement it so the the common core is actually the social coordination of what what should be turned on by default and then anyone can decide to turn on other rips whether they are based on a rollup gu or another client but the the agreement on Common Core is a set of RPS that everyone implements so my question was H not

related to the code but more on the coordination layer which ones uh uh which uh uh whether we always base everything whether all the rollups agree to always use the latest L1 L1 spec is the basis right yeah just to clarify because I do think that there was some confusion around this yeah so those are basically um in in different different things you can think of them as like a V diagram of of of of expanding Scopes where basically you have the the L1 um spec at the core then you have the L2 Common Core spec which is really a a list of features that the the individual L2 set

up into this would would uh commit to shipping in full and supporting in full um and then you have basically as a as an even larger set of of of features would be the the just like the the facto IPS that are um say ideally it would make sense to coordinate across the the L2 clients there as well basically the list of ips that are supported by all the l2s that can be enabled um in an opin basis so I think today all the if I'm if I'm not mistaken all um clients support I'm not actually sure if all the clients yet support the R1 curve but basically once that is the case that that would not that's not yet of course part of any common core or something but it's still basically available by the

individual clients and then the the the next most kind of shell would be like um L2 specific or like say L2 stack specific um features but basically yeah the distinction is important that like the common core is the actual um um social coordination decision um for for for people for for for shared features um and that is only a subset of the features that are available in the code bases of the L2 clients uh if that makes sense do we have uh do we have comments on that otherwise I also I wanted to get back to what um yo saying for the for as well that maybe first the two to raise stand here

how do I how do I pronounce that tah or like what tah okay uh so when you're talking about what's exactly when exactly arbitrum will support Petra the the answer is probably never if if you're talking about supporting exactly Petra because arbitrum doesn't support exactly London or anything else because there are things we change right the block number doesn't behave exactly like it is defined in the evm we don't accept we you can't post blobs to arbitrum and there is a good reason to believe you

would never will be U so I'm I think it makes sense to say that yes Common Core is based on pectra it will go forward with um uh when main net goes go forward it should absolutely be based on like uh uh more or less the current slash next um hard Fork but keep in mind that being based on pectra does not mean following everything that's uh that pectra says necessarily because some of it doesn't make sense for rollup some of it will be

different so if you're if you're really going for a a good definition of a common core you probably need to start with all these places where rollups are already different from mayet and where they won't stop being different and that's not a lack of eips uh yeah that makes that makes sense Charles so plus one to that comment um it's important to find out what are the the differences and to write them down and say here are the differences I think it makes a lot of sense to to say we're aiming to base on you know the

current evm you know every time that changes uh but you need to you probably need to explicitly look at each change so every time there's a hard you look at it and say okay uh is is there something thing that this changes in the common core is there something that's going into the the hard Fork that it's not going to go into rollups um but then in in terms of what is a uh a common core you have a spec of things it would be stupid to have a spec of things that no one implements obviously um you can have things that not everybody implements because you can

set the the versions as a Target and you know how do you manage fragmentation and difference it's like there's no magic rule on you know getting this right it's a a social process of what do we think is enough of this is implemented commonly to be able to say with a straight face for example to Eric saying you here here is a common core that if you work with this you can expect you know a a workable fraction of the market does it now and more of the market will pick it up um but then it does become

important to to say okay so what are the things where you know people don't what are the differences in in rollups and and how you manage making that information available I think is helpful to think about yeah those are really good um nuances Eric yeah so continuing from what uh uh was just mentioned in the last two comments um so number one uh indeed like right now already uh l2s are not exactly uh implementing the same specs um it's probably makes sense to say that what we

care about most on the wallet side is sort of the external layer of it so the fact that ZK VMS and optimistic uh like ZK rollups and optimistic rollups have different implementations entirely internally does not matter to us as long as what they're portraying to the outside world is the same uh um that might be um the way that events are transmitted that might be like generally different like you know Jason the Json RPC uh and I don't have a conclusive list but basically it's anything that touches the outside world and is not internal implementation detail um and still the fact is evm compatible is not really a defined term so in some

situations we kind of find ourselves sort of ad hoc defining it and so when an L2 comes to us we will ask specific questions we have like a list of I don't know 20 Questions we will ask and if the answer to some of these questions is no we might say well actually we don't consider this CVM compatible um now maybe we want to get to a place where that soft definition we have becomes a bit of a stronger definitions and then Common Court does try to be aware of that like which RPS are changing those definitions which rips are not changing those definitions um so yeah anyway I just wanted to say uh that like as one statement regarding the the the last comments and the second thing I wanted

to mention is or maybe ask is I think to some extent the first test to Common Core will be what happens after there's an rip that's being implemented across multiple l2s in a specific way then this rip becomes an EIP and basically um some changes uh are made or want to be made right uh suddenly we might end up with an evm version that is not compatible back to Common Core or is that something we have some commitment will not happen or if it is something that can happen what do we do about it right that's something that I'm interested in because otherwise we might end up with

like incompatible incompatibility between EVMS and d2s meain that in the I mean yeah I mean this this last point that was also what what came up earlier in the call that I think that's something where we can't really I think it would it's we're currently at it's it's a little premature to to to to have full answers for this I think that it's really good to flag that as hey going forward it's actually something where we have to have that conversation with the L1 and figure out basically how how this will um um um end up happening in practice I think unfort or not unfortunately but I I just think one one outcome that is not realistic is a full commitment from the L1 to never deviate from any features or

like if a feature basically is implemented on L1 that that already exist in some form in the L2 that it would always use the exact same um format for that because I think the L1 has has a very strong uh um feeling of sovereignty that it would not basically want to to to compromise on there um but of course anything that is that doesn't quite amount to that level of commitment I think there there's some some some reasonable compromises there I think practically for common core that just means that the initial version they say the first version but also like say initial versions probably will try to just be light on on features that could potentially generate conflicts to to specifically make sure that any conflicts that that might end up

happening are are kind of small enough in scope to be to be resolvable um yeah then then I will say that's actually something that like was not really on my radar which um is guess is silly but like yeah which is a really good question is basically um so evm equivalent is of course not a fully defined term and so there's a bit of a spectrum like just because someone is evm equivalent um I don't think any any evm equivalent L2 literally has uh all um um um um basically follows the one evm spec identically it's basically more like a this is the starting point and then we have a diff and and we behave differently and some features we just do not have enabled and everything that

that makes total sense so then the question is I think we have two choices here for the Common Core the Common Core could could either basically um come with the same level of uh adherence so if you say okay you're part of the Common Core you you you follow the common cor spec that means that same thing basically by and large you are um supporting the features of the Common Core but okay maybe you have a slightly different implementation or slightly different uh version or maybe some specific feature of the commic cor is just not enabled on on your all to because it's just architecturally not not not possible um so that that that that would have been my default kind of starting point my default position but of course an alternative choice we can make would be to say we give stronger guarantees so like if you are following

the Common Core then even though you might not like have like even even though your evm equivalence might not be like like extend to all the features of base evm on the Common Core we basically say that if if someone wants to follow the Common Core it has to be an exact match I don't know if people have have thoughts there and like how basically the whether we should we should have the same standard of equivalence between General evm and at the common core or whether it makes sense to have a stricter commitment to the Common Core Ty yeah I I think what I would like to see or the best case scenario for for me for a common core would be something that basically defines all the possible diffs

because I assume I I think I know that different RPS different rollups have different diffs and we're not going to now go back and change that but if we have like the a place that collects the possible ways the different ways in which different rups defer from the evm and actually do create some I don't know how possible this is but I think it should be uh to create some sort of uh metrics where uh different rollups can find themselves and that could be a great I think that could be great for

consolidation for actually like you know making people aware that okay this thing when you're thinking about this part and you're writing a smart contract or a wallet then this should be a programmable parameter because different rollups will behave differently there and then you just if you account for that and if you account for this set of things that could be a diff then you should be compatible with X dozens of rollups or whatever right yeah I I think that's a that like in interesting like that that would be a really nice thing to to to

have I'm not sure if that would specifically be like that that like a collection of diffs like that would live under the common core or even the the rollup the roll call um kind of process or or if that makes sense more sense independently I know that in the ecosystem there are already um attempts like that so I know that there's a roll up. codes which I think does a really good job um job job with with basically with something that that's already kind of similar um in a sense so maybe that could could be folded into into that um I do think that like once we have an a common core version one um it it it would make sense to to ask a question more narrowly there as well so like for

example it could make sense to to document as part of the Common Core process um basically which which El follow the Common Core in general but then also say for for each L2 maybe some annotations of like well this L2 follows the common core but with with this one kind of difference in this one feature something um so I think I think once we once we get closer that that that should be on the list of of things to be figured out um yeah were the other comments on like say the the the Common Core adherence to what extent that that should be similar to the EVS or or do we want to move to to the to talk about specific candidate features

um okay uh yeah then that's that's maybe uh use the uh rest of the I think the call was only scheduled for an hour right um and so that means we only have 10 minutes left uh clearly um this is something that like will require some time anyway to to work towards a common core uh release but let's maybe now go through um the individual kind of features I think so far people have been saying that it would probably make sense to be based to to have phasically the the um Common Core start start with a base on on on on pectra um so that would mean that all of the the the IPC listed as part of pectra would would basically

by default be be be already part of it um then then maybe no need to discuss those um right so so I think um in terms of in terms of other other features it would be interesting to to hear specifically what what people think would concretely add value and also be like small enough in scope for them to be to be kind of interesting in in an initial kind of version I I put UF on here but like I assume this might be a bit large in scope for for an initial release there are other features that are larger like M of account obstruction that could also potentially be candidates but also I felt like not they were basically too large in scope um yeah do people have specific um uh opinions on on on any of the features

listed here uh or other potential features that that you would want to see as as as part of an initial set um Harry just kind of related to the previous discussion I think basically the repricing is going to be interesting and that I think probably everybody here would agree that repricing would be valuable but I doubt that everybody here would agree on like what that repricing should be um so like for example optimistic Roll-Ups versus ZK rollups are going to be different here I'm sure within ZK Roll-Ups there there's differences um within chains there differences like figuring out like what how to handle that and like I ideally from my point of view kind of again to the previous conversation a little bit

like more normalizing that there will be differences in pricing um seems higher value than like locking everybody into to like a single different pricing yeah that's that's actually fair that that was one question I had specifically on pricing and there's there's a little bit of that also with a like more standard L2 kind of transaction type because that also might differ specifically across ZK and optimistic but I think with pricing it really is much more clear clearly the case because really optimal pricing differs really a lot from from L2 to L2 um so that so so there's a good case to be made that this should not be part of

the Common Core set at all that instead basically it's much more something where we should so so there's two parts of it there's one the just the general expectation as you were saying and that's more towards say smart contract developers right that like uh they know what to expect in ter terms of how their code behaves on different versions of the evm and then there's the the the actual uh um support say for example instead of every every L2 making individual changes to the gas schedule it might be nice to to have some sort of standard way in which um L2 clients now allow for more modularity there um so in in in that case that say that there could be some for example some

some version some IP here that that that would only define basically more just modularize the gas schedule in in some general way that could then be consumed by individual l2s so that would be an example of this um what what Proto was talking about earlier the kind of the these extensibility points um that that's something that yeah I I think could make a lot of sense but also probably will take some time to get right so so not clear whether that could be a candidate for the for the first version of common core and right and if if if not part of common C at all it could also just be something that we just like use roll call as a as a coordination form to both communicate this like the expectations

here to the to the to the community and and then the the developer community in particular and to say coordinate across the the individual L2 clients to um to support in in a standardized way but yeah my my my my assumption is that this basically that it really makes sense for the Common Core to to focus on features that make sense for all L2 in a very similar way so for example the R1 curve is an example of something um that I think for example I really think the R1 curve would be really natural fit for for first um version of common core and and and they are really um it it makes

sense to have that shared across across elus do we have other opinions um I think obviously so so um I mean UF is on here would I would be curious whether people um think UF would be feasible um say if we if we could get them get get the UF team to to basically have a commitment to like a kind of spec freeze so that we we make sure that that the version that we shipped then would would also um come to main it of course that there there's it's it's a large enough scope that there's always some risk of of um eventual Divergence um so that that M it maybe make some last minute changes after all um so so that comes with a bit of a risk I

think um yeah the R1 curve seems like a very natural fit and then otherwise the the transaction type repricing or any other features anything that people would want to see um I don't know if you for example really think that n now is the time for Native count obstruction and it should already be part of of version one then um maybe it would be worth just taking the time to make that happen um Nik uh there is another precompile for different uh cryptographic Primitives that is also I think quite interesting uh it allows different curves um it works with R1 but it also works with uh

Ed um and Baby J and a few other curves um so I think it's a an interesting candidate too okay another um another candidate it seems uh worth considering even for the first version is a a way to a way to check the layer one state from to whether using a l1s load or remote statical this is something this is going to enable so many things that we that we need such as a trustless bridging or or key stores so I would consider that yeah that's actually a really good

one I forgot that that should have been on this list here that's a that's a natural candidate um yeah is there um I'd actually be curious on that one specifically like an L L1 kind of static call Al or some some variant of of of accessing L1 state is that something L2 would be um interested in or have have have opinions on already um my my concern with that stuff is always just what the like node what the like performance requirement is like standardizing an interface for accessing the L1 block has like seems like a very

clear one um Beyond there I think it's mostly a question of sort of yeah node performance requirements like do you require an L1 archive node is always like the big question that comes up on there and like I probably personally I think like normalizing the requirement that like everybody runs an L2 node has to have an L1 archive node I I wouldn't love just because archive noes are a pain if there are things you can do that like don't have that that everybody could agree on I I totally agree the value is extremely high since obviously normalizing sort of interop features would be great I think doing just just L just L1 hash is not very useful especially for a

especially for optimistic rollups where you have to actually include the C data of the entire transaction so having a Merle proof in each transaction is going to make his STS too expensive to use but uh I think uh so I think we started from this and actually Ed suggested and Ed suggested that it could actually be you could use it in the fraud proof you could use the hash as part of the FL proof but then actually bring parts of the state H bring part of the state to Layer Two and not having to include a Merc proof in each transaction Nika yeah hi um actually this one I

already implemented it in the r of get so the way it was designed was uh not to require archive node on the uh to to to be implemented actually the idea was that l2s have some notion of the latest L1 block and that some notion is L2 dependent I think that uh scroll and op um optimism um have this we are predeployment uh that feature in rollup get is uh so

that uh that the the L2 uh bringing that code to their own code base uh can actually choose like inject this notion of L to uh sorry notion of the L1 uh latest block so basically you can uh you don't have to rely on that being uh smart contract or whatever you just inject it in the function call and everything is kind of modular so yeah I think that nice thing is that it doesn't require a node actually Ty yeah uh as we're nearing the uh uh

end of this meeting and especially uh given the last uh comment I I think it makes sense we were told uh let's create consensus among L2 about what needs to be enroll up gu and then have it I think if there exists a good forum to create such a consensus then I'm not aware of uh and uh that would be like what I would one thing I would like to see come out of this meeting is anything I don't know a Discord Channel whatever uh uh makes sense um to uh to have a mechanism to make that conversation amongst l2s uh and the

rollup gu about what should be there and how we get it there and um uh move stuff around right I mean I assume um there's there's two variant right like there's the it could make sense that like these inactions are on a l2s with each individual um um L2 client basis so like the l2s that today only use G have that channel with with roll up G and then the l2s that use R do do that with the rest team and so on or to have a a shared kind of communication uh um Channel uh that that has all the L2 clients present

um yeah I would say the best best thing to do here would be to to to follow up uh async and uh the nice thing is we have the the roll call the next roll call in a week so so the idea would be to um make make some decisions about about next steps and and and then present those there as well um but but yeah I think I think of course we have to figure out way to to iterate on this asynchronously um as well uh yeah we we have to we're about to to have to wrap up um if there any last comments and Nico you have your hand up or uh no that's it uh you you explained everything I just wanted to mention that

we have the telegram group and the Discord Channel already and uh if you're not there just feel free to uh to reach out to us and we will add you there sounds good but yeah just to clarify One Last Time right like though this this um this effort is about like kind of a commitment by L2 that want to participate on to like a specific feature set and then that would be across implemented and supported by by by by multiple M L2 clients uh so so this is this is like an an effort that is uh separate from from the the the rollup G project which which in turn is is a project that that is focused on um adding L2 specific functionality on top

of the the g code base specifically so just just to to make that clear one more time um yeah so then this was a good kickoff call uh we ran a little bit out of time towards the end but um yeah I I think it makes sense to just keep iterating towards the first um first list of features and then once we have that I think a lot of these questions around specific decisions who would actually want to support this how do we actually support this in particular like should should it come with a explicit um list of diffs of of actual implementations and things like that um I think all of that makes sense to figure out as we as we get closer to to an actual first version um but yeah

thank thank you everyone for for your participation your feedback and um yeah let's see see most of you or some of you all next week on on on the normal rooll call bye thank you thank you thank you thank you thank you thanks everyone bye