RollCall #0

Transcript

so welcome everyone to the inaugural roll call um this is uh an effort that uh anskar HOV and myself have been uh working on in the background and have chatted with many of you individually and uh now we're trying to set this up as more of a group thing um the idea of today's call is mostly just to uh get everyone to together um and to make sure we're all on the same page in terms of what exactly is happening here what this process is um and to check that this like is still what everyone

would like to do um there's been a lot of hype and interest but we want to make sure that uh expectations are exactly what we're going to have here um so I'll start by laying out a little bit of the vision for for what this is um as you all know the ethereum's um vision for how we achieve the end goal of um servicing as many users as possible as cheaply as possible um in as trustless a means as possible has sort of switched from relying on the core protocol L1 um onto this uh L2 rollup um driven vision

and there have been many changes that have that have that have happened alongside of that and I think part of this is that L1 is really been focusing on ossifying and not having too many um too too many changes and to be as like uh as hard to capture as possible and so this has also sort of limited the way um the the the the the changes that we've seen happen to the evm um so we've seen the the rate of improvements and um uh things that have shipped uh from from from new feature standpoint reduced quite a lot and instead the cevs have been L1 cevs have been focusing on uh the

merge um and shipping 4 844 and dunk sharding FAL trees etc etc um which are all absolutely essential for l2s to achieve what they need to achieve um but also don't really help the end user in terms of lots of Fe features that are are needed um and we've also seen that um evm equivalence has been something that's been very important um in in the the road map of many l2s um but it also it it seems unfortunate that we all have the SC of evm equivalence but we're blocked on being able to um have further changes to the EV which may

uh help bring new functionality um uh in things um there've been a number of efforts previously for cooperation along these lines um but they seem to have been a lot more ad hoc um around one or two particular things that that that people wanted to ship um and it's also we've seen a bit of like n squ blow up where it's like one team collaborating with another team on one particular project as opposed to sort of this overall set of set of standards and collaboration efforts and so the idea here is to try provide some credibly neutral platform for these discussions to to to happen um so what exactly we proposing here um and this is more the idea is

it's a a general process which like is comprised of many sort of sub um Sub sub discussions and and sub processes um obviously there is this call which the idea is to have on the uh third week of every month so it's a monthly call um on a Wednesday at this time uh but on top of that uh an optional set of Standards which we've been calling rips uh up to this point and the goal there is to primarily ensure that there are as few conflicts as possible in features that we have um uh there are already a number of ways in which which um all of like

many of these Alters are subtly incompatible um particularly uh with regards to to some of the features that the ZK rollups have shipped um just due to the necessity and limitations of their design um which are less favorable or or work less well with the existing evm SL um some optimistic chains so the idea here is to allow this to happen in a way where we can make sure that they're not going to be well as few incompatibilities as possible because I think that's just a really unfortunate thing to have um so like ensure that we're not going to have weird um pre-compiled deployed at the same address or something like that where it's just like this is just obviously something that could be

avoided with a little bit of coordination um and then secondly it would there many features which are like very beneficial where um that just require a bit of collaboration so uh things like account abstraction everyone is very keen on and some people have started shipping things that look like a account abstraction but the it are often very subtly different from one another and so instead of having um an individual standard for each each L2 rollup we can hopefully settle on one major standard that everyone agrees to use um and ensure that this works well enough for everyone even if it's got a slightly more limited features uh that would be a

a far better outcome in terms of being able to have support from the the the the like tooling and wallet ecosystems etc etc and so extending this to all of the other coordination things that we need um also we would like this to be a metaphorical API between l1s and l2s so uh there's a lot of like L1 devs are very focused on the issues they particularly face um and are often unaware of things are important and and what changes need to happen and also what priority those are so if one team starts loudly proclaiming that this and this is a super important thing that

needs to happen is absolutely essential for their Vision it's hard to know whe for the L ones whether that is actually something that is a shared common thing or it would just help out one particular um team and so this this call could help be an interface for um bringing bringing that all together uh and and and then being able to to present this to uh to to present this to the L one uh consensus process uh and then vice versa to Bubble Up like changes that are happening on the l1s um make sure that uh l2s are ready for Forks um that are that are happening and are ready for new functionality and aware of changes that might be happening

that are relevant um and also to bring research forward at like important for alter to be able to comment and maybe affect the road map a little bit for ways that this uh ways that could really help them out um there so what this is not this is a process that is of course non-binding this is you or the the the process itself doesn't require any kind of commitment um and the uh the changes that will be proposed and standards that will be proposed are entirely optional in terms of what people think um is beneficial the the uh this is not a decree this is how things work this is

more um here is a way that other people may or may not agree is a a sensible way of doing things um and so this is still uh everyone here is entirely in charge of their own Ro this are their own road maps um and how we get we get everywhere um which makes it quite different from some of the other governance calls that we've seen such as ACD um where there it's like we need to have consensus from everyone on what the next steps are and and which eips are going to be included in which Forks etc etc um this would more look like uh individual people individual teams deciding that hey they want to ship this feature and

here's the way they're doing it please can everyone else comment um on how they doing it to see if we can reach a a more meaningful common standard um this is also not going to be become a place for marketing and competition this is like really supposed to be a technical set of agreements um obviously there's there's there's a lot of money at play here and everyone's incentives are slightly different so we will do this to like as as much as possible to like keep these these topics technical um and to try reach common standards that are in everyone's technical best interest um this is also not a call that's going to establish who is and

isn't an al2 um this participation here doesn't Define that uh and it goes beyond that and that we actually are happy having people who uh aren't necessarily a part of the direct um ethereum ecosystem but are maybe uh using the evm for their own context they're welcome to propose standards that may be helpful to um the greater e evm ecosystem um but like the bias is always going to be towards rollups and l2s uh um but the idea is more that if something's sensible that's exists somewhere else there's no reason we can't incorporate it here too so this is not like it's not some exclusive group um being joining or not joining these efforts and these calls means

nothing it is just an individual set of discussions that are happening um so we can hopefully arrive at more of a central like a single Vision with as few diverging ways of doing things as possible so that we can um we can gain from some of those those efficiencies um in tooling Etc so um the I've been working on setting this up with uh Anar and yov um who've been thinking about this honestly for longer than I have uh Ana in the general sort of uh standardization and uh al2 to to um perspective and you have specifically

from the uh uh account abstraction side so I'm going to hand things over to onar quickly to introduce what he's been thinking about sure yeah uh hey everyone I think it's really exciting that we we we we have this this process now um getting off the ground um yeah I think KY has already I think said said a lot of like what what the vision for for this process is supposed to be all of course Very optional but just having having a shelling point for coordination um just from my perspective yeah um I think I think it's been really amazing to see all the Innovation that came with ler twos it at the same time it always felt like with with the focus on evm equivalence that there was this this bottleneck and Innovation specifically on the VM side um or at

least to the extent like that that the evm um set limits um and and I think we've been thinking about how can how can we best overcome this um for a while now of course a lot of of the individual teams here have already kind of done their own um have found their own ways to basically go beyond this but but but um I think there's always been some demand to to to basically kind of combine the evm equivalence with still enabling Innovation initially we had some ideas I think around basically more more heavy-handed you know completely Fork the evm and have like a layer two evm and really start pushing the limits there but I think ER from a lot of feedback from talking to people it seems just like um like a heavy-handed approach just not the right thing I think basically now we have landed on

this idea of of having having this IP process having basically more individual um features that are fully oped in so you can basically mix and match whatever ones you want to support versus go with your own um opinionated approach instead I think I think that's a very promising Direction and um yeah I I think now is also the time I think last year when we talked about this people also like no but we have other things we have to focus on on the layer two side I think now there's at least a little bit of breathing room to to get to this so I'm I'm I'm very excited for the for the process to get going and uh Y is there anything you'd like to add uh no I think so you and asgar already said everything there isn't much to add

and I'm really excited to see it finally happening we've been discussing this actually we started we started working on this idea since e Denver so it's been a while and finally everyone is here so welcome great so I think the next thing would just be to get a rough idea of uh who who who's who's in attendance here um not asking everyone to introduce themselves but like if one representative from each team/ stakeholder can just um mention uh who they are and uh where like how they think this process is relevant if they think it's relevant or

not not asking for long discussions but just sort of like a 30 second of hey this is who we are and um this is generally something we think is Meaningful or not or whatever I can start uh Nicola for Linea uh so thanks a lot for organizing this uh I think there are many things that uh can be quite interesting to discuss during this meeting so I mean we saw some discussion in the chat on the state representation and it's a it's a key topic for all Z kvms so I think it's a very interesting

one uh another one I think kind of easy one I think that we could work on is what we do for the difficulty of code we know that in the layer one it's a random number and I think that for all Layer Two it's complicated for it to be a random number so that's some easy stuff that could be done there I think uh and maybe one comment is we should be careful even if we say okay everybody can do do whatever he wants uh we should be careful not to arrive in a situation where actually everybody does everything he wants because it can do a mess so like we know that it's impossible to add any PR compile in the layer

one like BLS has been incredibly difficult to get and in this case fores we should not go too crazy on the layer two I think we should try to say okay let's not have 20 different PR compiles on the layer two for example but very happy to be there and again thanks a lot for organizing this thanks Nicholas uh someone just put their hand up yes P you're up oh hi everybody this is uh I'm Paul from polygon I don't know if I see anybody else from polygon um on the call at the moment so but you guys all know

Hudson Jameson he he's a polygon now and then Paul gbam has been involved with a lot of discussions with the ecosystem about um various proposals so yeah thanks again thanks again for putting this together this has been um it's it's it's a it's a Time Has Come For Sure basically um I I won't go into detail here I think we've been putting out Pips basically um to discuss various ideas that we have about um kind of top of Mind issues to to to talk to the ecosystem about things like account abstraction 3074 I think we've got a pit for we've got a pit for SE R1 the built-ins um and obviously ZK integration and having standardized apis um for all that is is very very topical for us and something that we're

very interested in working with with other lar tws on as well um you mentioned the issue of competition I think it's a it's a good call out here basically but um from my perspective I'd like to emphasize that there's such thing as good competition and bad competition and bad competition would be uh a lot of people trying to fight for kind of their own bespoke standards basically as opposed to us kind of at least agreeing that we can build something better by kind of doing it the right way the first time so that's kind of the mindset that we have at polygon so that's all I got so far great thanks Ed hey everyone Ed Felton from offchain

Labs developers of arbitrum and my colleagues Harry kadner and Austin are also on this call um for where I sit I think first of all thanks let me join the thanks for for getting this going um I think the two highest goals for this in my mind first are to address issues that are common across all rollups um especially ones that um L1 doesn't see or doesn't have so that we can um find solutions to the things that we're all facing um and then second um deconfliction to make sure that we don't get into a position accidentally where we are com incompatible with L1 or incompatible with each other um so just

making sure that um um that we can move forward with confidence on some things without worrying about that kind of conflict great thank you uh Thiago hey everyone I'm Thiago I'm CEO at and also co-founder of three sigma and for us there are multiple issues that I think is important to address especially for Arc from our perspective interoperability standards are the most important ones so for example the standardization of WX like we were discussing it's very important for us

since we'll be deploying multichain apps um also because we'll deploy be deploying different rollups different l2s with different text Texs so very important to get standards around shared bridges of the different ecosystems and also I would say that finding some compatibilities and standards so that shared sequen projects can work with different yeah with different rollups using the different Tex teexs is also quite um important and coming here also on on on Paul on the competition St standpoint I think finding these standards and for example understanding how multi-chain apps can work um this might eventually to a more

competition scenario between the different l2s instead of direct competition for liquidity and projects uh finally thank you again etherum foundation for the call and hope everyone enjoys great thanks um yeah sorry I have no idea how pronounce your handle hey I'm cman from Zing matter Labs um we're also very excited about this opportunity uh I personally think that the most easiest things to do would be things around standardizing GID derivation um and also standardizing the layer one layer two Bridges across different rollups it would make it much easier for

different da developers to have one standard interface interface which they could use and in the future this could also be expanded to Layer Two to layer two standards thank you also I forgot to mention that stas breadless is also on the call from ZK matter labs and Anthony Rose thank you very much thanks colan proo hello everyone I'm Proto from Ops um well again thank you for hosting this call it's good effort for ler twos and yeah I'll call two things why this this is

Meaningful one it's to get the right product feedback from layer twos to like the rer community get these kind of standards and specifically when it comes to infrastructure I think we have been introducing protocol changes on layer one and then we have infrastructure of end users that's like an afterthought whereas really the infrastructure around uh 444 and other eips so you just be there like similar to how the execution apis are really really critical to ethereum but never really have been so much a part of the EIP process ler to add significant infrastructure

requirements with the increased scale and having standard infrastructure would be really nice and a second what I hoping for is to meet that idea of DEC conflicting like future improvements and the idea of adding things is to just standardize a path for extending ethereum so I doubt we'll ever get to a situation where everything will be the exact same but if we have a standard way of extending the block header in a compatible way then we can allow for differences on player twos while still making the the lives of to toing

developers easier okay and I think Mark is also on this call we're very interested interested to hear all your thoughts on their two SM deuss thank you thanks PTO Roberto hey uh Roberto here I'm from coinbase I think I'm the only one from coinbase in the call there may be others I've missed um specifically I'm on the base team um we're quite interested in standardization around account abstraction um EDM scaling developer uh tooling uh so yeah very happy to see this being organized and looking forward to what we come up

with great thank you uh Peter Hy this is Peter from SC we also have Mohammad and H from our team here uh yeah agree with everyone you're mostly excited about externing DVM and the RPC standard apis as mentioned before and excited to be part of the process perfect thanks Alex yeah hey everyone um I'm part of the ipsilon team uh which is EF funded and works on evm research um the two main pieces we work on you may have heard about is EF or evm object format

and EV vmx which tries to uh give Primitives so that we wouldn't need all these promiles um and of course um so far we have been trying to introduce these features to to mainnet um which as uh car mentioned is is quite challenging um so this goal is definitely super interesting to us um to see how any of these changes could be coordinated across l2s and maybe mayet um and I also wanted to maybe take the opportunity to mention that uh we are organizing a evm summit um at defc connect and we do have plenty of some similar topics as

discussed here but this um yeah the Summit is not related to to what Carl and um you have in and landar is organizing um but I would like to invite everyone uh if you're interested um to discuss this also there thank you is uh anyone else would anyone El like to intro themselves team uh yeah sure I'll go ahead hi I'm Peter from immutable and I'm certain I'm the only person on the call because it's midnight here middle of the night um what we want to get out of this call and so thank you very much for organizing it

by the way what we want to get out of this is having commonality of l2s so that um running across U multiple provs um will um be smooth and seamless and so that um a multi-prover multi- rollup um system decentralized sequences will just work um so that's what we're about is um multi-pro multi-chain and just being able to get all that to just work thanks Peter uh Dan yeah I'm Dan faren I'm one of the maintainers on hyperledger Bas who

focusing mostly on the evm um I've also been working uh with team ipsilon and some of the evm implementor calls to try and get eof over the line and shipped um implementing a lot of the uh features in Basu um my salary is also paid by swirls Labs who implements hadera which so that gives a little bit of a exposure to the alt L1 scene um and I think the biggest open question we have is to get a more firm definition on what ethereum equivalence is and is not so that's something that would you know I think benefit not just l2s but the greater evm ecosystem okay thanks ten definitely a topic uh we could we can get into at

some point um anyone else like to intro themselves uh we l and hello firstly thanks for organizing this call it's a great I think I'm I'm co-author of EIP 7212 and I'm here with danan the other co-author we are also from the clave team and excited to present the EIP and discuss about the current progress in the further timeline great thank you and we definitely get

into your uh uh EIP in a moment last call for uh intros great okay um so the next thing um as uh uh ex was mentioning they've got uh um uh Dev connect coming up in Istanbul next month and um the what we're envisioning is sort of the next iteration of this call will be in person um pretty much with breakout sessions

um uh more whiteboarding style to get into some like hopefully some more problem solving things around some of these uh some of the topics we can touch on later on this call um so that's happening uh as a part of the uh al2 Days event organized by al2 beat and scroll uh which is on the 15th of November um I'll drop a link to the uh the web page hopefully by the end of this week we will have more details for you in terms of what our specific thing is so on the second day of this we're going to have a uh stage dedicated to uh these

discussions uh um yeah anyone have any questions about L2 day SL what's happening in istanb no okay um so next is the topic of rips and I'm going to hand over to uh Anar to uh let him let him elaborate on what been thaning yeah uh great so um as I think we we I mentioned earlier a little bit already we um have thought a little about kind of the structure that this this collaboration coordination effort

could could take and iip seemed like a reasonable um first element of that so I think like most probably all of you already know we have the EIP process uh on etherum Main net uh for proposed changes to the all the all rules that are consensus critical um that's mostly evm um related uh changes um historically that has been combined with the erc's uh which are just Community standards so anyone can just create an ERC on anything does not have to actually be relevant for for for mainnet directly um we are now in the process of splitting these out so eips and ESC will be uh separate um but under the same

umbrella we we're going to call these topic groups and so when talking about how could we basically fit into this um it just was a very natural idea to just basically become a third topic group so there will be eips erc's and then what we propose are IPS to become um and the ideal is basically to just have that as a standard for um all kind of layer two specific changes like evm extensions um that are not directly kind of targeting main net um and so eips would just not be a good fit um um being basically a topic group under the same umbrella as eips and escs would mean that we share the same would share

the same numbering scheme so it will not start with ip1 but with iip 7,000 something wherever we at um also means that if there's ever an EIP 7,500 there will never be an RP with the same same number and the other way around um we would have a separate uh repo though ethereum RPS or something um and then we would reuse the same e magicians Forum that I most of you have already been on various points in the past to discuss eips eic's I think that has proven itself to to actually just be be very just nice place to facilitate a discussion um one specific aspect as well is that um there with eips and Es we have so-called editors those are just

people that basically make sure every time there's a new EIP proposed that it follows just the the the the formal rules of of the the structure the document has to have and these kind of things um obviously it's it's not not an opinionated role you're not supposed to have an opinion on whether it's a good change or not just for that just just enforcing the the structure um we would also need uh equivalent rip editor so the first call of action here would be that if maybe anyone here on the call thinks they would want to be involved as a volunteer um or if they know someone on their team that would want to be involved as a volunteer um um I think the idea is that once we come together in person in Istanbul that we basically get a initial group of of of of people

together there that that would want to take on this role um there are some others basically more nuanced differences to the existing e process where we would want to kind of get dive more into more details in in Istanbul for example um eips have have like very defined statuses so you give draft and then later on you um review and and final and everything and we would basically have to slightly adjust that think about what does it mean in the layer two context um what status would correspond you know at what point for example you know if I want to implement this as in Layer Two I want to implement a standard when can I rely on that it will no longer change right so basically um mapping that to this this new setting um this kind of work um and of course

just to reiterate this like the big difference to APS is that this is not consensus forming right it's just standards so every Layer Two Can at any point decide to opt in opt out right this is so it's a very different process um in that regard um and then um there there are some some other small small aspects of for example I think one open question is the exact scope of this uh so for say nonm changes or layer two specific standards it's I think we have to basically figure out where the line is what should be an iip versus maybe an ESC or some some other type of standard right so there's some some more open questions and then I think one really exciting topic that once we get this off the ground I think

will become more important over time will be the relationship with layer one um um obviously as people has been say have been saying it's one thing to make sure that if there several different layer twos want to implement some cryptographic primitive that they do it in the same way ideally you know unless they have specific reasons not to but then ideally of course if mayet two years later um I guess that's even optimistic timeline with main um ever decides to to spot that as well of course it would be really really unfortunate if it doesn't follow the same standard then right so basically how can we get layer one people already involved in this process without slowing it down of course um how then iips and later on eaps once the target m not related so I think those are a lot of questions we have to figure out um but

uh yeah I think for for for for this call probably uh just to keep it not not not going completely out of scope I think uh I'd want to you know just get some feedback on in general if people think this is a reasonable approach if there's maybe some small CH things you would want to see done slightly differently or something but then I think the details we would want to work out in istan yes yeah so I I think in cases where um we're talking about standardizing something which L1 might also want to do and where we're worried about a conflict say it's something like um a um a new pre-compile to support some elliptic

curve group that we're interested in and that L1 doesn't want to do yet um in a case like that it seems like a sens way to do it to make sure that L1 is on board is to have um is to have it be an EIP but specify in the EIP that implementation is optional and each chain can decide whether to implement that way L1 is bought in to the particular design of it and they're bought into reserving the pre-compiled address and other things like that um as opposed to us developing something ourselves as an rip and then L1 kind of maybe having more optionality later to do something inconsistent right it if we want to deconflict with them we need

them on board early on and I think having it be one of their standards but stated op across but optional implementation across all chains is maybe a better way to do that so just elaborate sorry yeah y have no no I was just saying that this this is actually a part of the this is a part of the rip of the goals of the rip process is that uh um the is that layer one devs will be will be in the process will be involved in the process and we will have some sort of commitment of that once an rip gets for example if a pre-compile gets reserved then it will not be used for something else on uh on

layer one so I think this is one of the goals of H of the current effort but if if I could jump back in it's not just making sure that the numbers don't conflict it's also I think making sure that um L1 doesn't introduce a slightly incompatible different version um to confusion right so having a standard that they are bought into fully um from the beginning seems really important for those cases where it's not just an L2 thing but a consistency with L1 is an issue so part of the idea here and what this is a bit of what I was trying to get to is being a metaphorical API is if we come up with an rip um say for a

curve support as you're you're talking about um that we'd like to uh have in Shrine um then I think it would be wise to go from here onto um then raising this in one of the ACD calls uh to draw attention to it from the o1 devs to be like does this seem like a sensible thing um and uh then they can can can can voice opinions on whether that that's something whether that that that would be feasible to implement on all1 or whether they would need to have these small incompatible changes made um and then if it ever does ship as uh onto the on on L1 we can have a separate EIP which points to the rip basically saying like here is the

standard for how it's done um and um this is the this is where you can find the the implementation um and then the idea being that um in rips I think something that wasn't quite touched on it we we can Main a which uh chains/ l2s do and don't Implement things um so as we see more and more adoption for particular rip because again this is not something that would necessarily happen all at once we can add uh the list of of who is supporting a particular thing Tim you've had your your hand raised yeah maybe also to I think I agree with everything you you just said and maybe to add two more bits um one is that a list of

potentially reserved pre-compile addresses on L1 seems like something that could be a valuable EIP it came up in the context of like an ERC literally this week as well so I think that's probably the amount of like signal you can get from L1 but I I I would push towards having like an a standard as the rip to start just because it can literally be years um for L1 to adopt something if you look at say the BLS precompile which is probably the least controversial pre-compile we've been talking about it since 2018 and it's still not live um so just the the speed at which rollups can iterate and and and move on this stuff is you know probably an order of magnitude quicker than what L1 can do and so I I I

would try to have as little blocks uh or or or or checks like mandatory checks from L1 onto the L2 process um and not to say that like you should should sanity check with with like L1 Dev if they think it's a good idea or what not but I think having the RP be a separate process and and like being able to move quicker is is extremely valuable um and then yeah maybe having a list of just reserved pre-compiled or whatnot and potentially what we can do as well is something like set a a a a specific like chunk of addresses yeah a specific registry that's like these will be all the L2 pre- compiles L1 will never overwrite them and if we were to ever

import something you know this is the default uh address space it would go to um yeah just yeah just want to be mindful of like L1 is extremely slow in doing stuff and so if if you're if you're building your process over like L1 validation it's it's probably just going to slow it down unnecessarily yeah thanks Tom um agree with pretty much everything you you you you mentioned then um again like a lot a lot of this is trying to uh free ourselves from some of the um the the the the coordination and speed issues we see on L1 um but also not be too free such that we end up breaking things will

be incompatible so walking that line is going to be something we going to have to figure out as it goes um some other items that were mentioned um Proto brought up licensing so um strong agree here the um that rips will all need to be um some sort of Open Source licensed which will be able to be freely edited and not owned uh again this is a non-competitive uh non-marketing thing that we're trying to set up here um it's purely for collaboration and standardization um another thing Deno you brought up the idea of progressive pre-c compiles can you elaborate what you mean on that so that's a thread in ethereum magicians it's a way to deal with

bringing any promiles and you would start by defining them as a solidity form and solidity form or the evm form is the definition of the precompile and you would like to canonize it at a certain address through create 2 process so then when you implement it you could do a native implementation of like say the R1 precompile or whatever curve you want to bring in um so that way there's a definition that everyone can bring in with work um if they're okay with really slow stuff There's issues around um you know how do we modify gas charging for that how do you make it you know so we don't get the full cost of the of the evm and we use it to more optimized value um but I think as far as you know reserving spaces and numbers that's something that might be worth um

considering as we go through the process um or we could just go with registry which is also another fine option okay I think that makes uh that that makes some sense um anyone else have some some things I'd like to to mention with regards to rips nope oh Anar yeah I just wanted to briefly say of course um this this is like a big undertaking and there's a lot of I think open questions uh I think the idea of

this course also more to just physically start the process present the idea then we'll have to figure a lot of these questions out over the next few months hopefully we can make some progress in Istanbul already with um with people uh hopefully at least as many as possible people in the same uh room um and and enough time to really dive into this but a lot of this will probably have to be refined um over time as we actually s see in practice how the interaction um across L between Layer Two and layer one goes um yeah so so this is by no means like a present a finalized proposal here it's more of like this is how we want to get started and then take it from yep that makes a lot of sense um okay

so next uh topic I'd like to jump into is the R1 pre-compile um so that's EIP 7212 um obviously it being an EIP is already a thing we can think about um but uh it's a candidate that I think is very meaningful um to to bring that I would have a lot of use um and and is another one of these seemingly just Mak sense kind of things um SEC b256 R1 has a lot of um a lot of usage um but anyways I'm going to give it over again to onar to um dig into that a little bit sure yeah so I think the idea was

basically just to say that we have some technical topics we would want to talk about in istanb um a lot of them these are like bigger topics um that wouldn't make sense today anyway to dive into this one specific pre-compile has been around for last few months now and just seems to be in a really nice place where a lot of Theos we've been talking to have already said that they'd really be interested in shipping this as soon as possible um and so we were thinking this might be a good candidate as like the first I AP so that's why we wanted to basically just have a small section on this call to just um uh discuss it and then the the the idea the hope would be that maybe in isan we could already basically finalize its spe and so so that we could really ship this as the

the first IP uh the the idea is just um so so so uh as you all probably know like ethereum for E EAS so for for the for the inin cryptography we use the sep 256 K1 curve which is relatively uncommon outside of uh of blockchain um and so there's the much more um common um uh basically sister curve of the the sep 256 R1 um that for example is also supported by by by a lot of these Hardware um um secure Enclave systems um and the web or end standard and everything so there's been a lot of desire to have this natively supported um I think their implementations just in solidity but that's like a million um gas per

invocation so it's really quite inefficient uh there has been this EAP we we already heard in the INF round the from the from the EAP authors EIP 7212 um in IP so far of course because there has not been an iip process so far um so yeah what I would want to do is maybe briefly have the EIP authors give an update of where the EIP is at if there's like what the remaining open questions are um and then maybe briefly here talk just talk about um how how Leu feel feel about this as a potential candidate for first IP sure thank you I can talk about our current progress and open questions and current discussions about the IP um after we have discussed the IP in

the AC DC call the community has suggested us to apply an L2 first approach from from that time we have been discussed with some l2s and and rollups to implement the zp and zking has already made a huge progress on building this pre compiles in zking Era rollup then polygon team has requested the PIP to discuss implement in it to the polygon chain we have already published it and currently we are still on the review phase and we have some still open questions the the biggest question which

is also talk in the ACD was having a recovery or verification as a pre-compiled contract we have started with verification because it's the standard of the curve and it's only supported in the devices who is using this elliptic curve and the recovery is not supported in this kind of devices also the programming language has already support for the verification operation but they don't support recovery so having some client implementations are harder in in the recovery part

also in in the E making a recovery makes sense because you get the public address of the of the accounts but in this sitation I don't see a real value of making recovery so we have chose verification but it's still open to open to discuss the second open question is having a malleability check in the pre-compile contract EC recover already has it but we have removed it in in this phase because it's not included in the in the curve standards so we want to cover all

of the test vectors of thee elliptic curve then the last discussion is having this pre-compiled contract as a progressive promile which has mentioned earlier it might allow to use the same address in Every Chain by a Sol code then replace it with a pre-compiled contract and last not we have published a client implementation for for the go etherium clients and a developer from the community has implemented it for the rust terarium and basic client has this elliptic curve in its native library and I guess it

would be easier to implement as a pre-compiled contract and it's all progress and discussion from my side thank you R yeah yeah awesome I think indeed I think that talking to people it sounded to me also that the biggest remaining open question on on on the specific pre-compile would be whether to follow the uh nist standard which indeed is basically you just um you get a ver signature and a pup key and and and verify the signature as opposed to the

more ethereum native um way that we do with with with um K1 signatures where with with e recover pre-empire where you only take the signature and then instead of verifying that it wasn't igned by specific pup key you recover this the P the one ballot PB key that could have signed this the signature so it's a bit of a different logic um there there's some small efficiency advantages uh doing it with the EC recover because then you don't have to store an entire pup key you only have to store say some some sort of Hesh um but uh yeah was was saying is that basically um because the N standard is such a common standard that basically all the implementations only only support the

the verification so it would be a huge effort to to have a etherum specific e recover logic instead um I think that's why most people we favoring the the verify approach and there's also again with another small difference is in signature malleability the N that the allows fam ability of course ethereum usually tries to avoid that um but but yeah so so basically there's just like some some some small remaining decisions to be made here and then this this this this would be something that we could finalize this back off and um have ready for latus that would want to to ship this um also of course ex just mentioned in the chat that there's a that that has been discussed before that they alternative approaches there's this evm Max um proposition that's been

around for a long time to basically just make more arbitrary elliptic curve operations in ethereum um Cheaper by adding these these um um more generic Primitives that can be combined um there's some estimate that that could bring down the R1 verification to something like 70,000 gas um an 8 B compile would be more like 2 to 3,000 gas so it's still quite a bit of a difference but less so than a million gas of course um so at this point what I would be mostly curious I think kind of making sure that the spec is finalized we can do that in Istanbul what I'd be curious more would be to hear from the layer two teams if you've already been in contact with this specific

pre-compiled proposal is this something that you'd be uh interested in in um in shipping if it were to become an iip um and agreed upon spec wise between the different lay to is is something that you'd not be interested you'd rather want to go with an ebm Max route or you just want to wait until main does something basically yeah just getting getting layer to team getting your your team takes on whether this would make a good IP is what I'd be interested in yes yeah oh sorry let me Let's uh

let's go ahead Nicholas no please I'll just go real quick it's already been mentioned that polygon is very interested in this proposal so it's it's a it's both a great proposal for us but then it's also I think it's a great candidate to be kind of the initial you know way that we work through and figure out how this process going work so we're definitely favor and Nicholas I will go next one yeah I think it's quite interesting to look at the at the evm implementations uh because I think a lot of work has been spent there as nobody

had the cures he wanted and so and for us it's a reasonable tradeoff actually so I think because for two reasons first because everybody has exactly some implementation because it's not anymore having to uh to agree on a precompile it's available in the layer one as well which is always good for for compatibility so I think we should really be sure that this this approaches don't work before going for the pre compile at this stage considering all the work that has been spent on that okay thanks yeah I think uh the only com that I I would have on this would just be that obviously like our

role here would not be to be opinionated to to convince people whether they would want to go ahead with this pre-compile or instead take a different route H we've just been hearing from teams that some of them are really kind of wanting to either just chip this on their own in their own version or if we want to have a standard then really basically they were people were telling us the standard would have to be finalized very soon otherwise you know we don't want to wait for too long um so again the I think the the the general Spirit of this group would be more to just say if there is interest in shipping something um by some teams then then basically like we just would be happy to facilitate the standard and we don't want to make a call on whether you should or should not

do so um oh yeah a lot of people K do you want to question yeah I think you got most of it um but yeah just to mention again that like all of these proposed standards will be optional we're not defining the one way to do things in an L2 evm um it's about presenting some standards which you can opt into and Implement um if you so wish on a given L2 um and yeah I think a lot of these things are very complimentary and different trade-offs make sense for different people thanks right Harry yeah I just uh just wanted to say from from uh an optimistic role perspective I think the nice thing about

things like this is that they tend to be relatively straightforward to implement just because kind of if there's a like standard implementation in in go ethereum that that's kind of relatively easily Incorporated I think that like from my perspective this seems like a very nice sort of initial kind of Target just because it's feels relatively non-contentious and obviously quite high value I think that like all of my concerns around it would be kind of much more just figuring out the kind of underlying sort of okay making sure there are like how we can avoid conflicts with L1 how we can like also kind of optimally coordinate around sort of tooling and other stuff like I feel like it's a kind of opportunity with a in a relatively non-c

contentious way to kind of feel out the borders of what really works here sounds good uh yeah I can't pronounce this but you go ahead hey so on our side at ZK sync the pre-compile is also ready so we're also really excited about this opportunity right yeah then I would say it seems at least there's enough interest that it would make sense so um obviously we haven't even created the IP repo yet we we'll do this over the next at some point between now and Istanbul and then work with the cave team to

basically um figure out either just turn the existing EIP into an iip um if that if that makes sense or just create create a new or something um to to have that um I think still in part of the conversation besides just finalizing it could also still be evaluating alternative approaches um and just just so people can make up their minds whether they think this is a good good idea to go ahead with or not the only ask that I would have then would be for teams that are already and it seems I think zyn is probably the one that's already the furthest in in kind of implementing this that at least um ideally you you hold off of like finalizing decisions here before before we have the start or if you if you of course um feel strongly that you want to go ahead and maybe at

least kind of come and and briefly talk with with KL and me um so we at least aware of this um um but yeah I think the ideas in either way would be to have this basically become a finalized stand on on a on a very like Fast timeline because it's a small change um and there's been considerable interest on the layer one side as well already so I think layer one devs would be more than happy to also phasically um participate in that in that conversation to make sure that if we ever bring it to main at that um this General aligns with what play one people feel feel about about this awesome I think that's probably um a good conclusion to the R1 section of call yep thank you um it seems like Tim

has got some kind of pup thing going on in the chat so uh if you're interested in that have a look over there um so uh on the topic of Istanbul some other things that we would like to be discussing there uh and some of them have been brought up already um uh the first one would be State commitment veral which uh I believe Nicholas referred to so um yeah I think that would be that'd be uh a pretty helpful thing U obviously there be a lot of work done already on mainnet for that um and I think now would be sort of this would be a good time to get feedback from al2 on um what is potential issues there are

for using what we already have uh in terms of research for main net because there's a chance that we could be getting this into the next uh main n hard Fork um so I think like now's one of those moments where l2s need to look towards L1 to see if that makes sense um yeah so I think that's veral um eof is obviously something that's been discussed a lot we've seen um yeah a lot of consideration there it is something again that' be a lot easier to ship on the L2 side of things and would allow a lot of the discussions and changes we've been talking about here to happen a lot more easily um should we have um should we have EF um I believe there was a peep and EP done on this

yesterday so uh keep an eye out for that that'd be something that uh it' be nice to have people caught up on and have opinions on by um Istanbul uh counter abstraction is obviously always a very big topic um and uh that's that's really y's expertise here but again would be a a good discussion to be to to be having an istanb um and then some some more general ones that come up is a standardized way of handling fee markets um and multi-dimensional gas pricing uh we'll definitely have a breakout on that um Bridges is something that's been discussed and what this multi-chain lifestyle would look

like um and uh yeah any other topics um we will be posting an eth magicians thread on some of the more some more of the details and topics um an outline for what's going to happen um by the end of this week for for Istanbul um and so we'll encourage you all to to contribute to that um does anyone have any other topics that immediately like to to mention that they'd like to discuss on um in istan connect um one of the things we we brought this up along uh in the channel already but

one of the things that we're working on here at polygon is because uh we already have existent Prov which do use a sparse Merkel tree um and we're seeing that as being something that's sort of starting to exist in the ecosystem we would like to talk about how we can start uh working toward a standard on that or at least um standardized as much as possible so that tool Builders um you know uh people that are interacting with these things have a have a a good starting point so I don't know if we'll be able to get to a a full standard for that uh but but we would like to start talking about that and seeing if there's interest for that uh in a stable great um

yes so I think that's uh that brings us to the end of some of the more technical discussions um so I think some of the um some other things that are important and things to think about moving forward um and certainly before uh before we see each other in Istanbul um one is it would this whole process is not something that uh onar you over and myself are trying to trying to run here we're just trying to provide like a credibly platform for discussion um so we would really like um we' really like this to be Community run as as as much as possible um and I think a good good first example of that is RP

editors um it would be really cool and helpful um if uh um teams can nominate people that they have to to to contribute to this and and help as editors um if if that's something that you'd like to do um other things as as mentioned we'd really like to potentially make some final decisions on R1 pre-compile um so that would be that would be helpful um if if everyone can think about that um I just posted the magician thread on that uh if you haven't read up on some of the latest discussions there um and uh yeah I the we we we have this telegram group that we've discussed

some things in um I think that's that's good for for some of the discussions but uh it's it's also led to there being bottlenecks for uh people joining um uh mainly just when uh us admins can add you so um soon we will be porting that over to uh the eth R&D Discord um which I think makes a lot more sense um it's the same way we handle um ACD discussions and uh the uh um consensus discuss discussions as well um and then that's just fully open so watch out for that um and then we'll connect up the telegram group we have again as a a bridge uh between that so you can still

follow that if you need to VI Telegram and uh yeah I think does anyone else have any final things they would like to to raise or discuss in the the last little bit of the score uh sure Carl um so I've um put together an EIP too um about um evm profiles so the idea is that we talk about um type one type two type three and what we're seeing at a mutable across the different um rollup um implementations is different um op codes being implemented different promiles

being implemented and for the things that say like the um Rand down difficulty having different values potentially being returned so having a standardization on that would be really good and um in the agenda for this call there was a link to the eth magician um conversation on that EIP and hence the link back to the actual EIP itself so I encourage you to have a all have a look at it and um provide feedback thank you Peter yep I posted the uh the link to that in this chat as well um would would encourage uh people to to take a look at that um and we can

discuss further in person in Istanbul uh other further topics anyone want to raise their hand going once r twice okay well then uh thank you everyone for attending um I'm excited to see where we can take this uh I think there's a lot of lot of platform for for collaboration um and then I look forward to seeing lots of you in Istanbul um at uh primarily it's the the again the Wednesday uh this the second

day of the all two days we'll be having a dedicated event to these kinds of discussions um and then uh there's also that separate event which is the uh um the evm day um as as was mentioning so uh yeah thank you very much thank you and goodbye thanks everyone cheers thanks bye by thank you thanks