RollCall #1

Transcript

all right let's get started so uh welcome everyone to roll call number one um the original plan was to host uh this in istanb but uh due to the circumstances that didn't end up happening uh but I think a lot of us managed to still get some fruitful discussions in bit more peace meal while we're over there so um today we want to start by discussing some of the new uh rips been proposed um and uh yeah then uh get get into some of the other topics so uh would like to start with the uh uh SEC p256 R1

pre-compile um which is being being moved from being rip forry EIP 7212 to becoming rip 7212 but basically the EIP will be deleted and recreated as an RP um and the idea then being that we can move it into Final Call so um asking for comments on what uh what the status of that well basically comments or objections to um the uh rip as it stands so yeah I'd like to uh hand over to the clave team um to uh discuss if there been any changes or basically

where all of this is from their perspective hello hello thanks for including in the agenda I hope everyone is fine I'm sharing the EIP page in the chats currently we are okay with the specifications as the co-authors and we received some feedbacks and recently we have change the address of the pre-compile implementation and change it into the next available address which is proposed in the one of the other pre compiles but not not active yet I have asked to the met the light clients and he suggested

to use this address 0 x0 B and there there is no other change and I think we are ready to go to the last call and discuss with the rollup team about any possible change and we would love to implement any any decided change to the RP version and we are also currently waiting for the RP I mean specifications for example how should we propose the existing EIP as an RP what should we do as numbering as the file structure should we delete the EIP there

are a few discussions in in the EIP editors section in the Discord we are also following it and ready to do any change and and discussions thanks OS um yes don't know don't know if you're speaking we can't hear you oh all good I was just saying that we're excited about it and yeah can you can you hear

me yeah yes okay my mic was on the wrong system um so with the B1 address what are the applications for the layer one teams will they be obligated to ship it at B um there was already uh L1 proposals for bls2 we B was one of the proposed uh uh numbers um what happens if L1 decides to do another pre-compile next that is not R1 are they obligated to skip B and go to C how will that impact compatibility would something in like the thousands be a more appropriate I mean I yeah I'm I'm concerned about B1 um ancar suggested that to blocking that address for for the future for for this specific precompile

right so um yeah I think basically we'll see this kind of happen more more frequently in the in the future anyway that that we have pre compilers that start that ship on layer twos first um but still are very reasonable candidate for layer one and so I think standard procedure should really be to basically just um block the pre-compile um uh address on layer one um so even in the case that that that layer one never ship some something that at least never also never ship something conflicting but of course uh we are not in a position to to fully commit to this year so this would was basically the only remaining item on my list um before before um moving this to this this IP to final would be to to

double check with the with the layer one teams and um get them to commit on on basically blocking this address um once the IP turns into final okay open I'm open to suggestions if for example you you think there's a strong reason why you'd want to have iips pre-compiled be in a different range even if they you know potentially could Target main at a later point then you know we we could discuss that so yeah I think that should be discussed with the um on ACD call but I think that actually brings up a second question is uh pre-compile coordination registry um because there are going to be chains that have pre- compiles it matter are just to them um rollups and there are ones that we want to share we also want

to make sure there's no Collision so I think the second thing that should fall out of this is some sort of a pre-compile registry rip yeah I personally uh I think that's a great idea I think like the very pratic first step on this would just be that we wanted to uh have um IPS basically have a section where they indicate which uh which the TOs have implemented them once the IP turns final of course that's not not good as as Central IP as one place where you can can see all of them so I think that that as a second step should also follow where we the only the only question there is um uh do we list basically all of the IPS that are just individual to to to to to specific rollups or only the

standardized ones Harry hey um yeah I think this is when I think I had posted a little bit about this on the in the chat um after last time I I really like the idea and I'm wondering what other people think about here um actually trying to get sort of names like you know let's say three name spaces of of promiles like there's there's the current implicit name space which is basically the all zeros prefix which is used by uh by L1 development but we could potentially just have sort of like a different prefix like you know 0x one 0000000000 uh and then you know one two

three and then you know two and basically have like the two other prefixes being one being um a a rip fully owned prefix where um if ethereum wants to like it'd be awesome if they also adopt the rip and just also have it in that prefix I don't think people really care about EIP about pre- compiles being incrementing from zero um and the other being a rollup specific prefix where rollups could put promiles and have a guarantee that like neither the EIP process or the rip process would collide with theirs um and then we could just never worry about this again yeah I think the idea having separate name spaces makes a lot of

sense um there's much easier to maintain Registries and that kind of thing onar yeah I would say just as a problematic kind of Next Step then because I know that the the R1 compile um authors really want this to get to final as soon as possible so I would that we basically bring this up as a topic on the next alod def's call I'm not quite sure that could be because of the the holidays this might I'm not quite sure when that is but uh basically make a decision over there whether people um they pref prefer kind of just using the normal range and bucking them or or having a separate range um for IPs with the understanding that main it would then also ship ship in they say that I want pre-compile if if we were to

ship that on one also at the IP um address basically um just confirm with them and then um get back to the IP authors update the IP and at that point then if there's not been any other update to the IP move it to final yeah I mean one of the really cool things about um pre compiles is that we have as much space as we need U it's not like op codes where it's sort of contentious as to um the availability availability and you need extensions etc etc um so this just giving us a really large name space seems very very possible uh hen I hope I'm saying that correctly yes yeah that's correct so

actually my question is like the so for the the R1 precompile case that it's potential like that the layer one can also pick up this pre compile in the future and that means like putting the different name space will be weird like if the L one eventually pick up this I think it's it's not that bad it just like it means that when you're calling into on the layer one it would also be at this other address I think it's more just like delineating so that we don't have conflicts um I as as was already mentioned by someone earlier on I don't think most people care what the address is of a contract they're calling

into um so then um it shouldn't shouldn't matter all too much so one small thing I would float here uh the the R1 pre-compile is mostly useful for uh account abstraction wallet contracts and those are created at you know create two addresses that can be the same across all chains I don't think it's unsolvable right so you can still make a contract that multiplexes on chain ID to call into uh one you know address on on rollups and another on on L on on L1 but if you want you know a single contract

to exist both on L1 and on rollups then it makes it somewhat simpler if if it exists at a single address yeah we could definitely solve it with some kind of um switch here but that would be I think just if we can avoid that that' be great um po you mentioned in your comment that is not quite as simple as that um in the chat you mind elaborating yeah I mean this is kind of the tax you pay for a pre-compile uh every time you call something even if you don't use a pre-compile you need to know if it addresses a precompile or not because it affects um and the other

aspects so this information is kind of critical and if you over complicate it like how you how you like determine if if an address is in precompile then like everyone has to pay this this additional cost so yeah if it's like if you use like H addresses like the prefix in the beginning then you need some kind of of map or I don't but um so for now it's just a range from from one to some number and the number changes by the by the hard workk number more or less um it's not I think big deal but

something to consider that if you introduce gaps that changes how it works currently um so there are some number of complications that it I think it's not like showstopper uh I think it makes sense to have the same precompile on the same address so some reservation is is fine but uh yeah I'm not sure I wants to use the the whole whole address space for for a pre compile so that's number of trados um like like one example is that a precompile is always kind of wor

Maxes so you need to know how much you will pay if you even check the like code size of some some account you need to know if it's a pre compile or not and that kind of breaks all of this abstraction okay um thanks for explaining some of those complexities Jordie yeah one thing one thing that I would like to put on the table is what would happen if the instead of defining a specific address we Define the address of the equivalent smart contract written in solidity or in VM I mean you have a um let's say a

canonical uh smart contract written for example this see this signature verification whatever I mean you do it in solidity you have a smart contract which is very well defined it's you have the definition in DM it's very clear it gives compatibility so if you don't if if for any other rollup if they don't want to implement something specific they already they already have something we know for sure that we don't have any consensus uh problem and the only difference here is the gas price I mean maybe there is some uh chains that decide that certain time uh uh smart contracts have a different uh gas price but for me this has the

advantage that we don't need to deal with addresses but has also the advantages that all the promiles that are standit they come with a very clear uh I mean a very clear definition uh have a consens very clear consensus so that there is no do if you implement it in one way or or or the other I mean I think an idea like that is very cool but it does require all implementations to be um like correct and audited and that kind of thing which adds I guess a little extra complexity because now we both need a really solid um compiled version as well as the pre-compile as in

like solidity compiled or whatever your favorite language is I think that's a little complicated um it also would certainly complicate the checks that PO is talking about um because now these would be deployed all over the place um but I do I do think it's interesting directions to go in and yeah I yourid me uh so I mean yourid uh um I mean different consensus things I mean different interpretations of the pr compile from different chains different people I mean imagine that this I mean there are some HKS that in one chain is done in one way in the other chain is done in the other way and and so I'm

afraid on this and uh having a I mean a canonical uh evm uh standard evm um compile that does that I mean this is the the the standard is the canonical I think this is a good thing so then in the case of the um EVN implementation differing from the pre-compile due to some kind of bug somewhere what is the correct version how do we address something like that I mean the the thing is that it's prec compile I mean you the is that any with this any chain uh if you change the code then you change the

precompile address so uh the promile is the I mean it's defined by that uh uh by that address if you change a single line of code or because you fix you correct or whatever you will have a different address so there is no doubt what you are executing so it's like it's smart it's a I mean it's it's precompile but it's not it's like a compil smart contract I mean it's a smart contract that's just doing that you can I mean you can deploy it that smart contract in any chain you know that this uh uh uh smart contract is going to work so you get compatibility out of the box uh to all the chains uh with a very clear uh way it's done and then the only

thing you do is just for acceleration okay because you have some specific implementations then specific rollups can decide to just uh uh low the price of uh uh sample compil but lowering the price is uh is much I think it's much easier to deal with I mean different interpretations different versions different chains some chains that Implement something the other chains don't Implement something uh just trying to simplify yeah I think those all valid points um I think there's still a lot of complexities we need to Ash out there um in terms of exactly how we do these these Progressive pre- compiles um

so um I think let's let's table the progressive pre compile discussion for now um and we can try like we can have this discussion um in a different context later um but yeah definitely interesting things to think about here Andreas yeah just a question from a from a pure developer um experience right and and solity comp or compiler point of view right I mean it's you have chains that implemented others don't right and do they point is do they implement it exactly the same way way so

I I think that's that's actually a big problem so a canonical way of of of doing it I think is absolutely required otherwise you you're going to screw with with um you know developer experience security um you know it's like R you know you you doing R1 signature on one it's not exact it doesn't doesn't verify on the other chain even though it should right there there are especially if you're doing like bri and stuff like that there all kinds of things that um really really um require saying No this has to be done in a particular way and only that way otherwise you're you're

breaking things all over the place so to be clear the like part of the purpose of this whole standards effort is like to have that one canonical way so the the idea behind having this um R1 go into um final call now is that uh this is the implementation that we'd like to ship um it should be the same across all chains um uh modulo some some weird bug um but yes if if if you're going to do it do it this way or have if you're going to do it differently then have it at a different address kind of thing Anar yeah I also just wanted to briefly

say on the topic of of progress of pre compiles because I think that this is idea that has come up before I don't think it's quite in time to take this into account for say this the the R1 pre compile here which address it should use but it's something worth following up um there was the idea because we we of course wanted to have the inperson event in Istanbul which unfortunately we could not do uh we had a few topics and like the progress Rec part was was on the agenda if I remember correctly there was an idea that we could starting maybe after the the holidays in January we basically um have a few breakout calls op B calls um centered on like each each call centered on one one of these topics from the agenda um or additional topics if they if they come up by then um maybe

using the same time slot kind of on the off weeks where we don't have this call for people interested um so I think those would be a good forum then um to have kind of more in-depth conversations around how to do these things but I don't I don't think it would be a good idea to kind of block block deploying kind of a pre- compile that's ready to go now until we have figured out um this topic Ahad yeah um just looking into uh that from the compiler perspective and developer perspective um it is it is of course a good thing to follow a canonical way especially for

l2s uh but there is a reason why we uh like there is a separation between what is to be implemented on L1 and wants to be implemented in L2 and one of the reasons is that not everything that is implemented in L1 makes sense to be implemented in2 like given for example 4844 blob gas vop code um and um uh like for example the 4788 uh uh pre-compile etc etc so for these it does it it does not really make sense like if if we're like all like I'm not like trying to uh uh stir up things here but evm

equivalence Etc does not make sense in these cases right and and in this case we need to look into okay probably here we need to know what we're compiling into is this smart contract being compiled into an L2 and if that's the case certain up codes needs to be known that they're not compatible with an L2 for example these op codes are made for L1 uh so like I'm all for canonical way of doing things but it's it's mostly like it should be known that this is for L2 and does not necessarily apply to L1 all the time yeah I think that's a very very valid point um and uh yeah basically the

idea that we're going to have alter native compilers um or maybe feature flags for certain RPS Etc um I think makes a lot of sense um in the compilers in terms of what this would look like and I think that's something we going to have to figure out on this call and uh um yeah for all the truly moving forward uh Paul um I'm not sure I fully agree but I I really like this idea to have at least uh kind of reference evm implementation and I know some some some l2s already is doing are doing this they have pre- compiles implemented in solidity or evm and they just deploy the code at the

given address so I don't think they like the the address deploying on is so big deal I mean the the benefits of that is is much greater in my opinion to to have that uh because if you don't have a capacity to like implement it in the whatever the back end you have you can just use CVM for for for this reason it also works great as a as a reference spec otherwise we need to reach out for some other sources to understand what Implement exactly and in the specific topic of this R1 we actually want to have implementation evm Max I don't think this will be like for deployment but at least for the spec might be good use for

it and we want to like check how well it works uh in this context yeah thanks thanks for that uh DW regarding the name spaces I think it's less of a question whether all l2s will Implement feature of L1 or vice versa but on the other way around do we want to prevent ever merging features from l2s into l1s or the other way around and I think there is a consensus that we don't want explicitly to block emerging we don't

want conflicts so it makes sense to have one name space and one place whether it's RP or the c or someone that will do the minimal work of managing this namespace of numbers it's not that it's going to someone is going to be neither L1 nor l2s to have thousands of numbers it's going to be a small maybe tens number of numbers and so you know that this namespace will always be a precompiled and just have this unique num Authority like Jana on the ipf on the internet that to manage these numbers to make sure that they never

overlap I think that's what one of the charters of having this RP so it will make eventually when some when cross execution course compatibility between networks will be added it's going to be simpler than a separate name spaces yeah I think that's a very valid point I think Anar is getting to that in the chat as well um and uh yeah having a a single registry um probably in the E's repo of this would would make a lot of sense then yeah I think but since since D mentioned the the I think know how how

it's done on the internet I think having a having a name space and no Collision no Collision for possible future merging is important but uh maybe what Harry suggested of having also also a range in a Range which is private and never h and is never emerged this uh this is probably okay the equivalent for this is the uh is the private address range for IPs there are certain IPS that you are allowed to uh allocate in any in any way you like and you know that it doesn't need to be compatible with other networks whereas the rest of the IP range uh is uh is allocated so I think the equivalent here would probably be to

have like a certain prefix under which uh things can be different on rollups and this is rollup specific stuff and anything outside this particular range is is a non-conflict Zone I mean if that's if that's a path that people would like to go down to be able to have separate things that people are deploying on their individual uh um L2 evm implementations I think that's that's totally fine um the this the would create quite a lot of um branching and Divergence in terms of implementations then um in

terms of what gets deployed but if there's demand for it then sure I don't think there's any reason not to do that um uh Harry hey yeah I just wanted to add u in terms of and I I kind of wish we were doing all of this like three years ago um I just you know speak I I could speak to both uh arbitrum and optimism already have uh kind of custom chain specific pre-compiled much or about other rollups but I wouldn't be surprised arbitrum unfortunately and this is definitely a regret um just used like some I think we're in the like 200 range or something we we sort of rather than Nam spacing

optimism I'm pretty sure Nam spaced all of their promiles behind some specific um prefix um oh yeah 420 um well uh well done on their part um so yeah this is a bit kind of like there's already this issue um this is it the past the past pre compiles are all known at this point so if we choose to standardize it this way we could uh we could have a document that covers all the current ones that are used by any rollup and then and just not add any

more of them without using the new name spaces yeah I think that's going to be one thing that we're going to have to just manage going forward on everyone's front is that there already is a lot of deployed code and a lot of people have had to make uh practical decisions in order to actually deploy uh their they l2s and so this means that we're going to um need to need to think about these things and handle them as they come up anyways um moving on uh the next topic I'd like to touch on is Rip 7560 um and that is the native account one um I believe we have some who want I

want to talk about that yeah I think I'll present about it uh so RP 7560 um it is uh heavily based on the previous ERT 47 that we made for account attraction so I'll give a brief overview to somebody is not very familiar what we try to solve is the ERC 467 for account obstruction is to allow smart contracts to feel like an actual account native for for the users and we tried to achieve it without introducing a consensus change or like changes to the evm so the way it was achieved that time uh was done with uh deploying entry

point contract and this entry point contract is a speci l it's a very important contract that was audited many times and this contract coordinates uh basically all the process that is happening with the uh is the account and the uh block building is separated and blocks of uh transactions that are abstracted that we called user operations is delegated to also separate pares which are bundlers put all of them together into a single large ethereum transaction of a legacy typ uh right and can you hear me yes yeah we can hear you fine yeah

yeah okay great uh so the uh RP 7560 takes this uh one step forward by introducing basically uh the same principles of account subtraction ERC and of uh U user operation as a new transaction type uh so uh in general we we propose to create a new transaction type we want to reserve Reserve number four for this transaction type and this transaction uh defines multiple additional Fields uh for uh to to define the sender to uh exct away away signature and we have some additional

features like multi-dimensional non support and a gas obstruction and execution obstruction built into this transaction type we and validity ranges so transaction is a little bit bigger and another step that we are taking is uh we want to introduce uh multiple top level execution frames for this transaction so this transaction will not just include a single po that's done from an EA to the Target but this transaction type can can include up to five I think or six the top level uh like frame execution frame

like calls uh like part first phase of this calls is to establish if the transaction is generally valid and eligible to be included in a block and the rest is the actual execution of this production deage um so we do Define uh like a number of interfaces and it is these are solidity interfaces these are very similar to how they look like in the ERC but with some changes that were probably necessary and uh I think yeah another thing that um like we realize while we're working on

it is uh it is a pretty complex uh task for the block Builder uh and like to the one who operate the mimport is fing the block to uh put this transaction in a block sequential because um transaction can change the state which means that they can affect each other's validity so a single transaction can flip a flag then the next transaction is not valid so I as far as I know that there this is not addressed in the previous account subraction e at 29 38 if I'm mistaken not mistaken uh that we need to isolate

the code that is running in validation from uh being uh modified also by other transactions in the same block so what we uh propose in the RP uh is to uh cut this transactions like in two parts basically and apply the validation part together before execution so if you have three transaction uh then you're running transaction one validation transaction two validation transaction three validation then you're want p and so on uh so I I I think I should post the

link to the EAP itself RP itself yeah post it here and in addition to that uh we did uh Define a very extensive list of uh storage rules uh which means that we want to uh limit the validation code uh and we are doing it in order to protect blog Builders so if blog Builders want to break this rules they are free to do so it's just that they might be exposed to some kind of denal of servic attack because they allow the

code uh to invalidate the block basically and this rules belong to an ER I think is relevant so I will share it as well uh here uh and uh what else should I mention yeah I think multi-dimensional nons this a th that we already do in uh um the ERC but we want to make it a more native part of uh of the blockchain so uh we

propos to introduce a a 256 by uh long nons uh that will be splitting into two parts uh and a sequential 64bit Valor and 192 bits of arbitrary data uh so uh multiple like to enable Smart contract to have multiple channels like smart accounts to have multiple channels of execution in parallel if you have like separate groups of people interacting with the accounts at the same time so uh I it's been like we will achieve that with

a a predeployment so we allow a soal pay Master contract uh to to accept a a pay a fee for a given transaction and in that case uh the

entire payment of G is substracted from this contract and not from the sender uh and uh because we are adding G struct and validity ranges uh like we are considering extending this to EA contracts as well because eventually if we introduce a way for EAS to inject code into their addresses uh that would make a lot of sense for them to do it with a tye four transaction that is subsidized by a pay master and has Li Ranger and benefits from other additions from this of this transaction type

uh dra did they miss anything wanted to say about the RP and if there are any questions uh first no uh not about the Rip but I wanted to add something about the uh the motivation behind it so this rip is actually uh this is actually what triggered the creation of this group of the rip process of roll call because uh we saw that I mean when when we worked on EC 437 uh we wanted to standardize account obstructions so that wallet developers can build once and deploy everywhere and this worked great but then H but then some some layer tools wanted to get

better efficiency and other benefits of having native account obstruction so uh so so we've seen a rollup starting to enshrine to enshrine version of 437 which they adapted for their needs in different ways and then we started seeing wallets that are we started seeing wallets that only support one chain like for example arent stopped supporting evm chains and switched to only to supporting only one chain that has native account obstruction so this so This motivated the creation of the rip process and also of this particular RP which is meant to standardize native account obstruction for those where for

chains that wish to have the benefits of native account destruction so this just a just a background for a how it all started thanks uh Alexander and Y have does anyone have any questions relating to uh this rip yes star yeah hi everyone so uh first I want to say thank you like the EAP is actually very comprehensive and I think it's very good but I have you know like one thing which makes me a bit uncomfortable is that one of the

introduction for this AP in order to improve the ux for users or rather for users of wallet is that takes origin for type four transactions will no longer be guaranteed to be an EA right and right now okay firstly there might be other protocols which depend on it well you know normal def5 ones but if we even skip this case then the majority of existing rollups I mean like arbitrum optimism and error as a casing all of them uh use checks for T ex origin for communication between ethereum and L2 and uh basically it works like if it's a contract then its

address is alest and if it's an EA then there is no alas applied to the sender address to the message Center and so I'm like Curious how like how will is there already a plan to resolve it maybe you know just from my perspective it looks like if we do it navely and on ethereum WE implement the same proposal which we have in the RP then the assumptions might break and refactoring the code like changing it in a way which for instance does alas in always ways for every account

including including e well it might be massive breaking change for the existing Integrations with such rollups too yeah thanks uh yes so uh so I also replied I also replied this comment po request um this is a this is indeed a it's indeed a problem for the ear for how aliasing is done is done by some of the rollups on on lay in the layer one Bridge contract but it uh can be uh but uh I mean I think it will have to be resolved it it will have to be resolved in some way in this contracts regardless

of this particular rip because it also conflicts with a few other with a few other eaps that are being proposed so um so then I started thinking about you know what what was the rational behind this exception alas sing is done for everything for for every address except for ones where a message sender equals T origin and if I understand correctly uh if I understand correctly the reason for this is H the reason for this is because the eoa on the other side is not able to do unaliasing which normal contracts can do can do so uh so so in that case I proposed the in my reply in my reply to

the comment in the pr I um I suggested some ways of of handling it in this layer one contract and I think that rups will uh wups should probably consider changing this exception regardless of this particular RP har hey yeah I need to I have not spent enough time catching up on this stuff so I will do that after this call but just to add a little color in terms of kind of the current state of like why Laing exists and and kind of what the point is is basically like we early on discovered the issue which is that U just because

you control a contract address on one chain doesn't mean you control a contract ja on another chain um and so aling was introduced in order to um in order to um avoid issues around that um yeah TX origin equals message sender was used used in order to sort of um exempt uh exempt EAS from aling it's it's it's a it's a messy system um and like certainly interesting to look at within the constraints of kind of what can be changed without breaking existing code um it's but it's it's yeah fundamentally the like hard problem is address name spacing um and and that would be the

thing to kind of consider in terms of any potential um Alternatives yeah so in the the context the context in which elas s was H was needed was because of this uh because the contract on layer one you could deploy a contract on layer one using the same deployer and create to a different address and this way you couldn't and this way since H since some rollups including arbit room uh actually use the message sender from layer one direct on Layer Two it made it possible to make calls from a contract on Layer Two that are not actually in the code of this contract and elas sing solved that and for that reason it seems to be not

needed for it seems to be not unneeded for EA however this will break as soon as there's a way to add code to an eoa and there are several uh there are several rip several eips that are that have been proposed for doing this start stting with so there's EAP 5003 that adds code there's the set code EAP 6913 then there's the transaction type for adding code that's say EAP 7377 so any of these eips is going to bring back the same vulnerability the same potential vulnerability because you'll be able to have a case where

something looks like an eoa on layer one it looks like a EA on layer one when you start a transaction and then it actually and then it actually does something to some to an address which is a contract on Layer Two so we are back to the same vulnerability therefore I think that uh before any of these eips is considered on layer on layer one we'll also need to change how elas sing well we also need to remove this exception in all of these contracts otherwise they all become vulnerable thanks off Pua um thank you um yeah I have I have a question for you with respect to the

category mentioned here and before I get into that thank you for providing the background for the proposal because I was trying to understand how rip process are being evolved so as for my understanding uh rip is similar to core interface networking ERC proposals which are standard track type and um core proposals are basically proposals which are proposed for the ethereum main net deploying here so if we consider this as an rip should it be rip I mean standard track rip instead of core what is the motivation behind adding it as a core proposal so um I don't know it's a I

mean rips and RPS that do change the core the core protocol currently on Layer Two and later and later maybe in someday on layer one should they be considered core or is core only layer one I'm actually not I'm not that familiar with the definitions here but maybe Carl and Ansgar are more are more familiar with the I mean what should be used there uh so what do you think I think this one of the the issues we need to we need to figure out and it's something I'm hoping to do sort of as we uh as we go um the I I like the point of the rip process is to have a

place for um rollups and extended evm users to be able to make core changes should they seem relevant to them um and so I don't I'm not particularly concerned with what we call it if people really feel like we need a new name we can come up with a new name um but yes we definitely should be able to make core changes to to these things um and and that is yeah something that is separate from from the IP process of course that's helpful thank you so much I'm here to just learn about the process of evolution and we can perhaps discuss this uh later on some governance SC yeah thanks pja I think that brings into light many questions we're going to

have to work out with um uh this whole RP process and how it fits in with theps which I think we've we've seen a few times already okay um then moving on um like client mentioned he'd like to uh uh touch on EIP 374 and get a bit of a temperature check for things I still kind of have a question on the other RP that nobody really answered in the chat okay um just curious like what the temperature check is for l2's adopting the account abstraction rip if it's not supported Upstream in clients because as it's written right now my

guess I we haven't talked about this internally with Guth is we probably wouldn't support it like it's just a kind of a large change across the client and if that's the case like how do other l2s feel about it is there anything would there be like some spectrum of things that we could do to make it easier to support has anyone has anyone thought this so uh first we have a for testing purposes we uh we started implementing our own so we have a so we have a fork we have a fork with a PO request that implements it now I know it's not going to be merged into a merged into a get in its current form anytime soon but I

think that is but isn't this the case for any rip I mean every layer to every Layer Two uses some patches on top of H on top of G in order to implement modifications get also doesn't have any of the pre- compiles that are used by different rollups so I think this would be the case uh I mean the same question should probably apply for any for any rip uh I mean that's well there's two aspects of that that that's true but in one sense they're trying to have the smallest diff between the Upstream client and their client and there's also the idea that having an additional compile is like kind of a nicely

abstracted away thing you've got this file and then in some map you have to put the address in there and Link it's the implementation of the pre-compile so supporting that is really simple in terms of uh you know merging upstream or sorry not merging Upstream like doing the updates that are happening upstream and merging them back into your repository because you're not having conflicts between those those implementations whereas this is going to be a new transaction type you're going to as a maintainer of a downstream project from an L1 client you're going to run into a lot more like rebasing issues as you are developing your feature and then trying to get the Upstream changes that are happening uh it's just very different than than a

pre-compile right so let's uh so let's hear some layer TOS what are what's your think right yeah I mean I think like CL already kind of said it but I mean the two main I mean the I think probably the two biggest considerations in terms of making changes one is yeah one is difficulty of upstreaming and how much it's likely to create merge conflicts just in that like staying with Upstream is is important for all sorts of reasons um the other is um overall the yeah the level well there's you know level of likelihood that sort of it will actually eventually get in um is certainly kind of the the other um and God I had another point but it's slipping my mind so I'll probably

pick come back in with it in a second we have a variety of deviations already oh sorry I remembered um the other and this has like bitten us a little bit before um is implic is I think the the biggest risk for for rollups that are kind of directly building off of gu that are making modifications is implicit assumptions in the GU code base um that might change and silently cause issues um which has happened before and like with this sort of stuff that's like pretty deeply messing with the system um seems risky since doing those merges is is high Precision um so yeah it doable and it's a very valuable thing to implement so it's certainly something we'd be quite interested in but also

like pretty scary H yeah I just wonder you say that I think that's another good example of basically I don't know how right now we are still in a situation how where all the the tooling and uh the compilers the clients everything still natively targets layer one when of course over time layer 2 is where most of the continued iteration and most of the use activity will be um I think espe specifically like a big part of the motivation of of this standards process is to basically create some sort of Common Core of more advanced evm features and so those will NE necessarily over time diverge more and

more from layer 1 evm the idea is not just I think to just physically have just have eips that are going to go to mainnet anyway just like five months earlier for for for layer twos I mean that that then I feel like having an entire process for this just wouldn't be worth it so I think the the idea really has to be to have like a more advanced Common Core that over time we include features like I don't know transaction parallelization State expiry all these kind of things that that make sense for the evm but we might not ever want to bring to layer one just for Simplicity and so I think we'll have to figure a lot of these questions out in general like what does clearly the the right choice here is not to have every single two team maintain a separate

implementation on top of gu or something from of the same feature that that that that everyone supports in in the exact same way so so there would have to be some sort of standardization either with like ler two specific client teams emerging over time or some I don't know maybe there could be some sort of Common Core patch that is collaboratively worked on or something but I feel like this is it's not a trivial challenge but it feels like this is something we have to figure out anyway if this IP Pro is is is going is supposed to be to to go to meaningful places yeah I mean what what how do l2s and people feel about figuring that out sooner rather than later because I just imagine that we're going to come up with

these ideas and you're going to have people going off building projects around different amounts of changes that would happen to L L1 clients but we haven't really figured out how to deal with the situation that the reality is a lot of L1 teams will not support things that are going to pretty complicated so the R1 curve that's something that I think that we could probably support like relatively easily with a configuration flag just because there's very little overlap with our system and it doesn't really require much like maintenance and we don't have to work around it much but adding a new transaction type is something that is kind of painful for us to do because we have so many different places where we have to deal with all the different

transaction types and so it's not something that I see that we would be doing if it's not supported on L1 and so we're sort of talking that there needs to be another client sitting between the L1 maintainers and the consumers of these like L2 teams so it it feels like we need to have this discussion sooner than later to figure out how we're going to do it and if we're not going to do it then like what are the what is the uh you know what can we do if that's the actual reality yeah I think that like yeah two two things here that come to mind one like I personally I'd definitely be in favor of the idea of kind of like a a common core sort of fork of gu that like is actively contributed to Across the

various um well whoever's consuming it and kind of implements core rips um would definitely be happy to contribute there um the other would be it'll be interesting to think about and this would be interesting in terms of a question on the gu side as to sort of willingness of accepting Upstream um changes that make M make that add essentially abstraction in the interest of making it easier to maintain that fork um I could imagine a variety of things that we could try to basically like not insert the complexity into gu but insert various hooks into gu kind of for the purpose of being built on by

that other implementation so that's kind of you know level of Buy in there like I'm completely on board with the idea of like the GU team can't be responsible for maintaining like everything for every you know all the like that makes total sense but like if essentially it's of enough interest that it would motivate sort of incorporating changes that are low enough on maintenance to sort of make life easier for um for the kind of core Fork right and I mean I don't want to speak for the whole team I'm personally like much farther on that spectrum of being supportive of adding abstractions that make it easy iier adding reasonable obstructs that make it easier for L2 teams to interact with uh this software and we sort of did this for we have this

1559 configuration now in our chain config that was proposed by Proto last last year and and it took a while for us to as a team agree upon that and and get it through even though it was a simple change just because we had to overcome this exact thing that you're talking about like do we want to add an abstraction that makes our lives slightly harder but it makes the L2 two lives easier and we did end up accepting it so I think that the appetite is there it's just always going to be like a delicate balance of how much complexity does this abstraction add because at the end of the day we're just very focused on shipping a very safe client for L1 and I think like most core teams are pretty focused on that and it's going to be yeah it's going to just be a dance

with figuring out how to do this in the right way but having a team that sits in between us and L2 that is focused on maintaining that core client um that is implementing rips I think this is a good idea and I I would really like us to spend some time figure out like how how can we make this a reality okay definitely some interesting things to think about there in terms of uh how we can manage sort of Divergence um in in in sensible ways um

taian has a good comment in the chat that's worth I think take a look at too in terms of Lessons Learned and uh changes made a scroll onar yeah I just wanted to say that um um as Matt said I think for now before we but while we still in the proc of figuring this out of course there are changes that are like small where this might still be feasible to to have say G support especially if there's at least a good likelihood that they'll also had two layer one reasonably soon so like the R1 pre-compile um and then there are changes like kind of in shine 437 um which probably like it feels like it would be more important for us to basically have figured out this more fundamental approach here before before um it it would actually be feasible to

ship them to Layer Two so so i' just be curious obviously this this will take some time to figure this out and Set set set the process for this up um like maybe maybe question to the 437 team um what kind of timeline are you kind of right now thinking about roughly of course I mean t is always hard question but but for for for for this kind of the in trining 437 um what do you think is kind of realistic here and do you think that this basically will be the main Blocker in terms of timeline so we don't have a timeline for the uh enshrine the version yet we're still we're still working on it uh we only we recently published published this rip and asking for asking for

comments and we've been collaborating with several with several layer tools on on some changes that are needed there and some so it's not uh it's not close to being H to being finalized but at the same time uh so at the same time we are working on a we are working on a g on a g patch that implements it and we're trying to make it as modular as possible so that it can be easily detached and doesn't have doesn't have too many conflicts I think that's uh that's that's important but uh as for the As for the timeline for as for the timeline for a for doing this we are very much dependent on lay on layer tools we're

going to see which of the U which of the layer tools that are looking into it would like to uh would like to speak up for start as a a test net in order to in order to experiment with it so the time so the timeline for experimenting with this is uh more is less up to us and more up to uh to the layer tools that are interested in it okay um thanks you uh light L you still want to touch on 3074 in the context of I can I don't

know if anyone else is on the call who wanted to to mention it because otherwise I'll just I can say uh just something uh something to keep in mind since since we are discussing both uh both the full account obstruction rip and 374 it's important to it's important to keep in mind these are not mutually exclusive despite some memes going on Twitter so these are not H there are not proposals that try to solve the same the same thing no need to go into a full comparison here but um I'm going to I'm

going to post something about it but uh keep in mind that these are not mutually exclusive or try to solve the same problem yeah that's uh that's definitely true and I think a lot of the a lot of the problem here I think stems from the misunderstanding of exactly what a counts abstraction is it's become a very diluted term that sort of just means more functional accounts but really like the origin of the term came from this idea of abstracting the way that you authorize things to happen from your

account and it just so happens at a byproduct of that is that it allows us to do neat new things like batching transactions and having social recovery having spending Keys those types of things and so 3074 is is really not an account abstraction proposal even though it's like lumped in with that group of ideas um because it looks and feels like account like the other account sub ruction of proposals that exist which have the features just because they're allowing smart contract wallets to do things so 374 is really focused on giving EA's smart contract wallet like functionality and there's a long history about how 3074 came about and how it's

kind of evolved over over the time and we don't have to get into it on this call but I have been talking with a handful of different L2 teams and and developers people who are interested in 30 having a renew renewed interest in 3074 uh who want to experiment with different ways of creating um account abstraction like Frameworks and building systems that are really inexpensive for users to onboard to and use that are you know effortless to interact with and so they have said that it's something they would like to

ship on on their l2s but they want uh they want Buy in from the RP process I don't know if any of those people are here who want to say that their project is pretty supportive maybe they could chime in but I would yeah just ask like how can we like move forward with an EIP proposal if that is kind of the case that it is supported by the RP folks alar yeah just wanted to briefly say that I'm I think in more as a general comment that like NE I think it's important for the IP process to basically that we don't we should not make the distinction too much

between like say like supported by the IP process doesn't isn't necessarily I think a meaningful distinction I think we should be open to standardizing whatever people like some subset of of robs are interested in so for example I mean I'm I'm one of the cors as well of 3074 I'm personally somewhat skeptic that now is still a good time to ship it but I think think it's a perfectly fine candidate to turn into an IP um and then just see you know like to what extent ler to's um there could be some subset still want to ship it or something or maybe everyone or maybe no one or something but I I don't think basically we we should not turn the the roll call the IP process too much into a blessed by layer twos I mean I think it makes sense to have some sort of temperature

check you know as part of the the process because why not but but I think basically like there should not be a Blocker of start of of adding an rip that it needs to get like Broad C by by different people so I think definitely 3074 it's going to be the same question it's already an EIP so how do we convert it into an iip um so we just need maybe a standardized process for this but other than that I think it's a perfectly good IP candidate yeah I mean I think we should hear from the L2 teams how they feel about that specifically because I don't know if that's how they're feeling that subsets of people are going to adopt things but uh Paul raised his hand hey yeah hi um yeah sorry without

elaborating too much I would say that polygon is very seriously considering 3074 um potentially as early as early next year and I would say that just kind of also it gets into this this question about what the you know the the way that we we approach certain things and there's definitely two two Le at least two different tracks right there's there's areas where we're trying to come to consensus on standardizing implementation across as many rups as possible then possibly with the target of um of of getting to L1 basically and so the the secp R1 kind of built-ins basically are a good example of that 3074 may be an area where you know it's

an opt-in type thing for the rollups and then the main goal basically is just to maybe for one thing not step on each other and then also um if we are going to implement something across several rollups but not all then you know to the best to the best we can manage it basically I mean not to the best we should manage it should be it should be compliant basically it should be a standard so that you know that there's consistency across rollups about how things behave as well so that's kind of it's that's an interesting aspect of 3074 which like I said some rollups may choose to implement some may not but the rollups that do should be consistent obviously thanks Paul Harry hey I don't no no particular

comment on 3074 I just wanted to kind of ask and confirm so the rip process is is opt in by by um in terms of kind of rollups kind of adopting any particular RP which makes total sense are we I'm assuming but I wanted to check are are I'm assuming RPS need to be entirely consistent with each other like it needs to be technically possible to adopt all RPS that you can't have actual conflicting ones that would be sort of my only concern here if there isn't sort of enough buyin would be like is there going to be some is there going to be some other standard that comes along and it doesn't make sense to do both andar yeah I don't I don't think this is

this is a really good question but I I personally don't think this something we can guarantee just con conceptually like there's some specific invariants or guarantees that we can make like for example I think it's good that we would guarantee that there's never a conflict on a specific pre-compile address or ideally even though of course we have smaller range there on op codes or or transaction types or something um but then in terms of just being able to have like a completely modular field where basically we we could guarantee that there's never two IPS that are mutually exclusive I don't think just conceptually because because that that do something that a standards process uh could could enforce because they can always be just say two

different flavors of something that's clearly competing that each supported by by a few rollups and then the IP process should definitely be able to to be still a standard standardizing forum for for those competing standards any other teams thinking of supporting 3074 okay um yeah not a not a rollup team uh

necessarily but like I just want to represent that there's significant interest on the application developer side I think J Wong isn't here but he's super super interested in it for estaria and then um I'm hacking on some new projects right now and definitely would be interested in it as a primitive for ux improvements as an application developer cool yeah thanks for trying in I guess that's pretty much all for 3074 I I'm wondering you know more generically how teams feel about rips being accepted by a subset of

rollups I mean it's going to be almost impossible to get every role to do everything that everybody wants to do but part of the point of the process is to standardize and agree upon implementations and you know you could imagine this world we've been pretty focused on evm equivalence you could have imagine we have an L2 evm standard and every rollup supports the L2 evm standard and we're kind of saying that we're not going to go 100% that direction we're going to go to a place where you know some rollup support some of the RPS and I just want to confirm that that's also how L2 teams feel about it or are you still thinking that everybody needs to kind of be supporting

everything because we want to have L2 evm equivalents so I think the important Point here is that like one is a subset of the other um if if it emerges that people would like to have a L2 evm standard and that is something that is worked on we can maintain L2 evm well to clients around that um I think that's all great um and is is definitely an outcome that I think would be really cool to see um whether we can get there I think is a a different matter and very much depends on uh L2 teams appetite for that it certainly seems like having kind

of a common core Upstream repo that Implement stuff definitely like makes it a lot more likely that that that things will get widely adopted um which certainly seems like a a good goal like not something the process can like enforce but certainly something that we can work towards yeah I mean just to pick on 3074 because I've talked to some teams about it and you know we on the call partially because they were interested in getting some feedback about how other teams felt about this proposal like hypothetically let's imagine the polygon and optimism you know want to ship 3074 like is that enough of a quorum for for you guys to

ship 3074 and then the teams who are like kind of lukewarm about shipping and you know this is just an arbitrary APAP you can do this with the R1 curve or whatever else um are the other teams like do you feel like that means you need to implement it like because two other large rollups have said they want to uh how are you guys thinking about that I think there'd be a strong argument for it um I don't because I don't think we have anything against it I think it's just sort of not like that much on the top of our radar but like to the degree that it's like a thing that has momentum for it and like could be common tooling that could Target it and work on all um that would certainly be

really nice um yeah I mean I think it's a lot of it is sort of like you know there's a relatively similar issue to like the L1 EIP process of just sort of like mental bandwidth towards like pushing changes but to the degree that there's kind of momentum um I don't think we're certainly not like against it in any way um I'm I'm also just asking like more maybe more generally like imagine you know arbitrum and polygon you guys have some arbitrary EAP that you're interested in accepting uh if you were the only two rollups that were supportive of the thing and the other rups were like you know for whatever reason though they don't aren't that interested in it or it's just not top of mind for them they can't do it

right now maybe maybe one day in the future would you still feel comfortable moving forward uh even though it's just you and and one other rollup doing the thing depends on how breaking it is to the overall experience um like there are some sorts of changes that are that are kind of like value ad but don't create incompatibilities except for people who are opting into that feature and I don't think there's any concerned about that like a simple example of there is like a precompile um like I don't think we're too worried about that I think much more worrying would be anything that sort of fundamentally messed with an invariant that like caused you to sort of create subtle incompatibilities that weren't based on kind of clear opt in from

developers maybe something like 1153 would be harder for a small section of rollups to ship yeah I guess I'd have to say the precise answer is it depends as I mean it it really is probably very specific at least until we probably get more experience in kind of chewing our way through some of these proposals and trying to figure out how to sort them um actually I think another another good example might be like actually here yeah another good example is probably like um and very apt example is like account abstraction changes that break the TX stock the message. sender equals tx.

origin assumption um which is like not a good assumption that people should be making um but you know is a thing that's kind of in normal code um so I think that's actually a prime example of like wouldn't want to break that unless you know there was a good number of people breaking that well because it seems to have broad sorry go ahead I'm sorry oh yeah no no no problem you were talking about like not wanting to break break invariance it sounds like you're talking about invariance at this smart contract layer like code already deployed on chain not breaking it but you're not necessarily talking about invariance at the client layer like yeah no I'm I'm thinking primarily

invariance that like a developer comes along and deploys a piece of code that they expect to function the same on all chains um and I wouldn't want to have arbitrum have a deviation that caused their code to execute differently um which yeah I think kind of tx. origin message. sender assumptions is probably a good example of a place where you wouldn't want to have kind of very different assumptions on one chain that a developer is expecting D you've had your hand up for a while yeah I would say um as an evm developer the type of fragmentation that scares me more is op code fragmentation as opposed to pre-compiled fragmentation um because the pre-compile space is much

larger it's easier to handle pre-compile that's there are not there in your code um but if there's op codes that have different meanings on different chains that's going to have tool chain implication um if there's op codes that are there and that are not there that's also going to have tool chain applications um push zero um who here is living this nightmare um that is something that um some people support some people don't is not something that I think is positive so um I'm wondering if maybe um features that may be supported by a subset um that a solution that involves using pre- compiles instead of op codes is explored um for example adding new block um metadata could be queried through a pre-compile um i' be interested to see if o and off call

could be implemented through pair promiles and that would be a lot more um tolerant to fragmentation across the chains if some support it and some don't thanks Deno anal yeah I just wanted to say that I think this is going to be a very important conversation that we we have to have anyway going forward I think because for history kind kind of context I think initially the idea for roll call coming out of last year was to to to start really with something that looked much more kind of um governance like to have it have a proper layer 2 evm that FS off from layer one evm and and really does everything in Center Way and try to

get all the layer twos to to opt into that kind of in in it in in its hole but talking to to to teams it really seems Seems like there's this limited interest in basically having giving up sovereignty over the the virtual machine to some kind of um Consortium uh process so so I think kind of the the really the only way to make progress here is this more opt-in um approach and I think still think that any feature that's supported by two or three chains identically rather than everyone just doing their own slightly different thing is still a win even though it's even if it's not opted in by like everyone um and I I do think though that there's still a lot of value in trying to then beyond that figure like find things like

some sort of Common Core the question would be would Common Core only be the all the changes that are supported by literally everyone or is it more that the changes that are like supported by the majority and so that it's still worth to have that all implemented in one client but it's still activated by Flags or something but of course if it's not supported by everyone then you can't really have tool Ling targeted because if you if you you know so couldn't just say hey you compile to layer two common core because then it's still not going that everyone supports this so there might be might be value in having like a minimal common coin St that's those featur just literally supported by all the leros um obviously you I think it's very early there isn't really a good answer right now but I do think that

this is going to be very very important moving forward otherwise there's yeah very limited use in a lot of these features if if they're not actually properly supported by the by the tool chain yep very relevant points um yeah thanks ancar uh moving on just cuz we're running short on time um it's the has been discussed on the uh1 calls ACD calls recently um Denon timelines um and and testing of um all the the the the test Nets there so um the uh 4844 should go live on gly um early next year um probably

February to understanding January February uh followed by uh sapoia and hsky so if you are an al2 um like and you haven't been testing um your deploying blobs on 444 I highly recommend targeting these test Nets um particularly the Gorly one as um uh gorle is going to be the candidate for sort of changing um the sizes of um what these blobs look like potentially so yes please please look at testing into these things um and so because those impacts timelines for for

when main net can ship these things um one yeah one concern we have with goalie is uh acquiring a goalie if um it's quite difficult these days so is there some kind of way for Layer Two to acquire some for testing um that is the uh the big issue with gy um I can I can look into uh look into if there is any spare Gorly going around um especially uh for those who don't know gorley will be uh deprecated after this Denon Fork so there's no point in hoarding anymore um so I I will ask and get back to you um

if you do need gly eth for testing please ping me um and I can I can see if I can I can help out there so I think those are the major topics um one last thing is the call for uh rip editors um if you are interested in this um I think it's important to buy in from from many teams so please reach out to me if you're interested in becoming an RP editor um I think it's important that we have lots of representation and I think that's that's pretty much a wrap so thanks everyone for joining this roll call the next one will be uh the second week of

January and uh of course you'll all chat async uh before then and uh yeah see you all then should be able to find these recordings on YouTube if you've missed anything but it's uh it's been great thanks everyone thank you thank you thanks