RollCall #2.3 Breakout: Precompiles

Transcript

um so the idea is that uh today uh the topic will be pre compiles in the kind of context of of ips um and um a little bit more General beyond that um kind of using that as because the first IP that we have brought to fanation of course 7212 um introduces in new pre-compile so talking a little bit bit about the process as well for finalized IPS to make it L to how to track that um maybe what pain points are there still um does it even the the whole idea was that um the IP process with standardization

should give lats more confidence that implementing um these these features um is this is D risk basically checking in is that so far does it feel like we on track with that all these kind of topics so um to get going basically with the agenda I just wanted to very briefly kind of summarize where we are at um so far so um basically um uh we for now just copied the um the way eaps work in terms of the different um statuses that they they can be in so basically the the final status that the last status that that an IP um reaches is is

finalized um the idea there being that um at that time um there are no further changes to the to the IP uh allowed and that that should give teams then confidence that if they Implement um that feature exactly by the spec then uh all all teams Implement doing that will will inter the exact same same same version of course um we we have the the as I saying 712 7 to2 is the the only IP in final um for now um and then in in terms of pre part specifically um uh you might remember we we were talking with um CFS on mainnet um with regards to how they think about

kind of avoiding collisions in terms of pre-compile addresses also making sure that if they ever want to chip a um IP pre-compile as well um that that kind of is done in a good way and the consensus there was that we we were handed a separate pre- compile range so at basically address is 256 and up um and that main it wants to basically wait with talking about reusing um IP pre- compile addresses until they are ready to ship the first IP pre compiler themselves which also very plausibly could be 7 to2 so that's kind of where we at um currently with with with pre

compiles um and then of course there are a few interesting questions we can get into in in this call but I thought it would might be might be a good idea to start by having someone from the fa team from the from the 7 to 12 authors briefly kind of summarize um basically what what what has happened um since finalization so sure thanks for thanks for the intro I guess for now there are three rollups that are committed to to implement the rip and they also started implementation in their code base the first one was was the polygon site they requested a

polygon Improvement proposal and we have prepared it it's pip 207 then we have discussed it in a few of the community calls then they have included The Proposal in their next hard Fork it's nopo hard Fork I guess the test net release was this week and the main net release should be the following weeks and the next one is the casing they are ready in the implementation of the pre-compile and its circuits but it's waiting the next VM VM upgrades and they

say that it's might be in the this April and the circuits and all requirements for the pre-compile is is done but we are waiting the next VM upgrade in their side and also the optimism team started their implementation in their codebase there's a draft PR in in the code base I think it's it's also ready and scheduled for one of the next hard for it's I guess fed hard Fork I hope I'm not miss missing any of the rollups and I have seen that the Elmos has done an implementation in the cosmos

site okay yeah thank you um I I guess it also brings us out for now this time I only have a few kind of parts that that I prepared on the open section on the open questions section then we can go to open discussion but one of those specifically I think fits very well here and that's kind of the question of how to um keep track of um implementation status in l2's once once an IP reaches P of course the question is how congr do we want to be there I don't think it makes sense to necessarily distinguish between interest and then um commitment and uh and but like at some point

basically we have to we have to indicate okay this is about to be shipped and then this is this is now live um on on a specific at and Carl I think we talked about this briefly could you could you briefly kind of summarize kind of our our thinking so far and and and kind of the the idea for for tracking we had yeah I mean basically it would be nice as a um a developer who's wanting to uh like deploy a contract to multiple Alters to be able to have a single place so they can know whether they can use a feature um and have like bit oversight if they should ship something that

supports a pre-compile or not or that kind of thing um and so the idea is that as a part of the uh rip repo we can also have the uh a small Reg industry which basically only contains finalized RPS and when they are finalized that um we can show uh who has implemented what uh exactly what's in there and how that is formatted is still something that's that's kind of open uh currently I just have a little Json file but it's very empty because there's one rip and uh no no no one has shipped it to main net yet um and so the the the St that is not

super helpful um but uh as uh um usas was pointing out we already have many implementations of this um and I see in the chat there's some more uh so it would be nice to have insight into that uh with with reasonable ease and so that's that's hopefully what this will be um and then uh as as it gets shipped from all two sites everyone's welcome to just make PRS to add themselves to this this registry of he we've shipped it uh but again it's only if you have like exactly implemented set rip as per the uh the specs awesome um you you said you

already created that file is already in the repo so we could pry link it or if there a or something uh Link in I'll drop the link in the chat um it's it's a branch I'll open the pr today um but uh for people to take a look and and see absolutely yeah how that look like awesome I have a I have a question yes how should be the decision of which chains or rollups should be included in this registry H uh I mean I think that's going to be one of the most difficult questions of uh the the the the whole roll call and rips process in general um

the idea is basically if um if you're in the greater ecosystem and it you're like vaguely look like a rollup then I think the answer is going to be going to include you so sort of default inclusion as exclusion um and for some things where um I mean even if for example rip start getting shipped on other evm chains not necessarily l2s I would even consider including that in there um so yeah in general just default inclusion as as opposed to exclusion uh up to the point where it starts becoming too noisy to interpret the the the point of this

process is not to like Define who is and isn't a rollup / L2 but more just to be a useful resource right and one one question that I would have maybe briefly on this point um or not the point of who's in here that that may don't want to talk about but um in terms of tracking um which L2 have shipped this of course on the E side we have like this somewhat fine grain the difference between draft and then review and final call before we get to final so is there any use like what people here

think that that would basically be used to for tracking starting to track basically as l2s start to either consider um um shipping in in in IP or like say once they have made that decision but are still in the in the process of of implementing it and bringing it um to the2 so said two Pine gr and we and basically it only makes sense to to track once once it goes live my personal stance on this is that it's too fine grained um just that there's a lot of status changes and many different levels of staging and I think

it becomes something that would need to be policed uh a lot more or just have a bunch of attention paid to it whereas if it's just like is this on Main net I think that's much easier I guess one exception like the the the weaker formulas would be like is it on a test net then we can include test Nets there's a separate a separate thing which I would be open to um I guess the question becomes who's who we trying to serve with us um because I feel like test Nets are mostly used internal to um all the various rups as opposed to main which are external but maybe I'm mistaken in that yep sounds reasonable we have a

question in chat um is asking um but this something equivalent to to the kind of the test test read that we have for for main at evm for kind of for this iip um so of course this is the first time we kind of have some standardization around the feature that's not equivalent to to what we do on mainnet so I personally haven't haven't kind of thought about this much yet and um I think that's a really good question question and I don't know I see we have par on the call of course on the devite I don't know is there how close are you to to testing could you briefly talk about maybe

what um what it would take for for features like that I mean I don't know I don't want to put you on the spot but if there's if you have thoughts on this maybe yeah could you just repeat the question one more time sorry of course so it's basically the question from chat so um of course we have e we have ethereum tests for for eips and for for changes to the Manet evm um how how open would that be to basically adding um as as the conical place to also have IP test is it something that your inition would be that we would need our own testing Suite um for for non main net for IPs

basically um I'm not sure if we should add it in the same place but definitely could probably Fork the repo and um Implement whatever that needs to be done in the fork I think that's probably an easier way to go especially I haven't gotten deep into the L2 world yet um do you is most of the testing happening with just are we talking about the spec tests or Hive or um test Nets or which layer of testing are we talking about and you maybe last if you um you wrote

the comment if you have some perspective on kind of how you on two side think about testing or um I'm not sure is just as like rollups um maintain compatibility with add new features and like eagerly Implement new eips I wonder what's the best way to validate that everyone has a like consistent implementation I would imagine that I mean it it would sound reasonable to like add this test in The Ether test repo under like a specific folder such as I don't know rollups or prospective e um mainly because all the logic for

like has been implemented like the runner and so on and they they do extensive precompile tests um main also because I don't know how we would do it otherwise I mean the fork sounds reasonable but then we have to rebase every time um but I guess it's a implementation detail um I think there' be like one or two things so the first one would be generating the tests themselves um I think the test execution tool in question would then be retest and I guess for that one um it does make sense to to probably for that and support it um the higher level test part

is Hive which usually takes an uh an expected input expected output and then asserts what's going on um and I think that would also probably make sense as a fork because then you can add the definitions for all the layer Tools in there and any change in the definitions of um an El in the L1 wouldn't affect you guys so it probably does make sense to like you said it's an implementation detail but I think most of the infrastructure is built such that you can Fork it and probably continue supporting the same thing but for rollups that sounds that sounds reasonable but for example for K we don't use a RS tests I I don't know how to pronounce it the runner for the eest

we have a custom Runner but we still use all the Json and all the as you said the pre-state and postate assertions so even this kind of stand standardization is somewhat has has a mean differ say I would recommend um not using retest death and using either that custom format or looking at the um the execution test specs uh so that the the real output is the the test file not necessarily the fillers um and that's just because from core JBS we're

looking at trying to get rid of retest death and just use the execution tests so retest death might not get maintained much longer how about just how about just then the the like EXE the execution test the the Json files that have the pre and post as I mean that's ultimately what test harnesses will consume so however we get there is fine you could have a custom program that outputs it as long as it's repeatable and verifiable and if we're doing something like verifying um not just the layout of like a pre-compiled call but the actual math behind it backing those tests by an implementation that is the quote unquote reference implementation would be great and we could use like if it's in python

or C or whatever to generate test vectors from that that I think would be would be fine I don't think we need to ESS with creating retest death quality fillers as long as we have some way to regenerate them and can verify what each step means definitely think um having Mario and one of these SPS probably help there um because he's also looking at how to best move away from retest eth and where execution spec test Etc fits in perfectly um and additionally he's been thinking of how to set up this whole workflow for verle tests where they are quite a few things that are drastically different from how things happen right now and probably inheriting that same

logic for RPS would make sense yeah uh on the last call there was like a discussion about fees and so I was just wondering what if different rollups when they implemented certain R for instance this one like of a pre compile they have different costs for it will that still be considered as supported precompile or not and if it will be then I'm not exactly sure whether e test will work because if I recall correctly though I've never worked closely with them I think they would require fully and behavior to work correctly right so for now um this

actually really good question um but but but for now um we still basically do the The Lazy thing where the iip fully specifies all Behavior including the exact gas pricing um and so if if L2 would be uncomfortable with that gas pricing then that would technically not count as shipping the same IP and then I think it would be a really good conversation to have like what what do we do in these cases technically kind of the the if if if if there was any other type of behavior change what we would recommend is just shipping it at a different address because it's a slightly different um a slightly different pre compile of course pricing that's what we

talked about last call in principle we would want to get to a world where you could have the same features in this different pricing we just we just don't have a system for that yet and so if there's another two right now for example that does consider doing that with with L1 then I think that would be an interesting conversation to have whether to still ship that at the same address or not and then how to keep track of that that is a modified version but in in in in in general with maybe the exception of gas pricing the idea would be that modified version should be shipped at different addresses because um yeah because they're not not not quite identical I think maybe maybe a way to solve this is if the rip for each precompile specifies the ma specifies the maximum cost the one that is that

would be that no one would be charging more and then others can H can have have a refund mechanism at the end of the transaction just like when refunding on other things and this way the code is not disrupted by the different pricing but they can still make it cheaper on their roll up if they if they're able to sustain it and how would we sorry sorry how would we pick the max price yeah that's this has to be uh this has to be agreed by everyone that no one no one thinks that it needs to be that it needs to be more expensive in order

to be sustainable on their chain and then other chains that can make it cheaper can just H can just have a post transaction refund I don't just uh it's not ideal but it's not ideal but uh we should be able to reach where like a certain price that no one thinks that would it it should cost more wouldn't it be possible okay I mean no no one would no one would say that it has to be more expensive than I'm taking to extreme no one would say that it's more expensive than an evm implementation of the same functionality right um I think like some zks would want it for example like if kak were

pre-compiled it absolutely want oh right yes okay yes so you're right maybe so maybe refund is not sufficient uh not sufficient here so we a separate address like a different address for this but it kind of negates the value of having an rip to begin with so I'd like to add two points to this first um we've changed the price of pre-compile on mainnet before mod XP has had two different versions and it's even got issues depending upon how you implement it whether or not how you handle your mod your even modulus is um but I think that's a second get a second issue in that I I think we should seriously consider mechanisms to

disconnect the gas schedule from the evm execution and that would include pre-compiled because with zks for example um there might be systems there might be EVMS that are more efficient on some operations some that are less efficient they might want to distinguish themselves by gas schedule and as we've learned um in the past when we had to manipulate the gas schedule for things like storage it's broken contracts before and it's already a recommendation among Auditors never to depend on um specific gas costs so I I really think we should get in a direction where the gas cost is separated from the actual execution of the of the precompile yeah I

think right right I'm not sure any were you on on last week's call when we talked about feem markets um I had another call that I couldn't make at the same time um but no worries um yeah yeah so basically we also talked a little about that and indeed kind of I also brought up um EF as as of course a way to to remove gas observability and then um especially say I could in the future imagine that there might be L tools that are that only support youf mandatory um and and and in that world would be much easier to then indeed kind of um disconnect the the specific gas schedule from from the evm implementation um and yes and that that was that was that was

mentioned as as one that was desirable um outcome i al separately like my take away from last week's call was that this is for most teams this is lower priority even on the ZK side people while be a little grumbling about different kind of efficiencies of different different pre comps and whatnot for now are fine with making it work and the more principled approach in general for for specifically for say ZK proving would would be to to basically introduce a way to just have have kind of like a a multi-dimensional fee Market that could basically give um give pre comps an extra kind of Prov gas cost or something U but in either of these cases basically whether we do the

very simple just agree on a maximum whether we have remove gas observability and we uh we we basically get to a world where you can just do more free repricing in general or we do like multidimensional pricing or a mix of those and none of those are basically in a point right now where where they can be shipped right and so basically if we if we talk about say where where are we at with R1 we compile and whatnot the idea is basically for now in within the standardization process we would have to stick with exactly agreed upon fees and then this is this is basically something to follow up on now as a research process of um how do we then um move to a better and more principles world that that allows more freedom for for for all that that

incur different costs um yes so so so so that's kind of like take I think one of the takeaways here that that's that that needs active research um and then to to follow up on the conversational testing side as well um this similar situation I just wasn't aware like like I kind of testing was not on my on my radar for as a topic for today and otherwise we could have invited some testing people as well um but I think this is a really important topic that we should definitely follow up on um on on a future breakout call maybe um and in particular I think it is a question that will become more relevant as we have more iips that that reach

final and as we have this distinction like the R1 pre- compile we might bring to mainnet so I would over time expect it to be implemented in all the mainnet evm clients and then over time also just be part of them even the main testing suite and everything but there might well be IPS in the future that just never get support in the Upstream clients themselves and what not so I think basically testing is is a part of a broader question around how do we think about support in all the levels of the of the stack right and all the different tooling the different clients testing everywhere like how do we kind of maintain proper um standardized support across all of these if they if they're no longer just we don't get them for free because all the maina tooling

just implements that by default so I think that that's something question that that deserves its own breakout call and so so yeah it was good to see that come up as well do we have anything further on that kind of General set of topics that that that might make sense to talk about now I just had one question about BF because we mentioned it as probably not this magic solution but a good solution to remove from like the applicative layer and I wonder if anyone here that we know has like started implementing it for rollups and like what it would look

like um because as I understand what you mentioned e would remove the need to standardize gas cost between OLS like for eips or just in general gas pricing but maybe I misunderstood this from last call so eof um is a candidate for Pro um the Q3 Q4 release they haven't finalized scope it might be out it might be in I'm pushing for to be in um basu's got um we're working on Final implementation of it um but when gu gets an implementation a lot of the rollups are gu derivatives so it's just going to be an issue of just updating the code and it works parallel with the other EVMS it's actually just a container

format for the evm it's still the same underneath it so for rollups to get it they would just need to update the get code or do significant changes to the get code to bring it in early um but I don't I'm not aware that any implementations have seriously gone down the path of multiple schedules between the two so a lot of gas schedule Divergence just hasn't happened yet as I understand it it's like not ritual compatible right or like it removes a lot of like it removes the gas introspection from the the code now from the so um the container itself so it's the evm would run both Legacy or eof you could probably configure it to say only

eof is accepted but as far as code that is tagged as eof you don't have access to the op codes that would allow you to do introspection for gas or allow you to do introspection for code um now the Legacy stuff that you could call into could also do that just not through delegate um so in a way you could say that eof um it's not backwards compatible to do those if you're going to go forward with eof and the only way a chain won't be able to do those is if the chain is entirely eof otherwise you could call into a legacy contract and do gas inpection and um your code introspection in the Legacy code so it's kind of like you know ring zero ring one stuff in Intel probably a better way to

think about it okay okay because because kak is still not in testet but probably M that is like within a year it would make sense to directly leave frog to e then but then kind of like alone in this state of e only chain I'm a huge advocate of e only chains I have dreams about that that would be good right yes there's a long list of things I think would be awesome okay of course just to mention that right like because I agree that in on from the for the researchers right and from from from from from that point of view it would be amazing to see that for

the chain themselves you do have to take into account that if you were to launch as UF only and this is already assuming we we ship it to mayet so that in general it's broadly supported if if we don't end up shipping in tomain it then I think it will be more of an opinionated decision anyway because then you have to kind of yeah you'll have to rely on on somewhat less broad support in the ecosystem and but even even in the case of that it already went live on mainnet uh launching UF only means that a lot of projects that have already written their contracts um not using UF um would have to actively um move move on to new versions using EF before they could be deployed so it's not it is it is very opinionative choice and I agree

I would also love to see this but I just want to flag it because um otherwise you might run to issues down the road um and just to very briefly clarify how does this relate to changes D you already mentioned that of course the the point is that even if you are on a chain that has um both UF and Legacy um code that that can do gas introspection or even if you're on a chain that does not CHP UF at all and you only have Legacy code and so all code can do gas inpection the point is not that moving away from the main at gas schedule necessarily break like is impossible or breaks anything if if if we are in that world it is just that contracts might have been written

in a way inadvertently violating best practices of not relying on on gas pricing that now breaks right so basically if you have gas interection as something you can use it's just much easier to inadvertently write code that relies on specific relative gas prices being a specific way um that then break and so it's much harder to reason about will anything on out on on the Chain Break as we move to different gas schedule or even will just Legacy contacts that want to be deployed and that are not yet deployed um be broken and and so so basically the idea is more with UF in the long run once we are in a world where most contracts are UF contracts independent of whether or not these chains still support Legacy the

risk of systems breaking gets goes further and further down over time as most contracts basically are just by their design not possible to to to be vulnerable to this if that makes sense I think it makes sense especially if e Dominion is like years away but then I think it means RPS could have gas cost like up to implementers like rollups or as you have mentioned the this idea of refund which I'm not sure if if someone refuted it or not but we could just have RPS have like no gas in the specification is

that what you mentioned well basically what I'm saying is there for now just because we already have an IP so we have to kind of ship this now some somehow I think for now it makes sense to stick with the default rule of everything has to be specified including gas pricing so for now we have a specific gas price for the one pre compile if you want to support this pre compile you have to use that specific gas price um otherwise you can you can still chip it modified but then ideally and different address um but it is definitely something I think that we should just look into whether like to what extent we can have flexibility there in the future and and in what in what form but I think it's important to make the distinction between what you do

right now if you want to ship something right now and what is more of a research question um for the IP process yeah I just wanted to say that maybe like one of the other options is okay so what we're now like basically discussing is is whether or not to consider rollup supporting an RP maybe it's like the same as with evm it's not like like black and white we can besides just saying like in repo where we we say okay this RP supported by this and that rup besides the name of the rollup we can say type of support just reuse the same type system which V used for different kvms and say okay if

if it supports absolutely the same interface but it has different gas cost then we call it like type three or type four support like don't remember the number but you you get the idea maybe that would be a better approach yeah I personally would be hesitant to basically do this now I think because it's harder once once you would do something like that to move move back away from it so I think that's I would just really put want to put that on the list of approaches to consider once we kind of try to move away from just you have to once we investigate moving away from you have to use the exact same pricing if you want to

support a pre compile but that should that's basically I think the default State we in today like the reason why I bring it up is and like why I didn't bring it up like on the call about Fe is because like the cas think ER it has inherently different F model like it has like very different like gas pricing like it so we didn't like even attempts to maintain the same gas cost in zvm so we didn't have problems that some cost in BMR are B for us and so I think it would be like better and more representative for users if like yes it was mentioned that gas costs are not the same but it is mentioned that certain precompile can be find there can be

found there uh if I recall correctly uh this I mean it even brought shortly after you launched there was a project that H I should say carelessly deployed on mainnet without testing and could not transfer because the gas steepen for transfers was not enough so projects tend to have a even if it's the wrong thing to do projects seem to have a these unexpected dependencies on gas prices right it's a I don't remember which project it was but you remember there was a project that broke this way yeah yeah I remember but maybe we should drive forward to not encourage this

dependence uh yes I I'm I'm 100% with on that we don't want to encourage it but we also don't want to break it if we can avoid it but I mean okay so for old op codes like a store and Etc changing Behavior can be the dangerous like in the and like in St for transfer as like the example which you brought up but uh at least perhaps for new things we can explicitly say that okay for this you know like gas may not be supported and as I already said we can even add like a certain disclaimer that okay here it is supported but gas pricing is different

so users are aware of that yeah you definitely have a point in that of course yeah basically project that want to use an IP pre compile or in the future whatever up code or whatever other features we standardize by IPS they will have to write their code more L2 aware anyway because it can only run on l2s so if in that context we already give guidance for hey you can't you know on this L2 you can't rely on the same gas pricing or something that actually might might help and in general it's a good feedback because I was just didn't think of that that in thinking about what counts and does not count as having

supported a specific uh IP that we just have to make to to be aware that there are evm systems that just don't use the main gas pricing model at all so we have to have some sort um system for what counts as as support then in that context and I guess just you have to use the exact same gas pricing of the IP does not work I was not aware of that so that's we look into that good feedback anything else on on this point of of pricing in general so something to keep in the back of your mind probably not related to pre-compile specifically but when veral

ships um gas storage charges particularly around storage are going to change um in the way they work so we are going to have multiple worlds where rollups will have the old world unless they move to veral which will be a big shift but there'll be a time where they'll be on the old and the new so there are going to be variations um verl is targeting 25 right now um there is it's it's consider the next merge um I think there's going to be a lot of effort to to get it shipped do we have a sense of if um rollup should adopt veral trees as well um some rollups have already done

their own thing with storage um like going to sparse Merkel so I think uh diversity and storage tree implementations is going to be a feature of rollups some may go to Vertical some may not and will will it be visible from the applicative layer the like the underlying because you said you was change gas cost so maybe then it will depending on the roll up and the the storage layout gas would probably be the only way to do it if you were to check the gas before and after a store and see if it matches the old schedules um but like I said most Auditors consider such testing an anti- pattern and I really I question if there is a need for it in smart contracts I

don't see how knowing whether you're on verticle or sparse or Patricia adds value to it but I've been wrong before so if I understand correctly with vericle the issue will not be only storage in the sense of a store it's also loading contract since you you are paying per chunk so some code some some things will unexpectedly cost more gas as they load more code I think the code loading overhead um is probably going to be factored into the intrinsic it might be figured into call as well I think that's TBD

yeah and as it stands EF will ship before or after veral probably in terms priority if you know the answers to that let us know because that's we're currently debating okay so just on a little bit on timelines and all of this as I just mentioned like there is a lot of debating happening on the main net side and like as we speak we trying to Hash these things out um the things like voal the large problem with them from an implementation standpoint is it basically blocks all features for uh probably at least a year and a half um on the the execution L side possibly more and so it becomes very

hard to make a case for it when we have to hold off on features and so it need like just the decision needs to make sense in the the greater context of of what needs to be shipped um and so making a case for it also means making a case for not everything else for the next long time and I think that's where the complexities are coming in I think everyone wants verle um it's just a question of of when exactly and so I wouldn't immediately make it's very hard to have insight into timelines here and I wouldn't make any commitments or major plans based on presumed timelines quite yet um but I think in a few months time we'll have a lot more confidence and what what what what the plans are

here you said in order to ship Vero one should stop like like etham should stop shipping features for 1.5 years or right after verco ships we need to hold features just to stabilize no before just just from a development standpoint it's going to be very hard um to to to get anything else done I mean there are arguments that we can we can do parallel work but I think that only delays veral and the other things so I think like in a realistic World given all the testing requirements and whatever that come along with the hard Fork uh if we do do veral we're going to block features shipping until veral like from the point where we commit to do vocal until vocal is shipped most features will be blocked I have one more topic on my kind of Bo

draft for the agenda um if is there anything else on this point otherwise i' move on to that okay right so basically the the other question was um well there was this proposal a while ago about Progressive pre- compiles but I would just want to take as a general question of how do we make it easy for um projects um to write code across l2s that takes advantage of native implementations of features on the l2s where that is like and easily supports them having some sort of

fallback logic in case it that is not and ideally of course that would be forward compatible where if it's deployed on a L2 that does not yet support something natively that it automatically can switch over once uh once once that that support is shipped there um of course the the default if we do nothing could be that every app developer just has to manually write logic to check whether there is a pre-compiler life at a specific address and if not just themselves have to bring um some alternative just raw like solidity implementation of that that same feature um the question is what kind of Alternatives what we have there is the lightweight approach of basically

just having that is some sort of lightweight ERC feature so where basically we just have some sort of standardized Community maintained kind of implement equivalent implementation of of um I um pre-compiled and stuff like that that that people can use alternatively and the question is is there something more principle more structured that we could do um to to to do this so just to Briefly summarize the the the idea behind Progressive pre-compiled that that was basically saying that we could do it the other way around we could we could have have the the solidity implementation be part of the official flow basically um you could either just using normal you know

Universal deployers I understand they don't work on all trains but on most trains you could basically have like a common address um that just the solidity implementation lives at and then you could manually go in and this part of the deploying the pre-compile you could basically just swap out the solidity code at that address for the native implementation of course that's not where we the path we on right now um with our dedicated pre-compile address range um but I think it's it's important conf like as an idea that that motivates this entire conversation so I'm just wondering do do people have thoughts on how we can make support across multiple l2s that might or might not have shipped um shipped a specific big feature yet as

seamless as possible is this something that that has come up yet for people I think uh from even though uh even though every contract could check for the existence of precompile it wants to use maybe from Gaz perspective it might make sense to have one pre-compile that lets you query which which R whether certain RPS are or not supported on the current chain so at least it's going to be one call and then if your contract uses multiple things you just say you just check what you can or cannot use there that make sense yes that seems like a good

building block to have and to me that seems just like a good candidate for an IP inl for pre compile like that talking about RPS um do we have a way to choose at which address the pre compile should be deployed at because I noticed for example Aurora was using like a hash of some stuff so it could not collide with L1 and then Anar you mentioned before that we don't know which eips are going to reach maget and which are not but you would ideally want to like for those that will reach you would want the same address as Main and then for those that want then you want something that cannot Collide

so is there standardization on this right so the status basically is that we talked with people on the quf process side um so basically on on on the Manet side about this um initially there were two ideas one to basically um be opinionated about going into the same pre-compile range as mainnet and basically just then asking Mana to just skip the specific um addresses used um um but uh we ended up deciding that it would be easier to keep keep that separated so of course all the kind of the very lowest addresses um um in it pre compiles and the idea now was to

limit this to say to explicitly say that only the first 256 um addresses on mainnet are reserved for piles and then have the next for now 256 addresses above that be the dedicated L2 iip like IP sanitization precompile range um so that's kind of what we're going with so far so the the R1 um F2 IP also as part of its specification has a specific address that it is supposed to be deployed at which is exactly number 256 because it's the first one in this IP range um so ideally all 2's wanting to ship this should ship this at this

address maybe this is a good question General is there anyone on this call that knows about maybe um an L2 that would not be able to ship it at that address and how and and then to ship at the specific a range we need like who says okay this pre compile is now accepted as a RP range like is it accepted is have we standardized the voting process to to accept one so so so very importantly um the IP

process and the governance is like this is all strictly oped in just because we would accept an ip2 or an RP pre compile to that range would not mean that now all those TW are accepted ship it right so so you can still then pick and choose which which ones you want to support and then otherwise you just skip those those those addresses and of course there's still a somewhat limited number of of of of of of addresses although that is artificial we could go up a lot um there's there's a lot of addresses before we start to have to worry about collisions um I think for now the idea is that we want to be very permissive so any iip that comes with pre- compiles that is that just finalization status

and can reserve an address if it ever becomes a problem if someone proposes an IP that wants to chip 20 pre-compiled and maybe we have to revisit that decision but for now as long as it's not an issue we we want to be just permissive but but in in general this should just be part of the IP process um and we have to figure out the details out okay but then I guess on your other point which was like someone proposes r with a compile and then in the meantime someone proposes like a U or like a raw solidity implementation of it for those who haven't had time to implement it in their zuit or something else um then it might be PR prohibitively expensive no

like it will break the gas cering of the someone might have had like lowlevel ciruits that are somewhat not so expensive and then the implementation of solidity is prohibitively expensive for the rooll of itself but then they have to respect the pricing maybe I I don't know just thinking L right so so any any just solidity implementation would not um benefit from special treatment and would not get special pricing it still just it's just a normal contract deployed somewhere um with just normal pricing that it has to pay so that mean might might mean it's profitably expensive to use for applications right just because it might be much more more inefficient so I think

for example with R1 and I'm sure for have anyone on here that that remembers the details but I think it's something like 300,000 guas for even the most efficient implementations um versus I think 3,000 or 4,000 that the the native version would cost so that that that might make it privative for some applications to use and but it's not a problem for the rollup itself because it just charges for normal um contract execution and the only way in which it's contract might there might be might be an aspect that where we don't just want to treat it normally could be if if we want to have a standardized address for the solidity implementation and then we have these

Universal deployer systems that allow you on all unmodified evm versions to deploy at the same address using Create two logic but of course there are some rollups especially ZK rollups that can't support this because they have different hashing system so like for example I think Zing is one of these examples and so then the question is do we just accept that on those rollups we don't have the solidity implementation equivalent solidity implementation of an of of an pre-compile at the same address or would they maybe want to um with features they don't want to implement natively just basically manually deploy a contract um at a at an address that matches the sanitization or something that that I think is one of these open questions of how to best approach

this yeah I think maybe at some point we can also have a either break call or just some sort of separate effort where we kind of bring in people that that are actively on the the user side kind of thinking about um using say R1 or whatever other IPS we might be close to having Prim actually given that you kind of you're also kind of you're doubling in role here between the E author but then you also have the clay app have you do you have thoughts like do you have

intentions of of of of of of having I know that you're already live now on on on networks that don't yet of course have the R1 promile how do you think in in the long term about basically I mean I don't know really your thoughts but about kind of the routing between the native implementations and and just solidity equivalence for one I think the missing part might be that we cannot provide the same address in are rollup for example in the casing case the crate to gives different address than the rest of the evm so I feel like there is a lack of

standardization for this kind of address selection yeah I think that is inde a problem so we we have to we have to figure out how to how to best do this but maybe this is best left to the to the ESC side of things right like we in principle the question here was more is there something kind of from the base there from the kind of from the evm side that we we could chip and we could change and we could we could specifically introduce this behavior that makes it easier for application developers otherwise we

can always just leave it to the EIC process to have some sort of standardized logic of how to how to how to do all this kind of routing um in the absence of of of specialized features and I agree with you all from the very beginning of this conversation that um it would be worth looking into shipping and a sort of pre-compile that exposes just information about what other features are like on any given chain yeah I think maybe like we mentioned that Pro like some projects might want to deploy on like many l2s but if like say two l2s have a specific RP and it's priced because it's priced low because they implemented it in their

native ZK system um maybe the project chose them for this specific feature because it's cheap and um this this desired to standardize so that every rollup can have at least a solid implementation of it is maybe Overkill because the projects will have chosen them for this specific chure because it's cheap and available maybe the the project will not want to go in like a roll up that has the solid diversion like we would have to validate the the thesis that projects would want the the pr compite to be available to in or like r on on every chain where even though on some chains it might be

20 times more expensive or 10 times more expensive maybe they don't actually want that and the work to get a solidity implementation audited and valid is a lot of work for something that is inherently like some rollups have some use like Niche use cases I don't know yeah that's a good point I think the reason why this came up in in the past was that specifically for this first um RP that that we have as a specific case study the I one pre compile that they have indeed B projects and like largely all the projects that also very interested in the pre-compile a lot of

them are already live on on on several l2s and are using um just solidity implementations for the for the equivalent functionality but that could be an artifact of I mean a maybe the specifics of R1 that is at least somewhat feasible to do that and then B also just the timeline that a lot of those projects got started before it was clear that there would be such an IP and so that just waiting was not an option um it could well be that for future changes that that's a pretty uncommon situation that that there's even interest in that at all and so you might be right that this is worth that could be worth just revisiting once we have more real world experience with with other IPS in the future

have have we done the decision of when to assign a new pre-compile address for a new pre-compile RP how many of the rollups should accept the implementation or or every RP should get get an get an next address yeah I think El also briefly brought that question up like a couple couple minutes ago and I think for now just because we don't have we don't yet have such a thing as before like before finalization having way to Signal support or anything so I think for now we want to just be permissive

and as long as there's a clear you know not spam good faith um iip that moves to final we we would assign addresses in that range because there's also no issue in just skipping some and principle the range can grow relatively large if we ever see that this becomes too popular and and just becomes a problem then I think we have to have a more proper mechanism in place but for now I think the idea is to on the side of being permissive and permissionless it's fun we always have a

lot of people hop off the call on the hour mark which which makes sense so it's always the the important topic should always be in the first hour of any any roll call session that's good to know um but also I think we probably um already like because those were the only topics that I had prepared to to to talk about and of course you know we can we we'll have we have an open section in case there's anything else that hasn't come come up yet but otherwise also I think we it's it's perfectly fine if this call does not run up quite on the 90 minutes um so so are there are there kind of any any remaining topics to talk now okay yeah then I think this is

probably a good stopping point um I think that was help helpful um again I think again takeaway kind of is that that um while while that a we just have to really figure out the kind of the the pricing the the pricing situation what does it mean to ship an ipu unmodified apparently just enforcing the same gas pric is not not not a viable option because some evm systems just have different pricing models and then also like in more longer term kind of seeing how these are used and then possibly adapting the system um but yeah okay that's that's end that um thanks everyone for showing up and see you all next week will be a main roll call again

so so then we will also have a brief retrospective of to what extent these breakout calls were useful and whether we want to keep keep having them uh in the future so yeah thanks everyone and have a nice day thank you see you by two by