All Core Devs - Execution #186

Transcript

e [Music] for

than [Applause]

good morning everyone welcome to acde number 186 um bunch of things to talk about today I think the most important thing is um making sure everyone is aligned on the definite zero specs um I believe they're now Frozen but there's been some El discussion on the CL call last week and then a couple tweaks since the last call so um yeah just want to make sure we're all on the same page about uh the scope for de Net Zero so teams can um continue working on that then uh 3074 um I think nether mine had uh some behavior that they wanted to clarify and

then there were a bunch of proposals for tweaks to the eips so I think we should disc discuss those um probably in the context of like future Dev Nets rather than uh changing the devet zero spec um and then after that uh there's a bunch of other eips that people have wanted to uh propose for pectra um it might make sense to go over them but also just to hear from client teams how we want to proceed given we still have a lot of stuff to implement uh so we might not want to like commit even more stuff right now then if we have time to get to this um there were some questions in the agenda about how we want to Think

Through the um L1 L2 governance separation and um how things like rips and eips uh should interact and whatnot so um yeah we can leave this for the end but I guess just to kick it off um the teams want to give a quick update uh with regards to where they are on devet zero um I know we have the implementation tracker but yeah any team have uh any team want to share sort of where they're at now any blockers that they have or yeah floor is yours

Marek Moraczyński: uh so I can start on netherite

side I think we can say that we are almost ready for devet uh because we have all drafts implementation of all eips uh and we are right now polishing them uh writing some tests but of course there are some things uh that are easier to test on devet so there might be hiccups but it's better to try uh uh sooner than later nice

any other team

Justin Florentine: yeah basic you can go um similar situation we have everything in

progress 2537 is done um 6110 and 70002 are done pending uh some revision to adopt the uh 7685 uh mechanism to wrap them up um so that's the same status as last week from the consensus layer and um I think that's about it o and O call are in progress sweet so we are anticipating participating with all that stuff in devet zero

very cool um anyone from gu Aragon

uh other teams um well for Aron

Andrew Ashikhmin: we started looking at most of the eips but um and we will implement the BLS promiles one but um I'm not sure because that will be ready for devet zero because it's not it's far from being complete the implementation uh and also we're in the middle of uh a big change we are switching internally to the Aragon 3 Branch uh which has been in in the works for well for years now uh yeah so um we might uh get uh slowed down because of

that but it's it's a big move for us

Tim Beiko: got it and I guess your your expectation is that um Petra will ship on Aragon 3 basically

Andrew Ashikhmin: yeah

Tim Beiko: that's right got it sweet um anyone from

gu

Lightclient: uh yeah we are in pretty good shape we have 6110 70002 implemented using requests 2537 is merged I'm not sure Marius if the subgroup checks were merged yet but we have those updated and 3074 is still in progress but you know in general we're days away

from being ready for definite zero

Toni Wahrstätter: nice uh 2135 is also ready

Lightclient: right 2935 is also ready

sweet um I don't there anyone from ethereum JS as well

Gajinder Singh: yeah I think uh most of the things are ready we just need to uh integrate s 65 and we should be good to go

Tim Beiko: awesome um yeah I guess yeah maybe let's talk about um 7685 given that seems to be a common thing across uh different teams um Matt so I know you've followed up with all of the the teams

over the past couple weeks oh Anon we can do the subgroup stuff after if that's what your hand is for um but yeah let's do let's do the the message bus um do you have a feeling for like um yeah whether everyone is on board with this is there any team that basically had concerns or issues

Lightclient: it seemed like most people most teams were on board if anyone has complaints questions maybe we can Surface those now

Tim Beiko: okay so any objections to the

generalized message bus if not um then I think this is something that makes sense to include as part of definite zero uh given it a relatively small change and um sort of is pretty fundamental to how we build a bunch of eips we don't want to have like a version that that doesn't use it um I know you you had some PRS uh 2 61110 and 702 that based on this I believe those have already been merged right

Lightclient: that's correct

Tim Beiko: okay so then yeah given that like effectively the spec already uses

this we can just add the CIP to the list uh that's included in pectra and um part of De Net Zero and uh continue with the PRS uh continue with 6110 and 702 uh based on the latest PRS does that sound good to everyone okay no objections um and yeah I missed rest in the updates before I don't know if there's anyone from rest who wants to give a quick update okay if not uh we can move on um Antonio

you oh Mario yeah

Mario Vega: yeah I just want to give a quick update on tests is that okay or yeah uh so yeah we have a very good set of tests for the BLS PR compile and also for 6110 those are basically done um I I and I think 7,02 tests will be done probably today if everything goes fine um remaining is the 2935 we don't have test for that but I think we they will be done this or next week probably and when it when that is done uh we will make a release with all the fixtures so the teams can consume them and also verify uh any box before

dep

net

Tim Beiko: nice thank you um and yeah Antonio you had your hand up I believe about the BLS

Antonio Sanso: sure yeah exactly thanks Tim yeah I just want to make people aware that basically like the 2527 was has been stable like for years but has been a kind of uh addition that is nontrivial in the last week so basically we now require sub group checks for all the operation but ad uh so in case people want to update their implementation uh this is a right time to do it and there is a bunch of uh test vectors that has been added as well that cover all the corner cases including these sub group checks that are

mandatory now just this like announcement I don't have anything else

Tim Beiko: thanks yeah and I think we had your last commit in the spec for devet zero but if you have a chance can you just put the the pr the commit in the chat uh so everybody can reference

Antonio Sanso: sure I'll do it right now

Tim Beiko: thank you very much um sweet so okay there's some comments in the chat about when they zero uh with different dates um I don't know if like it actually makes that much sense to set a date here um like if if the earliest is going to be you know sometime next week but I think we can probably coordinate this

offline um as client implementations start to be ready um and maybe have like a bit more of a discussion on like having more client join next week um yeah I don't know does anyone see a strong need to like set a Target date right now it it seems like we can just keep working on the implementations and um launch it whenever it's ready um okay I have one yes in the chat um okay let's do that then um and I think yeah uh also based on like Mario's uh comments earlier like once we have um test vectors as well for more of the eips then it's valuable for clients to

actually um run through those make sure that we're passing everything and not just launch a def net where uh we find bugs that the static tests could have caught um yeah um yeah anything else on devet zero oh uh shall we yeah uh yeah you want to talk about the

B yes yes

so just before this call uh dusting uh he found the uh test vectory errow um of the consolidation so uh we will fix it and

it I think the error is just in the test Vector so we will F uh cut a new release soon to address it and also we will include the P death um new test nice it and also extra Electra test thank you

awesome thanks

Tim Beiko: um so yeah so and to be clear the specs themselves should not change it's really just the tests for all those things right

yes

no substantive change to the Electra part got it

Tim Beiko: okay anything else on devet zero um can we get an El test release or

at least fil test before devet uh so Mario said they're planning your release for next week but um targeting BLS 6110 72 2935 I think that's everything on the El side Mario will the will the release from next week basically Target all the eips from devet zeros or is there oh I guess maybe o call is not included

Mario Vega: yeah maybe probably OD call is going to be but the ones that we are trying to aim for the release are the ones that are like uh absolutely necessary for example the um 70 7 7,2 and 61 10 they have changes to the header yeah so for the

exception of 374 as long as we don't call the up Cod the test will work yeah

Tim Beiko: okay okay so we'll try to get test vectors for everything but off call next week and then we can add test factors to 3074 after

Mario Vega: yeah yeah exactly

Tim Beiko: cool um sweet anything else on devet zero okay um so 30 74 um there was a comment by nether mine um about clarifying some behavior and then a bunch of requests for changes um from uh

different uh developers so I think it makes sense to First address uh the nethermind concern and then we can maybe go over uh the other sort of proposals for it um who was it from nether mind uh was me um yes please um so it's it's

Justin Florentine: I think I have uh Miss uh said it in in the GitHub issue it's basically delegate call before oath call not the other way around okay um so apologies for that uh and um so basically the idea was uh that currently o call only works for the authorized

invoker and the invoker cannot be some kind of a proxy contract that can uh delegate the authorization to another implementation um so uh we were uh I was thinking that uh this will prevent um certain use cases um from emerging and maybe we can we should look at it in a different perspective um there is some suggestions uh to do it in another way so instead of allowing delegate o call after delegate call um I think light kle told me that uh he's thinking about an approach where we um initialize the

invoker contract inside the frame of the eoa uh like client if you if you if you care to elaborate

Lightclient: I've sent this around in a couple places but I guess the tldr is one idea that I'm thinking about is to possibly change the behavior of off call so that instead of just modifying the message. sender so in the next frame you call like exactly the Target that the EA wanted to call you actually call into some Target code that was signed over in O similar to the EA I think there's a lot of bit a lot more ability to reuse existing smart account

code in this type of format so it's something I want to look into I'm generally feel okay about allowing delegate call in 3074 in this format or just allowing it in the currently specified format but I'm not sure that there's going to be much change in 3074 for the next month or so as we're working on devet zero I would just like these conversations to continue happening and maybe have some sort of concrete proposal of change in one month's time

Tim Beiko: yeah so there's a comment uh by algar saying you know this feels like a rather big change I guess um talking about big changes to 374 does it make

sense to cover the other proposals and sort of see where we stand after that or do people have comments or thoughts um okay have a plus one for the other proposals so the other one um who was the first one that posted about this on the chat uh uh so Derek I don't know if you're on the call Derek Chang um that yes do you want to talk to talk through yeah your proposal

Derek Chiang: sure sure yeah so so the the the proposal was actually first proposed by uh uh Anor from um bony you know which I think you know who who I think is also here you know but but basically like the idea is that um so so basically like right now it seems that there are two

different needs uh when it comes to the nons spots of the off message right so basically like one group of people want a uh inal way to revoke nons messages so so uh like in particular I think they want to be able to revoke all the messages in a way that is independent of the invoker implementation right you know so so I think the concern here is that if the invoker is like buggy or malicious there should still be a way for the user to revoke messages um and then there's like another group of people who have a lot of problem with the with the with the fact that by including the nons into the off message every time you send a

transaction from your EA you are revoked all outstanding ath mates right so the the issue here is that so so so for example so so for my for for my company zero def um so we are building a account abstraction based embedded wet right so some of the most popular use cases involve long-standing authorizations right you know so so for example session Keys the idea that you can attach a temporary key to your smart accounts and then uh you know basically have other people send transactions for you so if you were to implement that on top of 3074 that would depend on a long a long a a long live off message right and really like any other use cases such as like for example like attaching a

pass key to your to your smart accounts that will also depend on that right so the fact that like every time you send a message from your EA you killing all Long Live a messages I think will be like a really really big issue for this um uh I guess like smart account use cases so the The Proposal that uh you know anchor and I wanted to propose uh is essentially um so I think I think I will probably send a uh put a link here you know but basically uh I'll just put a link in the chat before I uh right here yeah so basically this is the idea and then you can see my reply to this message like

right below this message right you know so so basically the the TLD is that um we change the nons parts of the of the spec sorry like like like the nons part of the a matage to um to two things which is nons manager address and nons manager nons so the non man the nons manager can be any address so it can be a eoa or it can be a smart account right sorry like a ea or smart contract right so the most basic way to use this would be to set a non manager to your own UA in which case you get the exact same behavior as today right in

which like if you send a transaction from your ea uh you are you are revoking all messages but this also gives you the ability to uh essentially use another contract or you know you like another EA or another contract as your non manager so for example I think like one very powerful way to do this is to use a counterfactually DE deployed contract as your nons manager so this contactually and deterministically deployed contract uh will be essentially owned by your EA right so you don't so you don't actually have to deploy this contract to have a nons manager so uh you can specify this contract address as your non manager and then uh like when you actually need to

revoke a message you actually deploy this contract and you increment it nons right you know you know in order to revoke messages but this means that first of all you don't have to pay any cost to have to have a non manager but then secondly um uh like it gives you the ability to both revoke all messages out of protocol out of protocol but just like independ independency of invokers but also it doesn't mess with the fact that you can you know just like use your EA without accidentally revoking all outstanding all mes yeah so so basically this is a proposal to meet both needs once the need to have be able to revoke all messages independently of invokers

and the second need that is the ability to use your EAS um without accidentally like revoking all outstanding aut mes that's a that's a

the

Tim Beiko: got it thanks Anar believe you have a response to that

would

Ansgar Dietrichs: say I mean I think it's an interesting proposal but the way I think about 3074 is our our goal was really to basically because the the nature of invokers is so unusual because you can't just have have arbitrary invokers but every individual invoker has to be manually WID listed by the wallet which means we only end up with every wallet will only end up supporting two three four um kind of CommunityWide big kind

of standardized invokers and because of that we have like much better trust guarantees about these invokers and so it makes a lot of sense to try to delegate a lot of special purpose logic to the of the invoker so for example in this case you can get the exact same behavior by just making the kind of the in protocol nons check slightly more permissive so you could for example um um basically or it is very similar functionality where basically you just in protocol instead of always enforcing the nons Restriction you can basically make it optional you can say if you sign over the zero nons basically it means now now the nons is non-binding um and then we could basically instead of this having being an enshrined part of 3074 it could just be an ERC so there's an ESC for if invus one they can opt into a

nons manager pattern and then we could basically just on the social and force that hey wallets should only WID list invokers that follow this non manager pattern if we think it's a useful patter right and because again like wallets will only there will be like three or four really really popular kind of ecosystem wide invokers like like a batching invoker like whatever right so so we can just basically pick whatever Community standard we like the big advantage of this is that instead of having to make a hasty choice now which constrains functionality forever and is very very basically opinionated about the choice we delegate it to the ESC layer where we basically then can take the proper time for the next one two

three years figure out what is the best patterns there are and then all come together around those features so I I I personally be very very strongly opposed to enshrining special purpose functionality like that directly into the op itself

uh but but

Derek Chiang: but just making sure I understand so like like are you proposing that we just remove nons or together from the

off Mage

Ansgar Dietrichs: or you could so so yeah to to flesh that out so basically what you could do is you could say that you you say if the nons is zero basically it's not finding in in the message if it's not zero it's finding which what that means is that by default the signer can choose right what would they sign over so so your wallet could basically say hey I always make my um my my Au message is revocable I make the

non-revocable it could be a setting we can figure out should should this be in the setting exposed to the user is this insecure it's Expos to the users do we want do we not want this we could figure this out in proper time right we wouldn't have to make the decision now and what that also means is that the invoker now could on top of that add restrictions so basically I could write an invoker that says hey my signatures always have to be revocable right because it it can it can impose some someity conditions on that nons field so that way basically we could just the protocol itself is unopinionated about it and then it is up for the later on the community standardization process to figure out what rules we should enforce like we can end up in the exact same world with invoc enforce the exact same

rules but we don't have to make that decision once forever in protocol and enshrined and how to change in the future but instead we make it on the ESC side but we have much more flexibility

Tim Beiko: and just to make sure I understand so the changes that this would make the 307 4 is effectively make that one field optional um when you do an initial signature um and we hope that there there's like a set of best practices that uh emerge around just like either requiring that or disclosing it pretty clearly when um when it's not re revocable is that is that correct

Ansgar Dietrichs: yes and I Would by the way

propose the same thing for the chain ID as well make it optional

got it uh Dan

Danno Ferrin: so if we make the notes off optional we make internal authorizations possible and that's where my big concern is is unrevoke internal authorizations because we'll always have buggy code we'll have supply chain errors we'll have user error um I still want some mechanism such that um if there is an internal authorization that can be revoked in setting the notes to zero um you know if there's a way to create a permanent one that's kind of the problem that's what I'm looking for is some way to roke revoke these and I agree with gar and that um putting the parameters into a smart contract and app code is way too

early um so I yeah so I don't like that proposal either

Tim Beiko: uh Richard

yeah

Richard Meissner: just wanted to like to the part like what op making optional means right like um because it's interesting making a parameter optional like here we have like multiple Parts in the O call and there's the commit part where it becomes more optional if we move it there and which I think more the ERC part but also here if we want to keep still on the outside the same compatibility where we say we would want that the account nons could be this Global revoke then we would also need a way to access the nons the account nons which is currently not possible as an OP

code right like so basically the question would be should we then push a nonstop code which again increases a complexity or do we say everything else is just another step that potentially then if we go the extreme argumentation route could be bugged and not be called

um yeah Anar yeah just Bri under

Ansgar Dietrichs: though because if you still have the option at least to enforce Lans then you can always basically still accept access your own loans and then for other contracts you could basically because you can just have arbitrary logic right you can basically just have yes they cannot currently access their own L but you

could just have any other replay protection mechanism instead they can just manually write to storage and it has the same effect

Tim Beiko: um okay and there was a bunch more comments in the chat but uh including one by Mar saying you know should we have like a specific breakout room to flush this out um I I sort of am leaning towards so like uh it feels unlikely that we like agree on the large design change of the EIP right now um and you know

there I I think there are some um like there's a concern that like you know if we send this back to breakout rooms we just keep iterating on it uh forever and then end up not shipping something in this Fork which is not great um so yeah the yeah the people feel like uh a breakout room potentially next week and then seeing if we want to make that recurring for a while that would be valuable um I think we probably want like some solution or final spec for this in the next like month or two um if we're going to actually ship it in

Petra uh assuming it's like a relatively simple change uh and and overall the CIP is not like a huge one but yeah does that make sense to people okay no objections um I guess maybe if people want to coordinate in the chat here or on the Discord to find a time um yeah I I I think uh basically discussing the topic of revocation we we didn't even get into chain ID today but uh based on ongar's comments you know maybe we can use a common mechanism for for all of that um yeah I I yeah okay so Matt will set

up the breakout room uh where we can discuss this further um we'll keep I guess uh maybe back to the original concern uh on the nethermind side does it make sense to make that change uh with regards the delegate call for devet zero my sense is no we should just keep the spec as is for devet zero and then when we have um when we have uh like a consensus on the updated spec we can just move the whole thing does that seem reasonable to people okay uh so yes Dev zero has 3074 um but we would not change it from uh the current

spec um and uh yeah there's a comment about like fully removing 3074 from Dev that Zer I would lean against it because it still seems like teams are in favor of doing yet and it's more a question of how rather than if um but yeah if uh a month from now we realize that there is no path forward and no one is happy about it uh we can we can always remove it then um okay so uh oh Siri I see you have your heads up is this about

374

yes um the suggestion was that we would discuss additional stakeholders um who uh uh did not get a

chance to voice their concerns about 3074 in general and perhaps consensus was formed prematurely before polling in um sufficient uh community members so I think there are some people on the call that have concerns about 3074 being kind of bad in principle um and something that would uh slow us down um on the path to full account abstraction um you know that it's it's a essentially a a cludge um that doesn't give us things like our key rotation I mean to

Tim Beiko: look I think we we have basically discussed this for like

the past four months on this call on and off and I know there's a ton of eth magicians thread I know there's other proposals um I know there's like some uh effectively like te step that we get out of this if we move to a like full say 4 33 seven world my sense is that despite all of that client teams still seem pretty in favor and it does seem like the most I don't know the proposal with the most consensus in the short term that we could actually you know improve the state of EAS uh in the next Fork um so I guess unless there's like something new um that came up and and

like yeah I

but Cent

teams shouldn't be the only ones that make this decision this is something that affects everybody and um you know we should hear from other stakeholders unless we want to say that basically we're handing over governance the client teams which I don't feel is a decision we ever made explicitly it's quite unsafe in my opinion so if we don't want to Veer into the realm of making contentious hard Forks uh with everything that entails I think it would be better uh to try to get a feel for what other stakeholders um how how they view this proposal

Tim Beiko: I mean I think this proposal

was first brought by like not like I mean non-client team developers requested this for this fork and we again we had a bunch of conversations about this it's fair that like some people disagree and look I I agree that we should um you know we should get broader input in that but um yeah I'm I'm not I'm not convinced that there's that much value in like rehashing the whole debate again um but yeah um yeah Martin is this

I don't think it's about rehashing the arguments I mean some of the arguments maybe some people have not heard it's just feeling out whether we do have consensus because you know this is again

something that affects everyone and there's a trade-off here to be made between improving things on a short-term basis uh with something that does have potential ux improvements but also has potential ux drawbacks uh depending on how you implemented also in other levels of the stack like wallets whether you're Whit listing or you want you're not wh listing so I think I feel like it's important for us to at least and for the client teams to at least understand how other parts um of the EOS are viewing this and if it's true that um you know there is actually consensus then you know that's one thing but if it's just something

that's you know convenient and easy to implement but maybe it gets us stuck on a local Maxima and delays Us in getting ux improvements that are more sustainable longterm and you know improve the the ux for everybody maybe maybe that's a trade-off that we want to discuss because you know ultimately this this value judgment on what you want to prioritize um so I feel like we should at least hear other people out

Tim Beiko: yeah Martin please yeah

Martin Holst Swende: yeah so I think well I have probably been one of the voices who have been crit critical

about or at least raised some concerns about 3074 still I do think um progress is important and I really don't want to uh stop this progress and essentially kind of yeah kind of try to Heckle or reverse that decision I think I would say we should go forward with 3074 but I still want to to bring the perspective that it brings uh yeah smart contract developers in a in a yeah well challenging perspective or position because clearly we want long-term account abstraction with things that key key rotation and the the question has always been is there a path to upgrade EAS to do that or uh is a manual

transition necessary and um with 3074 kind of the answer lies in between uh it is partially doing this migration of EAS but not fully so kind of for smart contract teams it's just 3074 without commitment to uh 503 uh put them in a in a hard place and and I heard that from obviously I talked to safe but also to the other smart contract teams um because well now it's it's not clear um should we try to convince users to give up their EAS and move to a Smart contract or is there actually a pass to to stay on this EA

and fully upgraded so I would say or my wish would be that there is a commitment to one of those two passes so essentially saying either yes we say you want to upgrade uh youas and there will be whether it can be directly included in this for or in a future one but at least there's a commitment to yeah let's say 503 um well that would be great or or if or also if if there's a commitment okay this will not happen well then would that would also uh be an answer and then you know okay well then you can use 30 74 at least to make it very efficient to bch or to to do a large transaction and move all your funds over

to a Smart contract I mean that's also something to work with but this uncertainty is uh is is quite challenging

Tim Beiko: thanks yeah and I think that's that's very fair like um yeah like whether 3074 has a path towards full smart contract wallet um um yeah is is an important question to uh to uh yeah to determine um and I will say yeah like we did consider you know 5806 early on this year and had a bunch of conversations about that so um yeah there is a tension between like rehashing all those conversations versus um yeah moving forward with something um that actually improves ux today

um

Anar

Ansgar Dietrichs: yeah I um I just wanted to largely Echo and agree with what Martin um just said I think some of the kind of the concerns here from the Cod side is more on the process side like we obviously debated this for quite a long time um I think a lot of the concerns came only after the decision was finally made which of course is not how how that should be at the same time I understand that the government posos is not even though it's open it's not always super legible for people who don't as part of their full-time work pay pay attention to it so so actively so I feel like it's important that we kind of find some sort of compromise here and I think actually because we've had prent right of of changes that are kind of preliminarily accepted into fork and then relatively

close to the fork we make a final go no goal no go Po and potentially pull it back out which is always not that hard to do so I personally would propose that we basically spend the time between now and when we would have to make a final decision the default should be that it is assumed that 374 is in because we did accept it after all but that basically now there's a responsibility for us to really spend the time sketch out a concrete plan that includes like a proper kind of long-term transition path including like I don't think it makes sense to consider e is like 53 for for for pectra but I think for example committing to shipping it as soon as possible afterwards or something or or some some general upgrade path um so basically on that side and then also

separately just basically having a very kind of reliable path for compatibility even in the meantime between 374 and 437 um in place and I think basically we should we should only we should we should make have the understanding that 3074 will will be pulled out unless we make enough progress there that by the time we make that ision everyone is happy about the path forward and I feel like that that that seems like a reasonable compromise to me

modal

Tim Beiko: to everyone I think I agree um yeah

vitalic yeah yeah

Vitalik Buterin: just like one side point in terms of this uh idea of agreeing on a path forward Beyond

Spectra one other side of this that's uh worth keeping in mind is basically digling ahead of time what kind of guarantees and invariance are going to exist versus are not going to exist and so there's possibly value in doing some kind of signaling similar to how we deprecate self-destruct but like for example deprecating the the idea that if an address has no code then then it's not non-transferable or like similar kinds of things that are used by like for either soulbound token people or other kinds of applications like I feel like there's like some small number of uh applications that rely on certain in

variants that exist today that are definitely not going to exist in the smart contract world and this is what one other of those like two or three hard work out things that's also worth thinking about pretty far ahead of time

Tim Beiko: yeah I think that's that's actually a really good point like especially something like you know if we did 503 and for whatever reason we can't include it in this Fork um and that changes you know effectively the the invariant on a smart cont on an eoa we can then um yeah have just like an informational EIP in this Fork saying like as of Osaka um you know you can't assume that an EA stays an EA and this is also good just in terms of like if yeah giving people time

to deal with this Behavior so if for example we decide in like two three months that we want to do 5 three and then we Shi that two 3 months after that it feels like a really quick timeline to change you know something that's been a pretty strong good variant for like uh yeah over five years almost 10 years at this point um so I guess clearly we're not going to come up with a final spec uh now um light client said he would organize a breakout room on this um where should people go to just like um basically help schedule the time for this breakout

um I'll post it on all cor Do's Discord cool

Tim Beiko: um yeah I think I think it makes sense to have it there and I think um yeah we'll definitely open GitHub is you know as soon as we have like a rough time um and I think for anyone who thinks who has like a different perspective or you know concerns about 3074 it makes sense to bring them up there um yeah so anything else on thatp okay uh yeah thanks everyone I appreciate people coming and uh sharing their your thoughts on this um and again yeah for devet zero let's just leave it as is and um hopefully in the next month

or month and a half we can have sort of a V2 of the EIP that we can then uh change all at once um next up uh there were a bunch of proposals that people also wanted to get included in pectra uh I've listed a few on the agenda but uh two more that um weren't posted in the agenda but I know we've been discussing your obviously eof and then etin had a bunch of ssz related eips uh that he he posted in the East magician thread um I guess given that we have already like six or seven eips in pectra that client teams um have not

implemented those do does any like client team feel comfortable including more stuff yet if not um how do people think we should proceed with regards to like signaling what we might include in this Fork do we think there's any chance we can include anything more um yeah how do people feel about that

Martin Holst Swende: kind of depends on what we what we're going to include like for definit zero we're like we're definitely not including anything more yeah uh for pectra if if we were to include EF then the focus do definitely

full if we were not to include U maybe we could include something more but even then I would be kind of against it

got any other teams have thoughts on this

well um not not speaking as uh one of the execution client teams but um there there are still some potentially resolved uh security concerns regards to uhp 3074 and it is possible that they will

be resolved um on the dev Nets one way or another but it's possible that the ones that we've kind of uh flagged as as potential issues are not the only ones and it's been three years since the last Audits and quite a few few things have changed um so there is potential interactions um that we may not have fully taken into account and seems be a little bit safer if we do more work just to validate that it's going to

be um you know safely interacting with everything else and

like

Tim Beiko: I think they're probably the best um the best approach is one getting to a spec that people think is reasonable once we have that I think we can consider whether or not we want to have an audit um I don't want like an audit to be like a reason we just use the delay making a decision if people actually understand the risks and and are comfortable with them um not that like we should never do them but

um historically there's probably like a 5050 hit rate as to whether these are actually you know quite valuable and provide us new information on something or um just something we do to effectively like get more confirmation on on like or or at wore delay kind of the the process so I I definitely wouldn't want to commit to like imposing this extra requirement on this EIP until we have one a final spec and two like a reasonable concern to think that there's something about this spec that's like unique and that it requires like a an audit uh whereas like by default theps don't get a full audit before they

go in um and I guess yeah back to like the just the broader inclusion point so there was a comment in the chat on uh 7212 which is like a relatively small change um and it feels like there are a bunch of relatively small chains that are being proposed so you know 503 is one 7623 the call data repricing is one um you know are there changes that teams would like to CFI to sort of signal a short list for stuff that's been considered for pectra do do people want to just uh leave the scope as is move forward on the uh implementations and then you know revisit this in a few weeks

um yeah Ahad

Justin Florentine: um so a personal um opinion is to include uh 7212 or um a similar widely supported elliptic curve um to actually improve account abstraction for the users uh uh if we keep like instead of um trying to uh say that EA will will stop account abstraction from Pro moving we should actually try to improve account abstraction so people actually try to move to that and 7212 does exactly that it improves um how account abstraction could deal with uh the US the users's keys and allow things like

um um uh pass keys and uh fingerprint uh authentication and our fingerprint signing Etc um biometric signing um a lot of other possibly key holding uh devices like QB key Etc so these thing I believe that uh including something like that will actually do improve uh account abstraction in a meaningful way

thanks any

Tim Beiko: I know Basu was like in in favor of 7212 but yeah any other thoughts from client teams on this

Aragon is also in favor

Lightclient: I think the go ahead Marius you can do it yeah I think one question that we had was is uh R1 the right curve to be adding as a pre-compile I am under the understanding that there are there's another curve that is starting to gain adoption and people are migrating towards I feel like if we're going to add a pre-compile it would be better to add the pre-compile that people are moving towards right now rather than the pre-compile that's on the way down but this is something that is like a bit outside of my expertise so I'm not sure if

any specific

Vitalik Buterin: up and

Rising curve do you have in mind

Lightclient: I have heard that people are looking at moving towards ed25519 as an alter alternative but I don't really know like what the status of that is in Hardware

Vitalik Buterin: yeah I don't either like I definitely know that 25519 is a super popular in just cryptographic applications in general just because it's a very fast curve and it has addition equations that don't have any subc conditions which makes it like Z boards and side Channel safer but uh yeah Hardware support it depends um maybe we this this gets into a bigger Rabbit Hole of like just how General

might it make sense to make an tic curve precompile but might be worth taking offline

um ongar is this on the same topic

Ansgar Dietrichs: yeah I just wanted to be with mention and just a flag for people that they're aware so 7212 happens to be the only uh the first and so far only RP that has been shipped to L 2 so there's quite a few ler tws already that have this life in production which of course does not we don't have to force our hand at all on on man decisions but at least it's something we should we should take into account so um keeping keeping in sync with features that are shipped on layer twos I think should at least be a a small reason to what's what's doing

it

Tim Beiko: yeah I guess based on all this I would lean towards just making 7212 CFI so we have it as like part of our short list uh not committing to implement it you know in the fork yet and definitely not in in in defet zero um yeah anyone against that okay um and I guess yeah are there any other of the proposed eips that like client teams would like to sort of CFI so that we can um you know consider it

for the the next Dev Nets once we a bit farther on on these implementations

Marius van der Wijden: uh yeah I also like 7623

this is the the call data the call data repacing

Marius van der Wijden: yeah it um it's not like it's it's super easy implementation but also it makes kind of intuitive sense for me to cap the amount of call data um that can be put in a block in the block size right now the maximum block size is 74 megabytes right uh uncompressed um because we Snappy

compress all the time it's way less something like two or 3 megabytes um but if we're uh when we're moving to what's the p d and putting more blobs on the chain it's just a nice Insurance to um have a tighter cap on the maximum size of block that we need to

S

Tim Beiko: okay anyone else in favor of CFI in 7623 are strongly opposed oh

I

Marek Moraczyński: I think

if we ever want to rise gas limit uh the CIP might be required for example because C clients have uh 10 megabytes limit or we have to change this limit uh and the CIP will makes uh make things better here U so yeah I think it is good

a

Tim Beiko: okay any other thoughts on 763

um yeah I guess it would probably make sense to CFI this one as well I know we've been talking about it for like several calls and it people are generally supportive but again it's like a question of bandwidth and and uh um yeah uh yeah um Richard has a question about this around data um whether data around how this would increase average gas costs um Tony had a ton of data on this um I don't know if he's on I think he's on the call but what's like yeah what's the best place for people to sort of see all your analyses

Toni Wahrstätter: um yeah so I put a lot of um posts on E research I think they're three so far

and in the one that is directly about the E there is also um this GitHub page linked where you can input um addresses or functions and check if they would be affected by the increase or not

Tim Beiko: nice um yeah if you can post this in the chat here for easy reference that'd be great

Toni Wahrstätter: yeah I will look it up and post it

Tim Beiko: uh and then Anar is a question the chat around like if we have broad support for it why not include it immediately I think given like all the stuff we still have to implement I'm cautious of like adding more things in

like an ad hoc way where if over the next like three calls we just add a little thing a little thing every call we end up in a spot where like okay we can't actually commit to like a bigger thing to add to pectra because we just added a bunch of small things so I I feel like it's better to sort of just identify the things we'd want to add after devet zero actually get devet zero done see you know how things are for something like eof see how things are 3074 um and then decide like okay do we want to add like two small eips one big EIP um and have that conversation when we actually have more context um does that make sense okay um aside from uh from these two uh

7212 7623 anything else client teams feel strongly about

Vitalik Buterin: were we going to talk about the

SS

Tim Beiko: um I don't know if Ethan is on the call um he posted an update. eat magicians I'm not sure if he could make the call to talk about them um I don't see him but there's 100 people here so maybe I missed him

this is s c on the ex

Tim Beiko: uh yes so let me I I'll post the like uh his comment in the chat here um yeah

vitalic did you have thoughts on them

Vitalik Buterin: um let me yeah read through the comments and come back in a minute or two cool

Tim Beiko: um and yeah worst case we can always discuss this on the on the next call um any other um any other eips people feel strongly about

Marius van der Wijden: I feel strongly about not including SSC on the execution I think for for that we would need to um write or audit new libraries um for the S format we would think about um the

hashing overhead and stuff and um that would that would really make it um make it hard to ship I think the S ification of the execution layer should happen in a in a future

f

Toni Wahrstätter: yeah just to add to this I've been ating SS libraries after we discussed that in taipe and I'm talking about the goang S libraries and uh there's one I still need to look at but uh none of them is really workable with at the moment which is why if I'm correct we decided to drop the topic for the previous Fork

got it

um anything else ons yeah I I

Vitalik Buterin: I just looked at that quickly um is there an EIP get for SS ifying receipts as like I know there's a bunch been a bunch of work for transactions right but

Lightclient: I'm pretty sure there is

Vitalik Buterin: yeah I think it's

Lightclient: very close to the transaction EIP

Vitalik Buterin: right yeah because receipts I think are also super high value and one of the reasons why is basically because receipts are the one place where you get where currently we can have these uh like indivisible potentially like many megabyte hashes take place and uh that actually causes a whole bunch of like

pay and extra security auditing uh overhead for for for rollups which admittedly can be solved by by a layer to but uh like there there's basically a lot of receip hashing applications that are needlessly forx to to efficient at the moment that could be improved a lot so I think there's a like there's significant value beyond the inherence goodness if quean UPS to think about

okay

Tim Beiko: um one other thing I think is worth getting an update on is eof so I asked I

know there's a meta EIP that's in um I I think we still need to get it merged but um yeah I know there's been a lot of work on that in the past couple weeks uh there's been some work done into like looking at the interactions with veral um I don't know if someone from the eof camp wants to give a quick update there so people can yeah get up to speed

Danno Ferrin: yeah I'll take it um so yeah we've got uh we're starting to write um execution spec tests we have specific um facilities added in there to test theof um Basu EV m one and reth um have reported they've finished their implementations G is making really good progress um and we're we're the

difficult parts are the parts we expect the validation um has a lot of corner cases that covers test the the tests cover very well um and the operations themselves really aren't terribly difficult um once you once you get well compare to the validation but it's it's it's achievable within you know a single handful of you know months at for a single engineer so that that's R's report from it um I know that uh GM from verl has been speaking with um Daniel from solidity um the when it comes to cutting features from eof my big question is um we can't cut so much that solidity and Viper won't support it in their compilers that

for me is is the point where it becomes viable and nonviable so um G's working with Danny to see what that that point really is um because they're the ones most interested in reducing the scope and reducing the risk in eof I'm comfortable with where it's at now but I accept that other people aren't comfortable with it and um I think that's the right approach to to figure out what the customers really want out of it and what the real minimum standards are um so that's that's a brief update of

EOS

Tim Beiko: thank you um anyone else want to share thoughts or updates okay um oh I

you yeah

Guillaume Ballet: I just want to to give some more details um yes so it's true I've been uh talking about the topic with with Daniel to try to reduce the scope a little bit uh it turns out that yeah it's going to be hard to to cut the scope or at least the the push back that has been given by by Anar especially is that uh yes we could reduce the scope uh but then that means the second version of eof would have to be fairly small or fairly um yeah hard to justify by itself and therefore uh the fear at least I mean Anar can give the argument himself I guess but uh that that would mean that yeah if we have a reduced CF that means

that's the only thing we deliver for for the last for the next five years and uh that pretty much kills the the whole point so yeah we're still trying to find a a sweet spot but it's not going to be very easy to to not ship all of it in one go

Tim Beiko: got it yeah

any way to

Tim Beiko: please go ahead

uh sorry to jump in but is there any way to ship like uh because the the problem is like we're trying to like upgrade the train while it's running right is there any way to like ship experimental versions of eof

that can be iterated on that run in like a

side car we or

Tim Beiko: we discussed something like this like on l2s a few years ago and this was before like the rip process was a thing um I think the concerns from then where um one there's probably some of the like eof work that we want L1 client teams and testing teams and security teams to actually you know thoroughly review um and and so like yeah there there's like a a significant part that it makes sense for L1 to own two is um basically l2's shipping and deprecating a version of eof leaves them with like the T dep forever and you know

that's not something they were super keen on um and then three is like if we have you know something like Dev Nets or or whatnot then it's it's kind of hard to get enough support from like tooling and and and languages and whatnot um so like sure you know we could launch like an eof v1.5 devet but like will solidity and Viper and all that support it that seems unlikely

um uh what if it's like neither what if it's like an L2 that you know the well some set of responsible parties set up that is kind of like a DEET in that it's supposed to be torn down at some time but it's also not

main

net so

Tim Beiko: so the risk is like if yeah either there's either that chain has no value or it has value if it has no value the incentive for tooling to support it feels very low maybe that's changed like maybe there's more tooling providers today but if there's value it's like yeah people's eat can get stuck yeah

why couldn't it have value

Tim Beiko: right so yeah so if you have value on it and then you have it deprecated version of eof and or like a conflicting version of eof and stuff like that um like you you end up in this case where you have actual funds that are stuck potentially in something um and and I don't think anyone just wanted to take on that like

complexity

um I mean if the I think the the issue that I've seen repeatedly in discussions about UF is that uh well it's like not perfect which I actually agree and if if the if the if the goal if the bar is that we need some system that is perfect or at least like very longterm like the nature of these things is that sometimes you don't actually know until they're in production um so uh I I don't know if the the bar the the this must be perfect before you ship it bar is very realistic

Tim Beiko: got it um yeah let's do

G

Guillaume Ballet: yeah so just uh to to give some uh like share share more information from my talk with Daniel and try to answer some of those concerns um basically the the compilers what they want to you know there there's an eof version that's not the like sorry compilers support eof but they support the former version and uh in order to keep maintaining this to be able to produce test Nets and uh and uh try to do some testing and by the way this is a problem we have for veral too because we would like to understand how veral and E interact but there's no way to to test this at this time um I think like what what the compilers want is uh

to have EOS scheduled so um yeah I think we should schedule it for sure I don't think it will come to anybody as a surprise that I think we should schedule for Amsterdam but uh in any case compilers if you want eof to make progress on the on the tooling so that you can actually test it you need to schedule it that has been made very clear by uh by compiler people

yeah yeah I'm I'm pretty aware of what compilers want um so I think that yeah if we can have some kind of middle ground it might be very helpful for um everybody who's working on

it

Tim Beiko: yeah I know that yeah Anar and vitalic have like a thread in the chat about potentially a simplified version um yeah either of you want to give some context on that

Ansgar Dietrichs: yeah I think the idea was just to say that there's two different types of small UF we could ship there's a small UF that would basically be incompatible with the big UF and so it would require us to then ship a separate version of UF later on if we want all the features of pig UF and that has the downset that then forever and ever now layer one has to to support basically raw contracts ufb one and ufb2 and because all of them

exist whereas if we can basically slim down the scope of UF by just removing features that can be later on added to the existing version without breaking things um that like for example right we could initially just not ship a specific op code and then we later on add the op code that usually does not require a new version bump um that makes much more sense because then we can ship small of now and still by later on adding the remaining features we would not need a new version so so so that that variant of of small UF I actually I think is promising

Marius van der Wijden: but is it is it so easy to add a new up code to your because you need to kind of you need to make sure

that

yeah you're

Vitalik Buterin: just add a new up code the same way we add new up codes today right

an eof right and because we have validation

Danno Ferrin: yeah because we have validation we have greater security that that space is there and unused we won't run into nasty side effects like when we're trying to add relative jumps um into the Legacy code that by the way you could put jump test in a in a push zero and every in a push 32 and things suddenly change

um you do need a like version bump because otherwise it won't pass validation

Danno Ferrin: it'll pass multiple levels of

validation you don't have to encode the version in the bite stream but you would have different versions of validation

Marius van der Wijden: um at least for us complexity wise would basically mean because you would have to write new validation that basically copy most of the validation algorithm that

Tim Beiko: right but there's a difference

Marius van der Wijden: I don't know it can be

Tim Beiko: oh sorry you sort of broke up yeah

Marius van der Wijden: it's not a it's not a version bump but it's it's it wouldn't be a version bum that would make the complexity similar at least in our implementation

got it uh Anar

Ansgar Dietrichs: yeah I feel like you were also starting to say this but I just want to point out that there is still a difference in the complexity because it might be the same complexity to for like implementing and adding the these extra features later on but in terms of long-term support right if if you think 10 years from now in one world the

client needs to support three different types of fight code that could it could encounter in the VM and in the other version it only needs to support two different types of fite codes and because the kind of the validation on deployment rules you only have to do if you replay the old history and I think there are all these ideas already that clients in the future might not be just out of the box support replaying the entire history and you might need to have like older versions of the clients for that and everything it basically means in one world you can slim down the rules and forget about these old rules in the other version you have to support them forever so I I do think it still makes a big difference

got

Tim Beiko: um I guess yeah this also feel like something

we're obviously not going to fully specify on this call um there are bi-weekly if not weekly eof calls so I think it probably makes sense to continue the conversation there and then um again as we get ready to consider stuff uh to add the pectra Beyond what's already there um yeah hopefully we we we can make some progress on all those issues for eof um yeah any final comments questions concerns about eof

um going back to this uh sidecar thing that I'm that I'm hung up on um I don't know I I think that l2s might be

interested in doing it if um there were there was a guarantee that under certain conditions it would be merged into main net because I think the issue is like nobody wants to be left holding the bag right main net doesn't want to implement it and then have to like change it later L2 doesn't want to implement it and then like just have it be turn into a you know abandoned or whatever so if there were some way and I maybe this is going to be important like going in the future because of what what is it called like L1 oifc so I think if there's some way to like kind of increasingly escalate uh the stakes involved with it instead of

it being like all of a sudden all or nothing maybe that's another way to do it

Tim Beiko: yeah we can yeah that is the last thing we had on the agenda so let's uh do the comments by ipsilon and then we can move over to that General uh topic around like L1 and L2 governance and feature deployment um yeah

ion

um yeah maybe this wasn't made clear and in today's update uh but on yesterday's uh EF call we did um mostly agreed to simplify the creation question and so there were in the chat there were some discussions uh about eof create and TX TX create h e create is for creating uh new contracts within an existing

contract so like Factory contracts and TX creat is the the external transaction uh creation process the TX create is the the more complicated one and we agreed to go with like a legacy approach which we don't think is the the final ideal case um but the design we have um is actually forward compatible it doesn't require a new transaction type it doesn't require a lot of complexity it is rather simple but it's forward compatible with introducing TX create and a specific transaction type in the future um and I think this was the most contentious uh item in terms of

complexity and it seems we have removed this um so I think we would be curious to learn maybe on on the next UF call which is every Wednesday uh we would be curious to learn what other uh blocking

exist thanks um okay

Tim Beiko: so there yeah uh can someone post the agenda to the next eof call in uh in the chat here or on the alv Discord so people can know uh yeah where to go for those um okay last topic on the agenda so uh this yeah we we've covered this a bunch of times sort of indirectly today uh but

uh L1 versus L2 processes um I guess you know the the question is around how should we think about ethereum l1's road map given that uh you know we want rollups to play larger and larger role um you know can rollups actually ships stuff before what's like the process we can use for something like that um and it might make sense for um Carl and or ongard to start by sharing their thoughts on that given they've been running the roll calls for the past couple months um and yeah we can we can take it from there

Ansgar Dietrichs: yeah I I can I don't know car I

mean I canly say something so um basically we've had this the kind of the Roll Call as like a b kind of experimental forum for for for a while now for half a year bit over half a year already and and the kind of accompanying IP process um the the way to think about it really is to I think there are basically three different dimensions here there's the the the research side there's the governance side and and then the client implementation side um so so on the research side I think we basically we still have an open question of longterm do we want to stick with evm equivalence or not there have been like a lot of kind of arguments on both sides this front but a lot of it hinges on this question so basically there all

these ideas like in the future we could have an enshrined ZK evm on mainnet and then we could have basically enshrined rollups that that natively are verified and everything all of this only works if you have fully equivalent layer TOS that follow the exact same as layer one in that scenario we don't really have to talk about this topic much then we maybe should just talk about how can we have layer twos be more present on aloda so that we can maybe govern the evm together more more more kind of um effectively but if of course we we decide that it's fine that if L toos over time depart from from mainnet evm more and more then the question instead becomes how can we basically enable them to to do that more and there specifically that's it's again it's like governance and and and the client side

and so basically on the governance side I think it's more the question about uh layer twos in the past have been very reluctant to ship features where they basically have the have the wor that main net might either never ship them which is still kind of fine or ship them in a slightly different incompatible wait I think this is usually where they what they're the most afraid of right because then that kind of bats the ecosystem a lot and I feel like for that we really over time need to just make a decision on on layer one to what extent we are willing to take this into into account in our decision making of course layer 2's often make decisions before layer one makes them so to what extent are we willing to basically be bound by Layer Two decisions and the nice thing is that with the R1 pre compile we have

the first candidate where we can just very practically debate all of this so if say next call we want to talk about whether to include the R1 pre compile or not we have all a lot of these practical questions to answer the L tws have already shied we've given them a separate if you remember this from a couple months ago we've given them a separate pre-compile range so now layer TW have shipped the R1 pre-compile at a layer two specific address do we want to take over that address do we want to not take over that address would we even want to maybe say modify the upod the pre-compile behavior or are we willing to say no it's finalized on layer TW we're also going to take it as is and basically ship the same version so I think basically just exercise going through this exercise of of figuring out

to what extent we're willing to basically be somewhat Bound by Layer Two governance on the layer one side I think this would be very helpful for guiding guiding L and then the third one is that that's also a really interesting one so far even though there has been some interest for L to basically start diverging more the main worry they have is that a lot of L twos of course also run layer one clients out of the box for as as their as clients for their for their own chains as well um client developers here is so far el el client developers mostly have focused on on the L1 feature set and so the question is how can we start enabling um chains that don't quite follow um layer one the layer one

feature set um just basically have to still still use these these same clients more so so I think in the past there's been quite a bit of debate like some clients are more open to also like say supporting their two specific features out of the box so for example implementing and supporting IPS uh I know for example from G that there's a bit more skepticism and hesitation about supporting features that are not actually intended for main net um if if if that's not the right path we could also like talk about more standards for extensibility of of of clients but basically we need to find a path forward where actually practically in software in client software these features can be supported otherwise it's it's just a non-starter so basically I think so far our lessons from six months of roll call

these are the three topics research do you want to divert from evm equivalence governance how does layer one interact with the decisions ler 2 makes on evm changes and then on the client side if L to want to actually ship features Beyond layer one how does that actually then end up in code and I don't know car do you have anything is that does it match your your impression

Carl Beekhuizen: yeah I think that's a a pretty good summary of of of of where we are

Tim Beiko: thanks yeah that was that was great um Peter

Péter Szilágyi: so one thing I wanted to react to was uh basically U how we should um approach when layer 2 ship certain features and

when whether we should pick those features up or not I think there's there's a I wouldn't necessarily call it dangerous precon but there's an interesting uh thing there that um if we commit to there to introducing something and then we'll just pick whatever they introduced I think we kind of run the risk of layer 2 is just yoloing in certain things which they want and then they can just point to it basically the one of the dangers is that we kind of um that feature that they ship might be appropriate for them but might be not completely appropriate in general for everybody and then the

question is well since some uh big important layer to ship are we going to basically have everybody use something that's not really appropriate for them just because I don't know optimism rolled with it uh first the other problem that I see is what H for example with precompile well what happens if you have two layer twos which use the same address for different pre compiles I mean how do you solve that because then you cannot actually follow the what layer twos are doing and um and thirdly I think it uh it kind of um I'm not entirely sure we want to end up in a place where basic layer 2os get

to dictate that uh while we shipped it it works so you have to roll with it so I think it's um because of these things I think it it's I would be kind of cautious against uh going down the path of saying that well layer 2x shipped it so we should ship it

Tim Beiko: yeah and I don't think anyone proposed that specifically but I agree this is this would be like a huge huge risk

uh yes there's

Carl Beekhuizen: a huge risk but I also don't think it's anything anyone's trying to do the I don't think the layer twos are trying to ship some weird feature that no one's going to want or whatever and there's no proposal that

whatever ships on l two has to be shipped on L one um I don't think that's that's a realistic concern yet um and I we have to address if if we ever got there I don't think this is a way of layer 2's like coopting and like trying to take over layer one governance I think this is just ler two's trying to have some their own sensible standards for for for this happening um and then to your second point about shipping pre-c compiles at the same address that's like one of the things we want to help prevent with RPS and roll call is like like how do how do we prevent these these these kinds of things from happening because that would that would suck for everyone involved and so it's like part of what

rips are trying to achieve

Péter Szilágyi: so um I definitely agree that I don't think there's an a danger of U layer 2 is necessarily wanting to co-op layer one governance or do anything super mean or and obviously if they were to deploy something uh wonky then obviously there would be no not even a guarante they layer one wouldn't follow them I think the the dangers are the I least the things that I see as potential problems are more in the nuances in the details when as a layer two the the idea the reason why people like layer tws is because layer

twos can experiment they can really go very fast and they can I I wouldn't say break things but the guarantees are a bit different but this kind of also means that layer twos will probably but once they have a solution for their problem they're going to roll with it they will not wait for 100 people to agree whether that solution is the perfect or not for everybody they will just go the with the perfect solution for their specific problem and I think that's the that's the nastier Corner case where for example you have optimism who ships a solution for some quirky problem which isn't perfectly optimal for everybody else but then okay

what do you you do do you so that's that's the issue and I think ler TOS will be actually incentivized to just roll whatever they want with the nuances they want and then just say that well we can't really change it so you just have to roll with it

Marius van der Wijden: I think my bigger concern is what what happens if if uh if rollups just die and walk away and we have we have to keep maintaining the feature because they once needed it but now they've either completely vanished or they have changed their their their their stack to use some different proving mechanism or

whatever and there's a lot of precedent for this where like people came and proposed uh features and pre compiles for exactly their use case and then their use case didn't really work out or they complely died or they moved on to to the next thing and we we are stuck maintaining BN uh the BN curves stuff so L to be and so yeah I I wouldn't like to be in a situ in this situation

here

Tim Beiko: thanks I we're already a bit past time so let's do Puja and Ansgar and

then wrap up

Pooja Ranjan: thank you Tim um I know this is not the best place to discuss the process part but I'm thankful to Anar that he brought up the uh significant element which is um governance here I'm really interested to understand a little bit more about it maybe in short of time we may not be able to do it here right now but it would be very uh interesting to learn about how do we want to see it I I want to congratulate proposal 7212 to be to be um considered for inclusion being CFI but it is rip and we are like when we talk about upgrade we talk about EIP so there are some some details which we may want to iron out I'll be happy to hear

the venue where we can perhaps discuss it with the role of teams generally for eips we discuss it in EIP meeting um but is it something that we should be joining rip calls yeah

um I

Tim Beiko: yeah I don't know that we have a great answer right now Beyond like ACD and rip calls um yeah but yeah I guess we can discuss this async more

um ancar

Ansgar Dietrichs: yeah I just want to briefly respond to what Peter said and and and I just want to say because because I think the impression has always been that V can just experiment and go more wild I think in practice what we've seen is

that most of them decided to not do this or or even at least maybe started doing this and then over time have mostly stopped so now they're really following mostly layer One specs um and I think at least given that you know like the rooll up Cent gr map or something where we kind of all decided this is the best way for the th ecosystem to go I think we at least ow layer two's clear communication about clear guidance and communication about like the the best path forward here like I don't think we necessarily have to be willing to say constraint our own decision set or anything it's more about clearly saying hey if you want to over time deviate from their One features these are the ways in which you can do it these are the ways that you

won't be able to do it and for example maybe it means you'll have to completely for away and you have to run to write your own client maintain your own client you have to maintain your own basically um now now virtual machine and everything H I just feel like in the past this has not been very relevant because ler twos have been mostly focused on just getting the basic rollup stuff ready like the fault proofs and basically like just learning how to walk but now that ler twos are mature they are starting to be more ambitious beyond the constraints of layer one in terms of throughput in terms of additional features so these these topics these questions become more urgent and I do think basically we we owe them uh some guidance so so I don't have any specific proposal or anything I just think we

it's important that we have these conversations and that we figure out a path forward um and just saying they should just keep experimenting is not the right approach because right now they're basically not able to experiment because they don't see a way to do it so I think at least giving Nick making it clear from our side what what the scope would be or what the the the design space would be for them to operate in I think is very important

Tim Beiko: thank you um okay I think we can wrap up here um yeah there's a lot of threads to follow up on async um yeah already a bit over time any final comments or things people things we

should address okay sweet well yeah thanks everyone um yeah I'll post a recap about all this on the R&D Discord and uh there's already a poll up for the time for the account abstraction 3074 breakout room um yeah talk to you all soon

by see thank you thank you you thanks J all

it's J for for

h you for

in oh

time 2

Speaker names adapted from ethereum/pm, CC BY-SA 3.0.