Native Rollups Call #0

Transcript

good morning everyone I am Matthew M team I'm going to be coordinating some of the base native rollup stuff excuse me um we're just going to go up until the hour today and talk about Native rollups that will be um the only time that is recorded but after that we'll have some some unstructured time as well I am the co-founder of spy Labs I'm very passionate about Bas rollups and I believe that there's a uh a you know a really powerful Union point between Bas rollups and Native rollups that just is calling ultrasound rollups I like that name but um some people don't and the the nice thing about ultrasound Roll-Ups is that they have essentially equivalent security properties to the layer one um but also have strong synchronous

composability between the layer one so um feels like the kind of thing that we wanted starting to be but actually practical um so yeah we're just going to go around and do quick introductions and I'm going to ask you to explain like your conviction on Native rollups and and kind of what's specifically your bullish on about Native rollups so far um just kind of take a couple minutes and then go through that Justin do you want to start yeah sure I mean I guess shot could be another good term for based and Native uh rollup um although sh T typically suggest an exact copy of the L1 uh and so maybe programmable Shard is

kind of a another term that that that could be used um the reason why I'm super excited about Native rollups is that um they basically solve a bunch of problems for the for the rollup for the l2s uh number one is that uh you don't need to worry about bugs anymore if you want to be evm equivalent like by construction out of the box you have an exact copy of whatever you have at the L1 so the the validators are you know running clients and verifying State Transitions and the exact same validators would be running the exact

same software to verify the state transitions happening at L2 in addition to to the L1 um the other thing I'm excited about is that native rollups solve the um the governance attack Vector that a lot of the rollups have if they want to remain evm equivalent so um today you can't have a immutable virtual machine which is long-term even equivalent and the reason is that DVM itself is a living thing and it lives through uh so social governance with with hard forks and uh and so today what we have is like a multisig or some sort of token governance to remain evm

equivalent once you have this uh pre-compile which exposes the native evm execution engine it stays uh uh equivalent through hard Forks uh so that's a very nice feature to have and then the the final problem that uh I think Native rups solve is that they dramatically simplify synchronous composability and the reason is that if you want to have synchronous composability with the L1 um you need to have what I've been calling real time proving but real time proving is maybe a term that I'll phase out a little bit in in these more technical discussions what I really mean is same slot proving so the proof needs

to arrive in this same slot as when the when the block is produced and uh what you can do with uh the these native rollups is that behind the scenes you can use next slot proving where basically the proof is delayed by by one slot and the reason is that I think the L1 is going to move to this model where the validators just accept uh blocks in slot n uh you know optimistically if you will without executing them and then they will only compute the state route in slot n plus one so this is a proposal by uh Dan Robinson and and Charlie noise and and Max Resnik um there isn't an EIP

yet but there will be an EIP and it solves a lot of problems and in particular it also helps with the the the latency problem of of of real-time proving shifting it from same slot to to next slot proving all right uh Joshua do you want to go next yeah sure so um just quick introduction to myself so I work um in mental Network so mental me andle um is is um in originally it's one of the early uh L2 networks that uh started out using the P stack so we' have been an optimistic uh sort of a rollup

construction um we have actually worked with uh suin and this is recent uh news uh from the end of last year that we working on using the sp1 Prov uh there ZK VM Prov in order to uh take our existing uh rollup construction uh and architecture into a a ZK validity proof uh uh rollup uh I I think this this this helped us in a few ways so we've been thinking a lot about uh trying to Future proof uh the chain um it's very difficult to do state migration so just to highlight that that was one of the reasons why we ended up going down this route was because it's

it's very difficult to take the the entire State uh and some customizations that we have in order to uh derive uh you know a new architecture so the ability for us to uh use S sync uh uh snot proofs was was Sol of like a very quick fix in terms of a proving system and also uh down down the ZK route now one of the reasons why we also were going down this route was because when we looked at the beam chain uh road map I think another key part of our ecosystem is that on the L1 we also support a lot of valid data uh

infrastructure to a true a liquid staking protocol so we also have uh quite a number of uh operators and that that operate validators uh and we potentially also see the transformation of the the staking requirements getting lower and lower uh as result of uh this beam chain road map so I think from this angle we do see uh like very strong interest to remain as compatible as possible uh down this road map uh and it's is a kind of a living example of uh a big chain so we're currently like probably on l2b I think we're the fourth largest is a good example of like a

chain that's actively working with uh production level uh transactions and people actually working with this uh self tooling and trying to see how we can move that architecture across uh the beam chain road map uh into a state that that like I I call it like maximization of decentralization so you have really low requirements for staking and also maximization of um uh maximization of decentralization and maximization of uh efficiency uh because of this suain proofs where uh it it's you know it's all1 type of complexity and you verify and you and and uh it's quite stateless

so I think from there like that's where I'm I'm I'm angling towards trying to understand how we can remain as much as as as future reading as compatible looking forward Matthew you're muted sorry Ming do you want to go next yeah hi everyone yeah so so I mean I work in the uh PSD belong to a under ethereum foundation so I'm working on the dkbm uh like exploration so or or recently or recently Milestone is we try to explore some performance dkb improver

and basically this is more like a s check Bas S Check base so we are working with some uh working with some uh working working on some open source project with some L2 provider in the market who explore how who explore the performance dkbm what it would be look like and basically it's like uh yeah the technical stack yeah and before before I working we just kick up this project uh last year uh and before that I'm working on the dkm project which also uh like uh under the PSD of etherum foundation so yeah so I'm very excited about the native dra up because I think uh uh at least this one resolve the existing

problem we have and uh the dkv evm project I I have working on previously the most challenging question is uh because evm is very complex so to make this evm to be run in the dkbm is also a very very challenging task so that's why so many people is prob exploring that exploring that and even for for our team right now we still explore what's the POS possible technical St in the future how to lending this kind of stuff in the Manet yeah so before that I'm pretty aggressively thinking that uh probably in in one day the the menet the the block settlement can be just uh squeeze into one snug proof and the all the

validator just verify it then the block will be settled so this one is more ambiguous uh sorry the more aggressive plan because uh this one involve you need to generate a proof in a very very short time because the ethereum uh menet block they need to be settled they have a strong requirement for the the block to be settled so we need to gener proof so that's why we think the perform performance Pro is very important to make this one happen in the future yeah but native R up is another for me it's another another role map because this one is basically probably sh some common challenge for the the the ultimate goal for the ELO settlement but for the native Ro probably we can apply some for example

one slot delay or some other tricks so probably we we can uh it's kind of for me it's kind of the the middle Milestone to achieve the final goal yeah so that's why I feel besides native dra because uh Native so it also means the evm compatible or everything is like the same as one yeah so uh the research or the effort we put properly can also be used in the native R so that's why I also feel yeah very very excited about that but today I also want to raise a question is uh if we if if if even the future we try to make the the single snug proof for the the main block Manet block settlement then how does the

native row up play in this role because I feel like if the Manet throughput is large enough probably we don't need row up so the r up exists because uh we we want to improve the througho by the r up way but what if the Manet can be settle in a more like high like a snug or dek way then do wind still need rent row up so this is also one question in mind hopefully we can have some Ry discussion for the day yeah so basically this is why I'm uh uh walking on in my introduction and my expectation yeah awesome thank you we can hopefully get to that later um a l i z k I don't

know how to pronounce that but would you like to go yeah hello I'm Alex uh from psse as well I work with Ming on the zvm project but also other projects like folding and client side proving uh and and security and um I'm also a founder of ELC which does Smart contract security and uh zero knowledge uh auditing as well I guess I have been passionate about snark ifying ethereum for a while actually since the rollup Centric road map one of the major concerns that I have is L1 losing its

place as a a deployment Target um uh if it's only just a settlement layer then eventually um Ro levels will get big enough and break off and we will lose this public good which is which is ethereum while if ethereum remains um um an execution layer as well an execution a viable execution environment for at least some some DBS then everyone wins basically including rollups themselves because uh they get advantage or they they get to take advantage of uh interoperability and shared liquidity and a lot of the good things that you know shared sequencing is is going to bring for

example um with respect to Native rollups I guess some of the great areas that remains to to me is how the plumbing of sequencing and execution happens um and things like that um so yeah I am excited to get into the details of it it's some of the you know backend things if we call it uh might still be unclear I do agree with Ming that there is a lot of overlap between native rollups and snark ifying main net itself um probably the only difference is probably the the

state and whether native rabs will be allowed to have their own uh customized ZK optimized state or not um but yeah it will be also interesting from a coordination and focus point of view where we uh think about something like that uh and the other point that I am very very interested in uh uh bringing attention to is the auditing and how we can make the right choices in order to compound auditing efforts uh so that's you know um working on even uh the beam or main net uh snark ification or native vs they all have a

shared uh component so that all these auditing effers can be compounded and taken advantage of thank you Aram do you want to go sure um hi everyone uh good to M you my name is Aram I work as a research lead just a moment yeah I work as a research lead at Cyber fund uh cyber fund is an investment firm um from founders of Lio Constantine and vasili and we're also Genesis investors in ethereum and

um as a result we're super interested in basically everything related to ethereum you know from both infrastructure and applications and naturally you know with we're interested in all the cutting Innovation that that's happening in the ethereum infrastructure land in particular native robs but uh yeah so uh and talking about Native rups um this is a really cool idea in general uh first of all and for a long time I I'm really fascinated by this kind kind of um tradeoff that um actually all businesses face at some point which is either outsourc um some of this some of their

stuff or vertically integrate so in this particular case we're talking about rollups which is basically um scaling execution but also maybe uh like some of the BD stuff um uh onboarding users essentially and uh yeah in particular all Alo ethereum's move to Outsource everything to roll up was uh was really uh cool to me at at that at that time let's say three or four years ago uh it was a really non-trivial non-trivial one but I think right now it's sort of uh it's it's the right time to bring some

of the things that are um en rollups back to ethereum L1 uh and I think followups is is the technology which will allow this to happen and the most important one is the network effects that that will come uh to Native rollups actually may probably to even based rollups via synchronous composability um yeah so and also I want to um highlight couple aspect aspects that uh are interested to me interesting to me one is you know is the coordination uh angle you know how to get it off the ground what's the right path uh towards

the end game because I I think the end game here in some sense there's some consensus I mean there's a question of course you know how many shot how many Native rollups and etc etc but roughly speaking this snar ified execution end game is uh is more or less clear but the path towards it is what really is unclear um and so in my mind for example uh yeah like native based rollups I think it it would also make sense for them to uh to be very close to ethereum and if they're just fully even deployed by

ethereum uh then they would be shards but U maybe it's it it could make sense for those rollups to share their execution is not 100% and not 0% so right now 0% Shard would be 100% it could be interesting to explore uh sharing like sharing a portion of execution fees with e holders essentially burning e so that's one aspect I call them in my head/ rollups aligned rollups um and then the second aspect is um you know another there there's like a uh sort of a bottleneck I mean in some all core Dev call is a is an extremely

cool process uh and the whole governance of ethereum is what makes uh actually people confident in ethereum but it is a bottleneck in terms of kind of delivering uh changes so I'm also interested in how can one potentially soft launch uh Native rollups uh without hard Forks potentially via side cars um and actually Justin also mentioned like this cool idea that you don't even maybe need a a snark uh verification first and just do it via re-execution and that would definitely uh also simplify things a lot um yeah thanks looking

forward thank you Alex you're last I believe um yeah so I think my my day today is leading to zkm form verification effort and so I'm particularly interested in the zkm angle to to the native rollups um and I think other than that like I'm very interested in trying to bring things back in touch with C1 in terms of better composability and kind of running equivalent software and I think Ali pointed out you know like you would make a lot of auditing in in security easier and I'm kind of fully agree with that um I'm not going to reiterate too much on what I think Justin analy have said I think I'm basically pretty pretty much on board

with everything they said um but I'm but I'm particularly excited in seeing I think yeah where where things will go um where Native RS will play a role in terms of adoption of ckvm but also in terms of moving towards N1 and and I think even how our maybe perception of native rollups and the role of rollups in theum ecosystem as we move towards kind of quite drastic changes to the L1 will will shift um I think that isn't settled in stone at least for me uh and I'm quite interested in in figuring that out awesome thank you everyone uh I think there's some some great people on this call I I get the I get the sentiment that there's a lot of people

that heard the native rollup idea and we're like convinced instantly because it sounds it sounds so nice um I think the open questions are around like specifications regarding like how does it actually work in practice and then how do we go from um from the idea to the reality and you know that's obviously like a multi-year process that probably involves some um some external actors and then a lay one hard Fork so that's a that's a tricky one for sure um so I have a I do have a presentation and I just want to go through and um and kind of discuss some of the important things that uh We've covered so far in the telegram chat um let's see so awesome um so here's what I I want to

go through the the first and kind of most important discussion point for me is to talk about some definitions so the uh Justin put this in the in the uh in the native rollup chat um and it just goes through kind of a few overall definitions Layer Two for settlement whatever settlement means roll up if it uses ethereum day I think that's pretty obvious uh based if it uses ethereum sequencing which is again arbitrary and vague and Native if it uses ethereum execution which is the thing I want to address in this call so I post this question to the group what is a native rollup um a few things to consider Does it include ZK if we're talking about re-execution then probably not um Does it include the concept of like using

blobs is that a part of the definition uh and then I guess we can go from there yeah so my uh perspective on on Native rabs is that um the sub routine that executes transactions uh basically uses a pre-compile which is exposed at the evm and this precompile is basically this this execute precompile that you have in quotes here all all capitals uh which takes uh several inputs and uh the three I guess most important inputs are a pre-state route a post-state roote and the trace and um basically what the the

pre-compile does is that it's making an assertion it's asserting that if you execute the trace starting from the pre-state route you end on the postate route and so the pre-compile will either return true if that's a true statement and it will return false uh if it's a if it's a false statement and um one of the subtleties here is that the trace needs to be available to the validators so that they have the ability to to re-execute um the the the computation and verify that it that it's a correct State transition um and even if you don't use naive re execution and relying on

SNS um we still want the data to be available and the reason is that we want anyone who wants to generate a SN to be able to generate a SN um and um I guess as a consequence of this if we are basically requiring the trace to be available it becomes a rollup so by construction you can only have native rollups you can't have native validium uh if we basically go with this constraint that the the trace needs to be available now the I guess the the simplest kind of of of native rollup is one where um you know all of the execution goes through this this pre

compile but part of the the you know the value of having programmability is that you can add logic around it so you could imagine um having a a custom gas token or custom governance or maybe you could have special system transactions uh that don't go through this pre-compile necessarily they kind of get filtered out and executed in some different virtual machine but um you know so long as for you know the default path I guess for user transactions is to go through this promile I think that's that's sufficient for for rollup to be to be called native awesome thank you Justin are

there any other kind suggestions for definitions think that covers it cool um the way that I would kind of approach this is not just defining things but also talking about um some terminology as well that's something we failed to do for Bas rups I believe for the most part and that was that was very tricky for writing some of the first research writeups um ex everyone uses different words to talk about the same thing so one thing I want to introduce here is need ative execution precompile to refer to the precompile that um is a requirement in in Justin definition to be a part of the sub routine again the default path for user transactions for

execution on a rollup um and then I also suggest kind of the we kind of use as a placeholder the op code execute um all right is there any kind of suggestions on that or considerations I mean another way to describe the pre-compile is to use terminology that we use used the you know many years ago which is uh execution engine so basically this pre-compile exposes the evm execution engine and you could imagine exposing a different type of uh virtual machine such as risk 5 um or even a wasm execution engine or or whatever it is um so if we if we want and to use a different term for the pre-compile and

the rollups that use the pre-compile we could if we wanted to use execution engine pre-compile and and Native rollup and so it's very clear what we're talking about at any given point in time yeah I like that um all right so I don't want to spend too long in any one of these so we'll just go to the next one real quick talk about ZK VM diversity so this is something Justin put in the native rollup chat again and the the summary that I got from this is that while it may be valuable to kind of work on multiple zvm simultaneously and even support like minority ZK VMS the it's kind of unfortunate fact of life when it comes to the kind of soundness bugs that

you see in ZK VMS and um and that problem is that you if you can break it in any point you can break the soundness of the entire thing and so um things like client diversity bugs kind of appear in different places in the in a client maybe there's one in the execution that consensus or whatever and so if you have multiple implementations it's unlikely they have the exact same bug but for ZK VMS they can have a completely different bug in implementation but still have the same end effect of um of kind of not being sound and so I think it's likely valuable to formally verify at least one zkm and kind of INR the idea of that zkm um either onchain or or just offchain with kind of social consensus um this is

like the downside of this is that it takes longer to you know formally verify things it's not easy uh but I think there's there's some significant benefits as well so I just want to open up to conversation if anyone has any ideas surrounding this so there is like one big benefit of uh of the ZK approach is that you can very very cheaply run multiple clients in parallel like if you take a a default you know typical operator on ethereum they will one run one execution client you know ref or GE or whatever it is um but there are like some s really sophisticated I guess institutional operators who are running vouch that

allows them to Multiplex and run you know multiple um execution clients and then they can have some sort of a logic which says if two of the execution clients agree uh two out of three for example then then that's kind of u considered to be uh to be the the the truth um and with ZK it's much much easier to have a vouch style multiplexing and so [Music] um this this to a very large extent I guess counterbalances the the the fact that if you have a ZK VM bug it it it might just compromise the whole zkm and so you can't trust it at all um so there are like still some compounding if if

you're running you know three um as an operator three uh ZK LS um and you know there's a probability a p of of of each one uh being being compromised then you know you get you P to the power three uh that all of them are compromised and you know if p is sufficiently low and the exponent is sufficiently high then then actually maybe uh maybe we're good and so what what I would kind of encourage the uh the valid dator operators to do is not just pick one client but actually pick a a whole set of clients that they that they

trust go ahead Aram sir yeah um this might be a a super basic question but uh I had the the fall in in mind you know if there's multiple zq VMS it means that there there's multiple proof systems and uh I'm wondering how can it be how can there be only one precompile but many proof systems because if uh some sort of proof Builder uh you know proves a block they use a particular system so a testers uh who and you know proposers who need to sort of verify

this block they need they need to have that particular proof system if I understand correctly uh in order to to to snark proof uh the block so I'm wondering how can there be only one precompile but many zqv yeah so this is basically very similar to ethereum and evm today there's only one ethereum one evm but there's five execution clients um and the the key thing for the native rapse is that the execution engine pre-compile doesn't take in a proof explicitly on chain so the the proof is not one of the inputs that's made explicit on chain

instead it's implicit and it's gossiped offchain in some sort of you know peer-to-peer peer-to-peer Network and so you could imagine that um each execution client GFF or ref becomes a ZK client and so you have ZK gef and ZK ref and as you said each of these will have different choices of snar ification they might use a different proof system or a different zkv or a different um you know compiler that will take high level code that compiles down to the to the ckvm um and ultimately what we what we need is for every

single uh proof that's generated for it to be generated for for all of the the the relevant uh zk's so there's multiple proofs that are generated and the validators basically pick the subset of proofs that they are feel comfortable uh considering to be trustworthy I see so it's really proof Builders need to basically generate all the proofs of existing um yeah proof systems on execution clients within the validators got it yeah and and just to kind of reiterate that that set of proof systems

is not like enforced on chain or not force a hard Fork it's kind of up to the the the validators to choose which proof systems they want a proof to be generated for um there's kind of some like rough consensus that we have to build cool there's a few key advantages to to this approach one of them is that um there's a lot less complexity that we have to andrine right it's all of the complexity is kind of offchain at the at the fork Choice levels subjective to every single validator and another one is that the eum layer one doesn't have to pick a a favorite right we don't have to pick sp1 or RIS zero so there's a bit more credible neutrality there's also much more diversity right if we were to

put all our eggs in in one proof system and there's a bug then you know all of eum fails so it's reusing this robustness through client diversity uh approach um and then if we find optimizations to the proof systems then those can be incorporated without a Fork The Operators just need to update their their ZK and similarly if there's a bug right if there's a bug in one of the ZK for example ZK GF um while all all of those operators just need to to update without without a hard for so I think you know given the amount of complexity that we're talking about with ZK VMS this is the only kind of

short-term viable path forward uh to to not enshrine it and instead make use of diversity yeah thanks Justin um okay let's go on to gas so this is something I think is um kind of not talked about enough for some of the Native rollup related things um at least in my conversations and that would be kind of related to the the resource usage of native rollups and there's a few key things to consider like first of all the proof generation stage gets more expensive and slower when you have to prove more um per rollup and overall so it's it's kind of

more expensive if you have to prove a lot of smaller native rollups but you can paralyze those so maybe it's not too slow but if it's one huge native rollup then that is painful u in terms of proving latency and so there's a there's a few things to consider here especially if we're doing multiple ZK VMS related to proving cost um but I think that there's also some other reasons to to kind of Target um certain gas prices and so the kind of fi mechanism used to do this is uh is is going to be a trick case so Justin wrote this in the um in the native Roll Up chat again and this is just kind of going through the idea of using a global gas Target versus a non kind of like individualized or

granular gas Target so uh do I have any kind of thoughts on this or important things to to point out here I mean one one thing you you point out Matthew is that um Native execution is going to be a a limited resource and and the reason is that we need to have the provs be able to generate all of these proofs um in a certain amount of time within one slot for example and and this needs to be a a credible minority Pro assumption so it needs to be credible that there's you know entity out there that are willing to do the

proofs and if uh in order to do the proving requires you know a data center for example this this assumption is no longer credible so uh you know what I'm hoping I I guess the ideal is that um we're in a position where the the the proving can be done by entities with with laptops for example uh and and as such we need to have some sort of limit on the the cumulative uh gas used across all of the different uh Native rollups um and this is this is a recent realization that actually there is an incentive compatible mechanism to to price this

this finite resource which is simply to to have an e559 mechanism but not granular to an individual rollup because in some sense there isn't such a thing right like the yes the the op the pre-compile that asserts state transition functions is ephemeral um there is no notion of of of state that is that is long lasting um and so it's it's very difficult to to charge an individual rollup but if you charge all of the rollups as a group um then then it becomes totally doable and it kind of goes as well to one of the comments that that was made

um Poss by by AUM um that uh you know maybe there's this model where part of the fees go to if and part of the fees go to to the L2 token um and and and that that would be one way to to to do it there where uh you kind of have a base fee for for for for for Native rollup execution um and that's the same for every single rollup and then if you have some native rups that distinguish themselves you know because of whatever reason then they they can they can charge a premium on top of that yeah I mean I'll add here the other

kind of perspective for for Value cool for ethereum is is blob related one kind of side effect of the kind of execution engine prile that we've been talking about so far is that they they um they can't do state diffs they have to have like the full transaction data and so they are purchasing a a ton of blobs and the um I believe the blob Market is like we introduce a lot of demand from this um that is another conversation for another time let's talk about re executions this is kind of a less endgame thing and more like stepping stone related thing I think the takeway for me is that we can do Native rollups figure out an OP code so have an execution engine pre-compile um and

expose this to rollups start to get like specs out um create like a credible migration path but instead of of doing snarks and actually getting those those all of the scaling benefits we can just get some of them with re-execution and the the beautiful thing about this is twofold the the first is that the uh the kind of impact on validators in terms of like Hardware requirements or bandwidth requirements is pretty minimal you just need to think about an additional kind of like thread of execution other than that stay and bandwidth stay like roughly the same um I think it's really powerful and then the second part is related to upgrades so if we want to move to snarks in the future which I think we do then um this wouldn't

require layer one hard work if we already have uh what what we're describing here like re-execution and so first of all I want to ask like does anyone have any questions about like how re execution would work and like how the migration process would work cool and then um are there any kind of broader discussions about like how wise it would be to to um to attempt re-execution before um before snarks I'll add one thing here which is that Justin tells me that it may be possible to get native fobs in fusaka in early 2026 and so that would be that'd be incredible if we can make that happen so yeah maybe AIT go ahead go

ahead Alie so I I wanted to clarify because I I see like two Notions of native rollups so the the first notion which is the relates to the old idea of having an insur chart is that um the native rer being enshrined because you have a a a pre-compile a verifier which automatically means you have to enshrine a specific verifier which ends up you being selecting proof system but here I also see another notion which is L1 is sort of coordinating basically um around this pre-compile

which is sort of an interface that a native rollup would provide its own verifier bring your own verifier to L1 and in that Paradigm uh we can have a diversity of native rollups because each will bring their own they will tell the L1 notes which verifier to use basically um so I'm wondering which notion are we talking about is like I don't see the the first one the the coordinating part I am not sure about it being a stepping stone to um from coordinating um around an interface to

enshrining specific verifiers so I I guess there there's three different models that you can uh go towards the first one is that you have a very opinionated uh proof system and that's the thing that's enshrined and that's the thing that every single validator needs to run uh I I think that um directionally this is something that's very very difficult to pull off in in the short and medium term and if anything for questions of security right if there is even a single catastrophic vulnerability in whatever proof system was was chosen um then then that compromises all of theum it kind of goes

against the the the client diversity um you know eforce that that we have so the the second path which is I guess the the one that was suggested by by vitalic which is kind of this this really clever idea which is that the proofs don't go onchain the proofs instead are gossiped off chain to to the validators um we we have a you know all of the validators have this kind of abstract notion of you know the evm that's basically you know the yellow paper or you know the the python executable specs but then um the actual proof systems that are and and execution um clients

that basically take this abstract notion of the evm and kind of implement it in in real life all of this is is implementation detail and every validator subjectively makes a choice as to which execution engine they run or which ZK execution engine uh execution client they they they run and then there's the there's a third thing that that you're talking about um which is where the the rollups kind of choose uh what verifier they have which is the the status quo that we have today with with with the ZK rollups and the the the problem there is that you know they're not native um and and you know there's

all sorts of issues around potentially having bugs in whatever they've chosen or the need for governance in order to to keep updating the the verifiers so I guess what we're we're trying to do is take the status quo where each rollup decides its own verifier and instead having this this this precompile um that is meant to be an exact copy of the L1 evm but the choice is actually at the validator level is it's not at the at the rollup level if that makes sense cool any any more thoughts on like re-execution related things

awesome Let's uh let's go on this is um kind of a I don't know how you saw this is but essentially just talked a second ago about kind of what the uh the op code might look like kind of a rough specification Justus and I also talked about this before and is kind of the the the kind of rough idea that we had which was um these three inputs you have a pre-state root a trace which is just enough information anyone to generate a star proof and the idea about the trace and I could write more about it but um you essentially have like the full path of execution here and then the by code input as well so if we expose a uh a kind of 5 VM and we would like to use the uh you know this as underlying layer

but we want to agree on some evm by code that can be used directly by native robs I don't like bring their own by code um then we could have a kind of a contract that's made available we just doesn't have to be a real contract it just be kind of included in the hard Fork um and it can be referenced by the the native Rob as kind of simple idea here and then the output is one of two things you can have either a post state route or an exception U if there's some sort of kind of invalid uh execution that is impossible to prove and so these are the two kind of possible results uh of this of this out code um and yeah I mean we had a few discussions around like using blobs or our state for p code there's I

think there's some trade-offs either way um just I don't know if you have any kind of revised thoughts since this call or we want to talk a little bit more about this yeah I guess I have a a couple um minor revisions the first one is that we need to expose the total amount of gas used uh if we're going to have this EIP 1559 uh uh mechanism so in addition to the postate route I think it's good to explicitly expose the the total amount of of gas used in that specific State transition um and then the other kind of slight change that I have is that BAS basically instead of putting the the postate route

as as an output right now what I'm thinking of is just you know putting it putting it as an input and basically thinking of the op code as being an assertion uh and basically returning returning true true or false um yeah the it's a bit of a of a minor technical uh detail but um like one one of the questions is do we want our proof system to be able to um only prove correct State transition functions or do we also expect the proof system to prove in in in basically proofs of invalidity

of of of state state Transitions and you know depending on on which flavor we go with we I've we we want we want to have these these potential uh reversions of not but I guess that's the that's two in the weed I guess the most important thing is just adding this this gas used as an input or an output go ahead Adam yeah was I was wondering about this 1559 um idea um you know it it makes sense to have it when there is like a clear um I guess

demand and also Supply and for me I'm not sure like if if this op code execute is let's say a third resource in ethereum that is priced as1 1559 you know if it if it if it's not done with v snarks just by re-execution it will obviously be a limited resource but then if it is upgraded to snarks um is it going to be that different from like an addition operation on ethereum like it seems it's going to be pretty cheap to verify yeah so the bottleneck will shift from the the verifiers you're right it

will it will be so cheap to verify that it won't be a bottleneck for the validators but there's a new bottleneck which is the the prover um so I think there needs to be some sort of a of a gas limit and actually one thing that comes to mind is that if we do make the current L1 evm instance snar ified uh under the same Paradigm then we can just unify the e559 mechanism so instead of having um you know a separate gas limit for the L1 and for the native rollups we could just have a unified cumulative gas limit uh and basically the the

current evm instance would would become a native rollup actually it would become more than a native roll up it would become a the first ethereum Shard I guess yeah makes sense Josh go ahead yeah I I I I think to follow up to AR's question so I think the I think earlier we mentioned the bottleneck will be shifting towards the provs and I would believe the proven infrastructure is fundamentally very different from uh validators is would there be I mean is is the thought around this a new set incentives for provs uh in order to keep it you know

keep keep keep that going in a and and in an independent fashion uh are and yeah with every sort of a separate um yeah set set of uh infrastructure incentives uh in order to keep this in a finite State uh uh and so forth yeah so incentivization is uh is is very important and it's it's not a super trivial uh problem the best idea that I have right now is that um basically with ATT tester proposer uh separation uh we have two

different types of proposers we have the the beacon proposers who are assumed to be very very weak running on SmartWatches or raspber pies and then you have the execution proposers who are meant to be very sophisticated think of them as as today's Builders and um basically we we want the proving load to fall on these uh sophisticated uh more sophisticated entities we certainly can't have uh the proving uh be done on U on the raspberry pies and um what one of the models basically is to have the execution proposes be bonded um for example have a

one e Bond and require them to to produce the proofs sufficiently many proofs so that their block gets included on chain so basically they need to produce sufficiently many proofs to cover a sufficiently large subset of the validators of the attestors who will attest to that block and include that block uh on on chain and if we basically set the bond to be significantly larger than the cost of proving then these these rational entities are are always incentivized to uh to get these these uh these proof build so that they can at the very least include that

block uh on chain and um you know my my guess is that we for any given you 12 second slot or 4 second slot or whatever it is um The Proven cost will be will be very very small on the order of you know dollars you know of of total energy consumed or or GPU time consumed or whatever it is and so if we have a onee bond uh that that should be more than enough to to to incentivize the generation of the proofs the slightly kind of unsatisfactory part of this of this answer is um that the there's only incentives to generate

proofs for a majority of ATT testers uh so if there's some sort of you know 1% of ATT testers who's running some exotic client than than than they're not incentivized to to pay the few cents or few dollars to generate the proofs for this for this 1% um maybe one way to to partially address that is is one of the comments that I made earlier which is that actually we want the validate is to be running a a plurality of of clients and so in some sense that there they no longer are minority clients because all of the operators are running most of the most of the clients and so every client is a a majority client Mak makes through the

sense awesome thank you Justin Let's uh let's get through our last couple slides here uh coming up on time so this is this is one that's very important to me and I want to talk about like kind of composability so another note I took from M call Justin uh a couple weeks ago and the the simple idea is that um and we were this is part of a longer discussion about when do you actually need the proofs for a native wup if proof generation is still like in the order of minutes then you can essentially just wait to um kind of generate the proof until much later but um this is kind of something I want to skip over for now and have like a kind of a dedicated call for because we are running out of time the the key kind of property that I want to look at is how

base sequencing and Native execution work together uh we call it ultrasound but um let's imagine that it is uh we use it for composability primarily I think that's the the key benefit um this phrase kind of next slot proven me and Justin used to describe kind of the uh the the the native roll out property where you can provide a proof like after the the the blockers prosed almost um and this gives you more time for proof generation right so the one of the bottlenecks for base rollups and kind of working on proving is this proving latency and the reason for that is because the more the proving latency then the less time you have to build a block and to like get order flow right and so the there's a ton of incentives

to like encourage uh minimization of proving latency but it's it's also very tricky because um if there's like a massive advantage to having lower proving latency then you kind of do have a centralization risk where one like super beefy Prov may be you know run by a builder has an advantage um and there's a whole bunch of other things to consider there but that brings us to plans for future calls so these are kind of the the things that I've thought about that would be useful to myself and I do want to get some kind of outside opinions here going to run some polls in the the telegram chat um one thing I want to talk about is kind of rough specking for an OP code and not like you know trying to write up any IP or anything but just focus on what are the

kind of what's like a unified understanding of the execution engine op code that we can um that we can think about for our kind of future research and then another one is gas and resource usage so this is one we talked about a little bit here about how um all of the the the mechanisms that we're thinking about for gas play into the um the native rollup kind of op code itself and other considerations as well one thing I might bring up is that like I think the the aggregate gas for um for you know all the native rollups doesn't like accurately represent the proven cost for all the rollups because you could have a situation where you have many small native rollups and

that's faster to prove because the uh the proving latency can be kind of parallelized but if you have one huge native roll up may be the same aggregate gas but have the downside of you need to kind of prove it sequentially so there's a few kind of more complexities there and then another one here is kind of incentivization uh of the provs and this one we talked about a little bit here it's not only incentivizing provs to exist but also encouraging them to prove um for certain you know maybe minorities kvms um is a whole another discussion as well and then talking about migration as well so this is where uh we talk about like migration for one version of native rollups to another using like different B code uh for that we also talk about

like doing a hard fork with the existence of native rollups if evm changes then how does a native rollup kind of hard for with that um it seems like we might need to use is a two block Fork process which would be interesting and then some of the incentives surrounding migration so this is the other type of migration which is um going from non-native to being native and and so I think this would be a um you know kind of a topic to discuss and one that I think is uh is going to be tricky but with the the right social pressures in place and the right like you building like a really good product when it comes to to Native execution I think will uh will give us a pretty massive Advantage so these is all the kind of stuff I had for today um this is

about on time here but I'll I'll give us a couple minutes for any closing comments do we have do we have anything I had a quick question about uh State on the up code slide um Justin where where does the State live exactly is it in the trace always or yeah great question so it's in the trace it's basically stateless execution um so the the trace uh needs to include uh basically Merkle paths or you veral paths or

or at the very least you know the the the state leaves that are being that are being accessed uh I guess the the merel paths can be compressed um actually no they sorry they can't be compressed and the reason is is that uh it's basically the comment that that that Matthew made which is that uh we we we we can't do state diff compression um because we we need everyone to be able to to generate the proofs and if you if you don't have the full witness then then then you can't generate the proof um so you know one of the the comments I guess that was made was that may maybe

we can uh we can have native rollups uh not in in fusaka in 2026 if we if we if we don't rely on um on SNS I guess the the biggest bottleneck to to getting that that that pre-compile technically speaking is probably to uh to agree on some sort of a format for for statelessness like how how do we communicate um the the the the Merkel paths and and serialize them and get them on chain and put them in in in blobs or call data or whatever it is so in some sense standardization on on a format for statelessness is a dependency uh to having um to H to having native

rollups in fusaka awesome thank you Justin I'm going to to stop sharing and then stop a recording thank you all for coming this has been this has been great