Native Rollups Call #1

Transcript

cool all right uh we're live everyone thank you for coming this is call number one for Native rollups so the the purpose of this call is you know decidedly non-technical we're going to be talking today about pilling educational content further research and open questions so the kinds of things that normies are going to ask about um things that we want to agree on so we're not going to talk too much about definitions today but we're gonna you know ideally have some set of definitions some set of open questions that we can coordinate on um because although I appreciate you know decentralized research I think it's often helpful to have uh channels for collaboration set up even if they don't

end up being uh being end up use so today I have a a very short presentation and I want to make this a very open-ended call um just get kind of community input how can we take native rollups from where they are today uh and ship them to mainnet right that's you know in the end our goal to get there I think we need to convince a few people uh obviously write some code and um you know make some changes to how we think about the uh the social contract that exists in ethereum so uh I'm just going to run through my my presentation and we'll take kind of questions as we go uh yeah let's uh me present um

see cool is my screen visible cool all right so like I said we're talking about ping educational content further research and open questions I'm not going to spend too long in any of those just want to give an overview so the you know the important thing uh for Native rollups is to actually ship a product right these things are are useful as research Concepts just like Bas rollups are but until we start going to main that like fet and taoh have for base rollups um then these are just ideas and they're not actually helping real users and so there's a few I guess uh kind of roles I think we need to convince the first is

ethereum layer twos so this is existing layer twos this is people who are launching new layer twos this is apps that want to launch their own app Chens so on and so forth right um and we need to convince them to launch native right to become native rups uh or to migrate to being native so go from existing offchain execution with fraud proofs or another Z KPM and transition to using native RS so um that's that's kind of the the goal for ethereum layer 2s our progress on this front has been um pretty solid so far we have interests from some major layer 2 players we have commitments from my own team Spire from other kind of development shops to start working on

actually making native rups real writing the code for that uh and so I think we've made a lot of progress on that side one other area is ethereum validators so um there's all sorts of validators to talk to different classes here we obviously have uh solo stickers we have larger node operators um we have to think about you know lsts versus kind of private stakers and I think the um you know the goal of uh of specifically ethereum validators is to convince them to you know make the necessary changes to their setup to support native rops you know if that means changing Hardware requirements you know coordinating with the approver network deciding which um kind of zkm to to use or to attest to uh

there's a I guess a set of things that validators will need to make choices about um and I think the most important of that is related to hardworking ethereum so we need to get validators to to upgrade their known software to a version of ethereum that supports native rups um the the third here is ethereum cevs so obviously the the process for upgrading ethereum the EIP process is is controlled by the allore dev calls um and this is how a lot of like prioritization and decision- making happens in ethereum for for this discussion uh the key you know thing for us is to write an EIP get EIP into a hard Fork right I think fusaka is still reasonable for for re execution um you

know if we limit the scope of the EIP to just uh an onchain OP code um but it's very possible that that will happen in the har Fork after fusaka um and then right here in the middle is I think some of the most important actors is the broader ethereum Community right so this is eth bag holders this is um you know just the kind of people who listen to The Daily way right uh ethereum people who are in ethereum for the the tech for the people Etc so so on so forth and um you know usually these people don't take a lot of convincing um if there's you know charismatic strong leaders that are pushing something like Justin for

example um and so I don't think this will take too much trouble but one thing that we we saw with basss at least is that people were like generally in support of the idea but had very little uh I guess understanding of what Bas rups actually entailed in practice um and so part of the goal with this call is to set up um channels to produce educational content for the ethereum community to learn what are native rollups what are the impacts what is it actually going to look like in practice answering frequently asked questions things like this uh in a way that is hopefully um enough to you know have arrows pointing out from ethereum community enough to convince validators layer tws and cevs to kind of consider um how they can uh you know make

decisions that are helpful for Native robes so that's ping do we have any uh any questions or thoughts on there Justin do you want to say a few words um no just this that makes sense so far um I'm actually on the bus in the French fountains I'm about to go tomorrow so uh yeah sorry if I not back to time no problem no problem uh cool okay let's go go to the next slide here so the the talking about educational content again for a second um I think there's a few kind of I have

eight here but a few categories that we just really want to nail down um and so if I was making a Content strategy I would focus an article or a podcast on each one of these and try to narrow down on um each one explain it for you know a Normy audience um so I'll just kind of walk through them and give a few sentences of kind of what I'm describing roughly in terms of benefits um we have four big ones uh Justin outlined five in his uh in is native for up post I think these are the four that resonated the most with me U but there's you know there's certainly more that that could be added here this not a comprehensive list by any means the first one is security so you know to put it simply uh we are enshrining the um security

properties of rollups at least their AVM execution into the e eum social contract right and so if if it was possible um to hack a a native rollup or you know a native rollup did get exploited God forbid then the security um you know social contract would require that ethereum hard Forks to uh to protect that from happening and so the the uh I guess the key point about security is that a native rollup designed correctly can be as secure as ethereum have the same uh security assumptions um and a offene execution roll up can can you know can never achieve that at least within the kind of local

perspective of ethereum the second one is composability so I believe the um the key property here is that with an execution engine op code if you're using that for execution you can kind of shape and customize your um the way that you're proving Works to actually uh essentially emulate real time proving so you know because we have off chain proofs uh the validity of an ethereum block is um dependent on the validity of proofs being generated and um you know therefore it must be possible to generate a valid proof and so what we're doing is we're kind of building the the native rollup um proving into uh the ethereum block validity and so the

the rollup can assume validity of execution of transactions they assume a state transition or a state output and use that to do um all sorts of composability on layer one so there's teams working on this um I know Gwyneth showed a super cool demo uh of doing composability between layer one and Layer Two doing a swamp between chains um and this is something that would you know would greatly help with that right as we try to move towards faster and and more secure forms of proving for rollups um the other thing on here is sustained compatibility and uh this is you know roughly the idea that uh Native rollups can maintain compatibility with a layer one evm without upgrading or changing anything else so uh this is I

think this is a super power some people might disagree but the um one of the issues with moving to stage two today for for existing layer use is um if you aify the protocol um and make some you know oif even Beyond stage two then your compatibility with ethereum will you know will disappear if ethereum you know executes some breaking change or some non-breaking change that just changes how developers interact with ethereum right and so if you know random example Teo decided to aify their evm right now then ethereum added eof then developers on ethereum would have a different experience than than those on Tao and you know this leads to all sorts of

issues but U mostly it's just a bad developer experience the the fourth one is Simplicity I think this is uh going going to be underappreciated and over appreciated the nice thing about Simplicity is at least for Native rollups is that spinning up a roll up no longer requires um you know Guardians to check for fraud proof it doesn't require a network of provs you're essentially inheriting and reusing the resources that etherum has gathered I believe the same property applies to base sequencing um but it's it's just using what's already out there to to launch rooll up so the I guess the end goal for something like Simplicity is to launch a ethereum based native rollup or an ultrasound rollup with just a contract

call right we can imagine using these for very ephemeral purposes we can imagine them being long-term U but essentially changing the construction of uh how how rollups get launched so another thing um another broad category here is is what to expect uh but before we get to that I want to hear feedback on benefits if there's any kind of changes that people would make here um and what are people thinking about the benefits outlined I mean I I'll say something quickly I mean I think there's absolutely correct I think if you're talking about educating people you know you've got to wait these benefits somehow in terms of what Native rollup specifically can

provide because you know I think there are some like real black and white differences when it comes to something like security uh but when it comes to something like sustained compatibility it's like well how big of a deal you you know actually uh is that so I think maybe my my only question would be if you had to like you know change the sizes of these to reflect the messaging uh how the messaging should go like what would those sort of sizes uh be yeah that's a great question I think security is should definitely be the largest box you know take up 50% of this it is you know it's going to accelerate the native excuse me the the rollup Centric road map just by changing the trust assumptions of Larry 2os um for composability

it's it's not so much a size as it is like a timeline we can get faster composability with Native rollups or faster secure composability instead of having to rely on like te approving or something that you know people would consider less secure um so you know I think of that as as a timeline thing for sustained compatibility I I believe this is the only way to aify um a you know execution protocol and still maintain compatibility with ethereum and so I think that you know the the here is like how important is oif I don't have a great answer for that I think there's good reasons to aify L toos especially when it comes to like security uh but something like an exit window can can get you a decent bit of the way there so I may make that a

smaller box and then Simplicity is not something I'm sold on yet uh I think it is it's good to have that option but I'm not sure how much uh it will be used without you know some pretty major changes to to how we think about it like what is a roll up and what is a layer two does that answer your question yeah no that's that's that's helpful thank you cool any other thoughts here any other benefits people are thinking about what's the benefit you you left out which didn't resonate with you just to recall um oh I'm trying to remember let me check real

quick it was see it was gas cost right so just in outlines that verifying snarks on Chan is expensive um and therefore rups choose to settle INF frequently with something like the execute promile you could you know you're obviously not verifying uh snarks on chain and so that the cost could theoretically be lower I uh yeah I don't know how much that could be offset um obviously by uh settling more frequently into layer one you could be paying for da more I think to honestly tell how much costs are going to change

like you know in terms of bottom line we're going to have to actually do some experimentation and you know ship some of this stuff I mean on the cost ultimately um you have to charge for whatever the validator work is uh but the nice thing is that you can do group aggregation at the layer one level as opposed to having to coordinates l2s to to share proof systems and share infrastructure there yeah that's a that's a great point I mean I think there's that's one of the other benefits I guess is that you you now have a central coordination point for everything you might want to do for proving for the depring um be that you know different proof systems different

VMS uh you know obviously be that like preaggregation and some other some other kind of related things I think that's going to be you know a massive as well cool anything else yeah I guess another thing I would say is just you know in some sense right everyone is trying to choose what to do trying to choose what to work on trying to use what roll up what stack to use and so I think there is this awkward question about like the comparison you know it's like right okay you're secure are you more secure you know like there is a big big like you know I wouldn't call like a propaganda apparatus but like some kind of apparatus around St stage two right you're done when you get there obviously you can get to stage two

uh without being a native rollup and so I think if we're going to come out and say and I really do believe this that a native rollup uh stage two is like a trillion times more secure than a non-native rollup stage two then I think that kind of comparative Point uh needs to be made because if you're just looking at you'll say great that's another way to get to perfect security which is what the marketing machine tells me that stage two is so it's tied and so why do we need a new thing yeah I mean I think the my takeaway at least around security is that you don't automatically get security by being a native rollup you only get security of your uh kind of state transition your your or you know some subset of it perhaps um depends on how how much of the op code you use and

for what and so if you're using just you know the the pure execute engine op code for all of your evm execution then your security for that part of the rollup is going to be from you know the local perspective of ethereum at least going to be better than any form of offchain ZK any form of fraud Bruce just because of how it's encoded into the the social contract right after that I mean I don't want to um take any positions on the whole stage two thing I think there's there's a uh I guess a whole lot of risks and security um kind of questions that we need to answer for rups that are not just around St transition but are around you know more than that right so yeah

I'll leave it there cool let's go into what to expect um so I think this is should be thought of almost like a frequently asked questions for people who are see this on their Twitter feed for their first time and want to know you know are native rollups just another product of the ethereum you know research heads or is this something I should care about right how is this going to make my experience better how should I think about this is this competing with the layer twos that I love am I going to have to run aover right things like this um and so what I think we can do about this is just you know straightforward spin up some educational resources um put these on ethereum.org has whole directory of

ethereum resource that could be a good starting point there's other ways to um host resources as well happy to kind of support some of those Aspire um but at least we we want to answer I guess a few big questions that I I expect uh will will come up so offchain execution layer 2os which is every Layer Two that exists right now um is uh I guess exists in a state where some of them are interested in moving to Native rups some of them have kind of softc committed um depending on certain things and we want to make it clear uh especially here that migration from an offchain extion layer to to an onchain execution layer too or a native rup is

possible right and we even expect so um this will depend on larger layer twos and their commitments to doing certain things but I think I would love to see an effort from uh you know people who represent optimism arbitrum Etc in this call um you know let's let's make it clear that native rollups are not going to compete with like fraud proof systems right these games are ultimately um something that is compatible with with a migration um so yeah let's talk about kind of launching new layer twos I think the um the important thing to touch on here is that uh Native robs kind of fundamentally change how I think about layer to design uh one of them is you

don't have to bootstrap a proba prooof network um I I remember on Twitter poos was talking about um he was replying to someone and and essentially what he was saying is that while we could fork arbitrum and call it you know ARB 2 and just add an exit window um it would be a stage to roll up right but the if you design it right but the security of this theortical arb2 would be dramatically lower than arum even as it is today right because you you know arrum has a you know a bunch of Guardians who are watching out for their F fault proving um they have a whole system of infrastructure built around the security of Rob and so um for something like launching new layer twos I think that's

a a just a consideration um cool so let's uh let's talk about hard forking for NXT do code so this is the one big like Community rallying point this is the merge for Native rups uh the beam chain for Native rups is we need to get the execute op code into ethereum through a hard Fork um and obviously we need to convince allore devs we need to write this EIP can't just uh add it without EIP and so um this is something that we need to communicate very clearly is the the goal for Native robs we need to launch native robs to Main and to do that we need to actually hard Fork ethereum so that that should be I guess a clear expectation is that our goal is not to do something

like what based rups are doing and just augment ethereum today it's actually to to change ethereum to provide a service execution to to layer to um the other thing I want to talk about is kind of proving and how does staking and and validating the network change are there any you know new node requirements are there any new attesting requirements right I think that'll definitely be a yes um and yeah and then of course how we think about proving right are we are we favoring any uh ZK VM right are we are we you know enshrining anything here what are the um I guess what are the security properties of anything that we enshrine how do we affect ethereum things like this are all are all

questions that we need answers to um you know they don't have to be comprehensive but this is not the kind of thing that we can we can just leave up to speculation right we have to get some kind of Baseline agreement on these these core ideas and we can keep branching out from there all right uh that is what to expect do we have any thoughts on this kind of like fi FAQ idea or kind of ideas for uh educating people yeah I I was thinking so I like the benefits and the what to expect I was thinking something more on the drawbox side maybe that can fall into the what to expect bucket because I noticed when Bas rollups were now coming about they were heralded as this great thing and then is is only later what

they say oh you need like pre-confirmation you need a layer for this you needed to make the L1 a little bit faster so all of these things came out as kind of like gas from from other people in the community so if you could just be like upfront with the tradeoffs let's just say from the GG go maybe any what to expect bucket I think that's something that's needed yeah so I mean the way I tried to categorize here was like here's why you should like native rollups and then here's like you know if you do like native rollups you need to know this this and this this may help you inform your decision as well um there are a set of drawbacks for Native rollups that we we should take the time to discuss um I think generally they're net positive over offchain is execution um I think

they or for layer twos at least I don't know about for ethereum um I think there are some very serious concerns about um drawbacks in terms of timelines like if we launch with re-execution maybe re-execution has different trade-offs than uh a sarfi give a ro of environment um yeah that's a that's a great call it we should definitely highlight that in what to expect I I have a small comment regarding the snar ification on ZK on Native rollups as a CK big fan I'm really worried and I have been saying that publicly uh in with the current dynamics that exist in ZK uh particularly if that gets uh into native I I think uh very

smart people have been working for the last five six years to make ZK very fast it's becoming very very fast but now there's a huge fight to go to market on be the like on winning at the end with RIS five uh VMS and I think that's going to accelerate uh literally two or three days ago uh Pico breis launched um a modification to sp1 that made made things almost two to three times faster and they were not even part of the race so what I'm trying to say with that is that even people that were not didn't exist six months ago are the ones like they the company did exist and they're a

h I'm a huge fan of their work but that shows you that the current trend is that things are moving very very fast on one thing that I'm worried about and I'm putting quite some capital I didn't show I don't this is is this recorded on public I don't know like if it's recorded I cannot say the number but we put uh a lot of money to find the bug in sp1 and one of the reasons we did that uh is because we're worried it's not that we're just worried when we say it it's we're putting our head some time into that because if this becomes part of uh eum core um yeah the way eum works by default I think there can be a problem

where if any of these zvm have a soundless bag uh we will be all in like similar situation to the the uh dowo hack so I'm just sharing my concerns and I have been like trying to show it with concrete code on hacks on I think that's going to get repeated on also to share the incentives only to find those bags for like 50k the the cost was way higher so if we do that there needs to be a clear plan as a ZK person I am more bullish and Native on the non ZK part on the re execution and on the ZK until we have a clear and this is somebody I I I believe in the beam chain in ZK and all like it's just I'm worried because of

the market dynamics yeah so you said a few really preent things there I think um especially around like security there's there's things that we we don't know now and that will 100% change in the next year you know before native robs go live um we need to be very particular and specific about you of what zpms we you know include that we require from conclusion is there a minimum do we try to formally verify one um I know we had some some discussion on the first call about uh how should we frame like the diversity of z kvms uh is it is it important so on and so forth um I know Justin has some changing thoughts here

so I won't comment there but I think the um I think these questions need to be answered I mean I think it'd be really helpful if you fetty could just write up like what is a list of the the questions that we need to answer what are like the requirements um and I guess suggestions that that would be best to go about this um that'd be that'd be a great resource just for thinking about this U and then one other thing like beam chain is also facing these same kind of games I guess right you're gonna have all of these beam chain clients who are obviously all these ckvm as well for for beam chain um but they're on a much longer timeline I hope than than robs right and so I hope

we can share resources with the beam chain effort I mean Justin's obviously the right guy to do that with uh but figuring out how to uh you know how to be very clear about the the timelines and the trade-offs at each point especially with regards to the ZK element is something we we absolutely need to clarify and I I love your guidance on cool um I'm sorry uh I actually had a like uh one question about what to expect so like the whole roll up idea is to scale the ethereum network and like from what I understood is the execute of code um will be limited by by the lwan

exe execution uh limit so I think it's also important to highlight if if like this is going to be something that is super scalable like what we have current uh offchain execution l2s uh otherwise like without ZK I just don't know like how this can be scaled without scaling the L1 itself um so yeah this is just a general question but also uh implify in the what expect yeah that's that's a really good call it here I think um h i I'll definitely do some thinking on that and and put some um put some

writing down on paper about that I think there's I guess scalability is tricky because there's like a few different type of like uh ways you could use the execution engine op code and they each have their kind of different scalability um trade-offs and and obviously limits and so if we're doing a native rule up we're I I I would say I mean I'd be willing to say we're not going to be constrained by the execution but rather by da um if we're doing a optimistic Layer Two that uses the xed engine op code for for its you know in its fraud proof game um then I think it's you know very likely that we will um that we will be constrained by the op code and not by da right because we use some multi for that um and so yeah I

mean it we need to do a little bit more research on the effects of the op code on validators before we make any strong promises about this but I do believe that native rollups will be dramatically more scalable than ethereum and um ultimately a uh the only way to scale ethereum's trust properties the form of of security to to robs and so you know if you think that you know doubling ethereum's gas limit is is going to be valuable for ethereum then that's one way that we can extend the security umbrella of ethereum and its social contract or if you think Native Rob's can 100x that um then I think it's two sides of the of the same coin J do you have any any thoughts on

this the one thing that that comes to mind is that um if you're working with an optimistic rollup and you only call a pre-compile in the for prooof game then yeah you you you have unbounded effectively unbounded uh limit at the at the L2 layer and the only the only limit is Da a and if you to become an optimium and have Alda then you're essentially unlimited there as well so for you know a large class of applications that don't necessarily need the super high grade security or the super high grade composability then ethereum is

effectively you know unlimited yeah I mean I I definitely agree there I don't think every rollup will will be native just like I don't think every rollup will be based I definitely don't think every Layer Two will be native or based um I think there's there's going always going to exist you know high performance chains that use Alda that use fraud proofs maybe they use the ex engine op code at some point um you know as optimums I just don't know so you know I'm very willing to accept the um the idea that we do have different kind of classes of layer different types of scalability there's some layer 2os that you know maybe have dramatically higher

scalability than U than we have today for for ler twos I think that's a very reasonable assumption um and I think the the native execution engine op code could definitely be a part of that I don't think that's going to be the bottleneck cool so uh you guys are the first to hear about a new telegram group that I have created earlier today uh with the single goal of kind of filling a hole that we unfor did not have for base rollups it's a place that you can ping people and get pinged and not feel bad about it uh for Content review so if you're writing a draft for something about Native rollups that you know is research on Native rollups or discusses native rollups um as a kind of

educational content area then this is the perfect place to do it and like I said before don't don't feel uh don't feel bad about pinging people so um yeah I've just created the script let me just um put in the in the main native rollup Telegram and feel free to to join looks like people are streaming in um

yeah so anyway like I said before the goal is to provide review and feedback for educational content um and research specifically about Native rollups um for anyone who's watching this call on a recording and wants to get that review and feedback then uh this group is this group is open please reach out to me on Twitter at M is loading or on telegram at m888 um I'm sure other people will be able to to invite you as well if I'm not available um yeah and you know absolutely don't feel don't feel afraid to to reach out we want this to be a resource to anyone who's doing doing God's work of um of writing for education or for research cool and then I also listed out just off the top of my head some kind of

open research areas um and so I want to just like kind of run through these briefly I think the you know these are not very specific and I guess some of these are more specific than the categories that they find themselves a part of um but these are just a few things I think about for uh for research around native rops um one of them obviously is specking for an OP code we need to figure out can we put this in EIP what are you know what do we care about in terms of how the outcode actually looks um I know Justin outlined something in his in his uh Native Ro post on eth research but getting something a little bit more specific here would be great kind of a draft EIP would be a good place to start um I know there's a group working on

implementation details you who's explicitly working on this and I'd love to to continue the research there if you're watching the recording um and you'd like to contribute this is absolutely a space that it you know we'd love input on for VM flexibility this is one that um I there's a few people who feel strongly about I guess uh so part of this is um you know layer Twos for example have a lot of differences to the layer 1 evm as it exists today and so the stock evm might not be best for them right or some compromise might not be best for them and so giving rollups the ability to um you know change their VM to add custom pre- compiles to add custom op codes is something that we I

personally would like to support um although possibly not with the same security assumptions as as Alternatives um there are you know one way kind of previously suggested to do this is that the the native uh execution engine op code proves everything except for precompilers it's not familiar with and then for those um you just have to bring your own Pro for the rest right I verify that in a l one contract use some ZK use a fra proof game whatever um and yeah and this you know this does kind of change how we think about security assumptions but it's a way to support this um something I I don't view as a requirement for getting native robs

through but something I know other people do um and so it's something we should definitely put a little more time into researching um Okay cool so single versus multiple zkm implementations this is uh I'm sure something that will get discussed and debated in the future but doing a single kind of formally verified ckvm versus multiple different ckvm um which one we choose so and so forth something fetty obviously cares about um and something that I just want to make sure we get right so yeah let's spend more time on that for this is a big I think for for the scker side is we need to figure out how much or how layer one gas is impacted here uh and specifically how L one validators and proposers and

ATT testers uh how resource usage changes so I imagine that re-execution faces some um I guess present some changes to how ATT testers um need to to kind of allocate resources for their knows I also believe that um doing gas Management on layer one you know doing EIP 1559 mechanism for Native R gas for you know some sort of gas limit is this something um like the gas limit that can be voted on by validators or is it something like blobs that is as of now kind of a protocol parameter um so yeah a place that there's a broad umbrella I guess around research we need to do into kind of modifications for for stakers and kind

of what to expect on the layer one level another one is proving improvers so um how do we think about incentivization for approvers and this is like specifically at block proposal time once a block has been proposed do we need a proof from the proposer do we need appr proof from um you know from entities that are elected by ethereum um probably not do we want you know proving to be permissionless I think ideally but we need to think about that um in terms of incentivization so I think one way that people think about this is that uh proving will be incentivized just through altruism right so if we have one honest PR somewhere in the world then

that that should be enough um and ideally we'll just have lots of uh layer two teams lots of research teams running these uh something we just need to um be very clear we have the right assumptions about the other one related to that around proving at least is kind of proving latency and proving cost um how much does proving cost which Hardware what Hardware do you need to prove is it a requirement that you can prove it on a you know next Generation MW Pro um questions we should be asking um in terms of uh another interesting one I think migration is one that we need to absolutely need to get right um around technical uh of course so how do we actually like just like

swap out fraud proofs for uh execution engine op code um and also incentives so what exists in terms of community pressures are there bounties that teams are willing to put up for uh for rollups actually becoming native so yeah um let's uh let's get some feedback on here do we have any thoughts on open research would anyone like to I guess volunteer to put some time into any of these that'd be great cool all right we can come back to oh go

ahead sorry apies yeah sorry I just did it at the same time uh does anyone have any ideas about how much additional resources will be needed for re-execution so my concrete proposal would be to have a tiny gas limit initially for re execution something maybe nominal like 1 million gas um and the reason is that it would unlock at the very least the optimistic rollups with uh with unlimited uh gas limit because they can just call the

execute precompile in in the fullprof game in in in 1 million gas increments it's possible for technical reasons that you know 1 million is the wrong number because there's some sort of edge case that I'm not thinking about and you know just more convenient to have 10 million for example but something small would be sufficient to rollups uh right so then this would mean that the testers will not need uh any additional Hardware requirements uh from what they have right now yes especially that the hardware usage today is more likely than not uh

you know the hardware is underutilized and the reason is that if you know evm execution single threaded and you have a multi-core CPU then you might not be using all of your cores and it's relatively easy to parallelize verification of the execute pre compile yeah that's a that's a good one Justin I think the additional uh well at least for like a native roll up um that uses ethereum for da you're not going to have greater bandwidth requirements right um and I don't think you will have uh you know dramatic changes to to state depending on how the opcode is designed but um I

think your your your biggest one is just going to be execution and you know CPU cycles and as of now that is definitely underutilized resource for for a lot of uh Hardware setups um and so something I feel comfortable with one one thing that I personally imagine as a direction that may be useful is uh is getting the op code into you know fusaka or the fork after that um with a with a gas limit of like zero so it's like effectively useless um but then and setting some like protocol defined threshold for activating that without requiring a hard Fork um and it's something that I

imagine could be uh just a way to get the onchain interface done without having to increase validator hard requirements at all um so yeah something I've been thinking about um I think to get it into F Saka you likely need an EIP very soon and then to um like put it up for inclusion uh quite soon I agreed yeah I mean fusaka I guess it's still not clear to me when faga will actually happen um I know there are people that want it to be a small fork and some who want it to be a very large Fork um and I I'm not tapped into the

ACDC uh process enough to understand like which Camp is winning at the moment um so yeah but I I definitely agree there's there's a sense of urgency here um I had one question about the ZK vers um so does that require delayed execution in order to give the theover enough time to actually create these proofs do you mean um for like State R computation uh just to create the ZK VM proofs uh so yeah I mean I think the I think the how would kind of

rephrase your question is is do we need um serial calculation delay which is another EIP um to get some of these properties and I would say the answer is no um what we're what we're doing is moving the the verification of the op cod's execution into the attestation stage of the block right and you know of course this is independently verifiable by by anyone running a node and and you know who's able to reexecute if they want to see you know what's going on they don't need to wait for proofs the proofs are just for consensus um and so in that regard like you don't need to um here's how I would put it to to

check the validity of a block um from within the evm so if you're doing things like composability you need to know that your state transition of the followup was valid you don't need to um you don't need to have delayed execution you can just consider the uh the op code kind of executed uh if your if your evm code maybe another contract doing composability if that actually gets finalized on ethereum then that means the the whatever happened in the native ra to say transition must have been valid so I guess there was a confusing way of explaining it but um your your local perspective of the current ethereum block is um I guess is not dependent on delayed execution does

that kind of answer your question um yeah I think so I think you're saying that uh if the block is seen as valid you can assume that the execute function uh ex uh if I was to verify the proof that came with the execute function it would verify true um my question was more around the time to create these proofs and it seems like you're saying you can just ignore you can ignore the proof from what I understand you you don't need to but you want to so it's not it depends on the Block time the relationship between the block time of Del two the proving time uh but you don't have to do it it's just

like you want to do it so that the block can be produced uh even if the proving is not yet done I don't know if I'm explaining myself correctly but what I'm trying to say is like you don't need logically to have a delayed execution but you want to have it like so that uh the black production on the one is not delayed by The Proving and you can have more time to prove because also the proving the more the bigger the size of what you're proving the better because in most cases it's log square of n or log n or like so the bigger the better TDR you don't need it you want it right okay I see so the validity of the block is not dependent on those proofs that

come with it right yeah I mean that's that's the the key about offchain proofs is the validity of the block um or you know even the finality of the block when we start to get access stations is not going to be dependent on on those proofs so yeah just to kind of summarize here I think the one of the major benefits of native Ops is that our proving time can be longer than real time can be up to the slot time or or close to it um because we can start generating those proofs after the ethereum block is proposed um and you know then we have some some wiggle room for sure when it comes to to proving latency 12 seconds isn't a long

time for for proving by any means but it's it's a lot better than like 200 milliseconds good um one more one more potential benefit I feel Worth to explore is uh how Revenue model may change with the native rollups at least with the re-execution it sort of falls into incentive section but one of the big concerns in community currently that existing layer tws do not contribute enough Revenue to layer one and if native RS may change

the picture at least with the re-execution I would mark it as a benefit yeah I'll give you my own personal opinion I think it's important for ethereum to focus on value creation and not value acral um at this current point in time I believe NATO rollups are a way to export ethereum security um and you know align themselves pretty well with the kind of like eth Centric rollup Centric road map that we want to support um there I think it is theoretically possible to enshrine eth as the gas token of uh of native rups um if you really wanted to I don't think that's something that makes a ton of sense but

um yeah at the end of the day I think Native rups could could slightly change the the short-term value gr for ethereum in terms of like uh I guess Revenue isn't the right word but like eth burned um or or gas fees contributed to validators but at the same time and this was in Justin post at the same time the value distribution today also pays for a lot of stuff and I think that's question maybe in open research areas maybe in like a uh you know the what to expect on the potential downside you know if uh we're not doing that as much and if we are bringing uh if we are trying to minimize governance which I don't know

if that's actually a a a goal here because the initial uh execute notion right doesn't totally minimize governance but if you're trying to minimize governance um and you're trying to remove power from uh the people running existing rollups and uh you know is that going to Dev value the governance tokens that are used for Grants and are presently trying to grow in importance and grow in value and uh you know this was a Justin post but I think that's kind of another question of like if you're trying to get something that's like better in these ways uh who's going to uh pay for it basically yeah I mean the governance token is ultimately tangential to the um to the security I think like you can

have a governance vote whether to migrate to or from being a native rup um I think that's something that is not excluded by by being native or or using the pre- compiler for something um I think rollups will have a diverse set of like value acral mechanisms some will have a governance token for protocol upgrades um some of them will have uh you know first party applications so we had app chains I think we'll have chain apps um I don't know I I see this this being a set of models that is not going to be excluded or or or limited or constrained by the by native Wes but just pin on that a little if you have upgrades that are needed now to support a variety of

things that uh will go away and uh those upgrades are driven by you know governance that has tokens involved and people are really passionate about being able to prevent those upgrades from hurting things and the governance token is really part of that if you remove all of that if you say there's no governance required now in an extreme case then at least in that case you would affect the value of you know assets and and what people have uh you know put time and money into building like it would hurt the value of the governance token if you didn't need it anymore even if that's better overall can I uh jump in I I think you're so I think there's nothing preventing like L existing l2s that migrate to become a native rup from

upgrading like as a native rup I think what you're actually getting out is if you're not just delegating like consensus security but like the execution layer security to validators like maybe your point is that like if they can't continue to experiment they effectively there's no reason to upgrade um and so that that sort of devalues the governance took in a in a sense so I mean I I would say like the the execute precompile should be designed in a way where they could continue to experiment on execution and if they want to they can you know migrate like deploy a new contract on L1 uh and have some kind of up upgrade mechanism and use new pre-c compiles Etc

so I don't know is that is that sort of what your concern is um like the the execution experimentation side or is it something different I think in part I mean I just think it's it's sold right as a benefit like security councils right like that's the thing that everyone doesn't like those are bad uh and this is sold as being like a way of avoiding them because you don't need to keep these upgradeable contracts you don't need to keep upgrading them and um the generalized version of Security Council is governance and the people involved in that and the tokens involved in that and so you know are I believe in this but is the native role movement a movement that is a movement about government minimization and then governance minimization then that has

other costs or is this movement basically saying you know security councils are fine you know Dow's running things are fine but here's another way to uh to do it my personal view is that it should be a governance minimization movement but I think that is a you know big change from from you know where the power exists today basically yeah yeah Tom I think uh I'm obviously not a a dictator on this matter at all but I think um as a movement we should attempt to remain neutral on anything that is like that's tangential to um the extion engine op code itself I believe that we want to create better ways to do government minimization right so if you

want sustained compatibility with ethereum and you want governance minimization or or alific um then we want to create that option and this does create that option um but you know making moral judgments on is this correct or or or better or good um I think is something we should we should avoid but yeah that's just my personal opinion one thing I'll add about upgrades is that uh governance tokens can control a lot more than just like execution so I think probably the best example is around sequencing to to choose the sequencing for a chain is an exceptionally valuable thing right centralized signatur could capture millions of dollars um they even do in practice today and if they were

extractive for me they could you know get a lot more out of the chance that they sequence and so governance tokens if you you know if you want to speculate that their value is based on um you know the the revenue that they could extract from from a chain by making decisions about it then I think sequencing is something that is actually going to be dramatically more important than um than execution but maybe that's just me just to press you on this a little bit though right like you've got to make moral judgments at some point like today if you look at all of the super chain chains not to call it the super chain just randomly right uh all of them can be shut down like with 15 signatures and I would say I'm willing to say that's not good right and so is that not good

or is that fine and then okay that's not good then is having them all powered by a market cap token you know having them rest on the attack ability of a token whose market cap is two billion or 10 billion or something is that fine so I just think we gotta be able to say some things are good and some things are bad if we're going to convince people right we have to say secur you know 15 signatures is too few in fact you should ever be able to shut down a a good rollup I mean right or I don't know trying to pin you out a little bit um my I want to like separate my personal opinion from that of of the movement as a whole and for Native rups um I personally believe that uh that security

councils stage one rollups are a stepping stone and um training wheels for what rollups eventually will be I think that it is dangerous to um uh I guess dangerous to frame like the security councils are good argument as security councils are good forever I would try to make it much more clear that um I think people who are advocating for security councils people who are own those security councils major layer toos are looking especially at um using security councils uh until you know other forms of government mization perhaps or or security are available and so uh perhaps this ends up

being a timeline debate like you know everything else in crypto uh doesn't make sense to move away from a security Council now or doesn't make sense to wait um and and I guess I'm not sure how much um how strongly people feel about this but I I do think that uh it is better to launch with Security Council than to not launch at all right for something like there's going to be an infinite um you know range of trade-offs um for layer twos and rollups and you know I think that some will migrate you know um for reasons that they're losing market share or some will decide not to right because of you know again like I think it's strange that

people the people were seemingly so surprised by the Sony you know Enterprise chain right like you know representing kind of the the Enterprise side here or and the finance side you know we you know most uh banks in the future in fex are going to have rollups they probably won't be native right but they're going to have entirely opposite spectrum of tradeoffs um and risk assumption you know these types of uh assumptions than than a maximally you know public and permissionless uh Native or even ultrasound rollup and so I think you just I would just have a you know keep a wide aperture in terms of this and I think I agree with Matthew we shouldn't

be too judgmental um in the short term especially yeah agree there Kev you put something in the chat um I think in an Ideal World we wouldn't need security councils right and I I agree with that I think the the question is uh do we live in in an Ideal World um and when can we get to that ideal when can we get to good enough right I think Native robs are way there um I would agree we don't want security councils and and iide would we shouldn't need them uh and wouldn't need them but I want to actually make that happen uh cool so let's uh uh let's go to the next slide here um I want to talk about nups the future so I have some

Milestones laid out here this is the last slide um and we're just going to finish up this section um and specifically talk about kind of how I see mileston sping out for Native rups it's my personal kind of opinion here um I want to write an EIP for the execute op code obviously to do this we need to agree on what the op code should include um max can you please make this happen um need to write code to use that execute op code as the execution for a rollup so this you know can happen on a test net for sure I can happen without xop code actually existing um but I just want to you know make sure we're we're getting there these are not necessarily in order uh by the way I want to get an

EIP on test Nets so uh obviously public test Nets but also some some Dev Nets um and of course approved by all core devs for faka fusaka you know cross your finger but you know I think more likely for the fork after that um and then of course the the big milestone is ethereum hard Forks to support native rollups I think uh I think this will happen I I really hope it will happen um and that is our our most important Milestone and then after that I expect to see a blossoming of native rups so I we'll see the first Native rup and then from there um I expect we'll see migrations and um and new rollups launching as native so yeah these are my are my set of milestones

here um we are overtime on the call so I'm going to open up for just a couple more minutes of questions and then we're going to stop recording and go to the the private segment I'll just ask a quick question I think first of this looks great I agree with it um I know I'm you know trying to push some buttons a moment ago but I will ask this on the road map you know if we Zoom back right there's this question of like the execute op code and that's going to help us verify the evm but the rollup State transition function includes more than just the evm there's a bunch of other stuff there's all the you know debate on that and so you know for me uh from my perspective if you have the ability for the uh L1 to verify the entire State

transition function that means you don't need the upgradeable smart contracts uh for the bridge which means you're done we're in Paradise but if you only have verification on the evm side you still need the upgradeable smart contracts you're not quite in Paradise yet even though it's pretty good so I agree that obviously you don't want to do everything at once but is the road map and is the plan to get to the what I would call Paradise or how do you think about that uh I I do believe that um this is another thing that we want to provide optionality on I want to make it possible to aify everything so your your Bridge contract your evm state transition um you know complete ocation right and you know we theoretically could do this today I think there's a

lot of great reasons why we don't because there's no perfect rollups the secur assumptions of existing rollups are not very good for the most part um and so the the I think n robs are a necessary step to getting good office ification with the security of ethereum and um explicitly like future proofing for layer one compatibility and if you think that's valuable then I think Native robs are the only way to to get that um that's something you should support but it's not it's not the only way right like you could you could set up some offchain system of proving without being native um and have a you know a really great roll up that uh that is oied all of this but without native um so yeah a

lot of things there Co do you have any thoughts just to close out I have a question like in the case of of Base apps I see why somebody would not want to be based on in the case of native apart from the uh Security Council is there any other cre ISM or potential reason why somebody wouldn't want to be native I'm just trying to understand the optic from somebody that could like have criticism I cannot see many criticisms to to Native rollers and I want to see if anybody has any because yeah people were asking like if I I I tend to think it's

not going to be very I don't know if the words in English polemic or like uh it's not GNA be like something that yeah I want to see if there's anything I'm missing yeah I mean one thing that I think is always going to be a question is the uh like activation cost or complexity like how much does it cost to like you know put ethereum resources into this is that worth it I think that is a a drawback that needs to be considered um it also needs to be considered like will layer twos end up switching like are the benefits actually good enough are we just going to waste a lot of layer one time um I don't know but I I would see that as one criticism that I've seen shopped around um I don't

know if other people have have seen some other ones as well uh I think there's there's some scaling questions that we need to answer for this uh especially if we're doing um strict native only um I don't know but I have a suspicion that we might end up with hybrid native uh Solutions on l2s that are uh extremely high activity that's not um cross chain and by that you mean like a optimium yeah I mean where where they're

basically interleaving native interrup blocks with you know fast fast um uh calculation of only local state and then settling the the local state updates before the next native block yeah I mean I'm not I I just I see this being a a complicated landscape for different types of L2 uses and if the um if the limitations of of building on the L1 end up restricting the throughput for the l2s they're not going to want to

go full uh Reliance on the L1 one agreed so and I I'd like to have solutions that still allow them to participate right yeah so just to summarize we have cost and complexity of migrating and you know shipping this to ethereum um is going to slow down faga stuff like that and we have scalability especially with trade-offs like what are the tradeoffs around certain points on the scalability Spectrum um and lah did you have something else not to this point but to a different R so if you want to finish this then i' continue no go ahead please okay um yeah

so just uh just uh quickly Switching gears um in terms of bringing this to mainnet so I wanted to yeah just share with the group maybe a learning from the from the fossil um EIP and uh like one good argument for why fer uh made it into to faka for example was the the design of the EIP was based on extensibility so um like when I heard Kev and just then earlier talk about hey let's start minimal here um um we have all this debate about re-execution versus K version so just to just wanted to share this idea that maybe there's there's a good chance that um a native

rollup EIP uh can be structured similarly that so so we start with a light very lightweight variant and and extended later on yeah I think that potentially manifests itself in um in doing re execution before um before doing full ZK I mean or you know in shining something with a very very low uh gas limit is another way to kind of just experiment with some of the stuff before activating it um I think our um maybe say something a little spicy I think the aore devs process is something we want to um be involved with as little as possible and get one EIP through and then do everything else just with you

know EIP 1559 um gas limit style upgrade where where validators can can vote um that's something I'd be uh I'd really like to push um and K yeah I mean that's a great call out I don't want to promise anything nor do I want to uh speculate strongly that about timelines for NS or even about inclusion at all um and so if you are writing educational resources or or research uh it' be great to avoid um uh avoid speculating on inclusion in fusaka I guess as a as a starting point um and I'd love to get more more feedback from those from gevs if you if you know any GVS if you are a gev then

please um please let us know how you're thinking about this uh that's that's all the time we have for today for for this call um I'm going to stop recording and we're going to take this off offline just to discuss any um you know any additional things that we have not covered so far publicly if anyone else is interested in um getting into the native rup telegram then please um please message me on Twitter message Justin um there's a variety of people that can help you with that um and we would love to get you involved with this get you in these calls get your feedback um I also talked about this cont group um for

review and if you are interested in uh participating in that then again please reach out to me and I will um I will add you and yeah hopefully we can get some some content out there in um you know in a structured way in the the next few weeks to months all right thank you everyone for coming goodbye and we're done thanks mate