Ethproofs Call #5: Native Rollups

Transcript

Intro

I drop entropy like E40 slang. You prove or crash. That's bang bang bang. Claim your plunk but you just confused. Circuit sloppy benchmarks bruised back looking janky like scraper paint. Nah, it faint gone in the shell. Another biting [Music] out. >> Welcome everyone. And we're going to get started very very soon. >> We're 2 minutes past the hour and we have 100 people connected.

>> Started just as this song ends. Okay, welcome everyone to Eve Proof's call uh number five. Uh this call is dedicated to native rollups and we're going to have Luca Dono give uh the main presentation. Luca has been uh working uh very hard and doing a fantastic job on on on native rollup. So looking

forward to his presentation. Before that uh we have a few short up updates. Uh so let me just share with you the the agenda real quick. And by the way, if you haven't joined uh the EF proofs community uh Telegram group, I do encourage you to to join. There's about 500 people. It's not too noisy. Um and uh there's you know a bunch of of alpha shared there as well. So, so far we've had uh four calls in 2025 and this is our our fifth one with with Luca and um I'm hoping to be able to squeeze uh three more calls uh this year. One on the $1 million proximity

prize which is relevant to the vast majority of ZKVMs. Uh then a call on formal ver verification and then finally a call on on risk 5 alternatives. And uh this is today's agenda. So we're going to have uh nine different updates starting from Felix uh Lee who will be talking about a new ZKVM which is announced on this call. So Felix uh the floor is yours. my screen.

AntChain OpenLabs': new zkVM announced

>> Yeah, we can hear you. But if you can speak a little bit close to the microphone, we can't hear you very loudly. >> Okay. Okay. Thank you for your introduction Justin. Hello everyone. I'm Felix from Under Open Labs. Today we are s our works on TKVM. In recent years, a series of TKVMs has cut Ethereum B time from hours down to seconds. Since these tech VMs have done such great works, we found some challenges which may be bottleneck towards real realtime proving error. For the emulator, we found the code translation and trace generation is the bottleneck since some parts must execute it in parallel for proving system and some track advance rapidly but entity and extension field

computation may be the bottleneck. For recursive proving current protocols are relative codes only allowing aggregation of their own generated proofs and cannot use the proving power of others. For GPU isolation operations restain GPU isolation due to PCIe transport bottlenecks and limited GPU memory bandwise. We found some point that can further help JKVM. Just to emphasize this is still an ongoing work for the emulator. We use an agrees static binary translator to train resp code straight into machine code and a GPU native trace generator to build traces in parallel that give us a six time speed up for

proving system. We use base field only some track to skip costive field extension plus an fi in the middle protocol to speed up rotation that give about a 60% speed up for recursive proving we will build a unified recursive method that can aggregate proof from different protocols so we can use all team prores for GPU isolation we've designed a multiGPU heroical pipeline that will work by block and shout GPU to maximize the resources used.

Here is the benchmark of our MVP version. For the road map, we will finish the GPU acceleration and launch in J test net this season. And in next season, we will launch in J mainet and implement the unifi recursive protocol. About J. J is an Ethern to that went live on million yesterday. Thank you. Okay, thank you Felix. Uh, any questions from the audience? Feel free to ask them in the chat or raise your hand. First question, what is code translation?

Yeah, it's we translate the uh code writen in R directly to the code writen in uh this file and directly to the machine code such as x6 x8 x89 8664. Yeah. >> Okay. Okay. So, is this a similar idea to what ZISK is doing with the ahead of time compilation and then the very efficient execution? >> I'm assuming the answers answer is yes.

Um, great. Thank you. Um, so just to confirm this is a a risk 5 ZKVM that anchain open labs will be launching at some point in the future. Is that correct? >> Yes. >> And do you have a rough timeline for when you would uh release the CKVM? >> It depends since J has higher priority for us. >> I see. Okay. So once Jet has been launched in 2026, I guess um you would you would then launch the ZKVM.

>> Okay, understood. Fantastic. Thank you so much uh for for the update, Felix. Uh next up we have Ventali. If she's here, it doesn't look like she's here. in which case uh we'll move directly to some quick updates that I have on the ZKVM tracker. So uh you may be familiar with this ZKVM tracker. It's evolved every single month if not every single week. And uh I've added a bunch of things here that I wanted to very uh briefly uh walk you through. So the first one is that I've added this this

zkVM Tracker Updates

QR code in case uh the screenshot gets shared so that people can can find it. Um another thing is that uh we now have uh a a strong very very strong dominance of risk 5 here in this in this top section. These are the the the ZKVMs that I believe uh will be able to integrate with Eve proofs in 2025 or have already integrated uh with with with e proofs. Um and another uh update here is that on the uh verifiers we have um uh 100% dominance of of dual licensing. So uh

ris zero very recently moved from Apache 2.0 you know to to do your licensing and I think this is a fantastic uh standard to to set for the for the community. Um we also have another third uh redacted ZKVM which has been added here. This is from a a very strong team um and I'm I'm hopeful that they will uh reveal themselves uh maybe in a future EF proof call later this this year. uh again it's a risk 5 ZKVM on the right hand side um what I've done here is I've added the uh provers corresponding to the to the ZKVM so for

example uh Brevis is proving uh Pico Fermar and ZK cloud are proving ris zero actually this is quite interesting that ris zero themselves as a team haven't yet integrated with e proofs but two separate provers Fermar and ZK cloud have and uh here I have a little tracker the number nine. So we have nine different integrations uh with e proofs so far and that's spans uh six different uh zkms with one here at the bottom as well.

Um, what I've also done is try and provide a little bit of context as to why I think these ZKVMs uh might not integrate with EF proofs in 2026. Um, so a bunch of these for example uh have chains that are non EVM chains either L1's or L2s. So Aztec for example or Cairo or Maiden. Um and so I I don't think it's a priority for the for those teams necessarily to to integrate with with eofroofs. Uh and then some of the ZKVMs are mostly focused on the client side. So Cairo M where the M stands for mobile is focused on the client side.

Same thing for uh I guess ZK engine which is focused on low memory proving and and folding. Um and then you know there's all sorts of other reasons that I've given to try and explain my rationale. If you think one of these teams should go in the top section here uh for an integration with e proofs in 2025, do do let me know. And another thing that I've um added here is this uh mention of a countdown. So I don't know if you've seen on the e proof website, but we have two new countdowns which um we'll have Farah discuss. And um basically these three teams uh three ZKVMs Pico um Zyron and

Espon hyper cube um need to do some sort of a change uh otherwise they will get delisted uh by the relevant uh countdown. And uh this is a flashback to call number one u where we had a much less sophisticated uh tracker uh than than we do now. Okay, that's it from me. So next up uh we have Leo from CYC who will be talking about uh GPU and FPGA hybrid proving.

Cysic: GPU + FPGA

Oh, hi. Can you uh >> Can you see my slides? Okay. Yeah. >> Uh yeah. So, my name is Neil. I like come from Cassic. So, here like I'm introducing like doing like a very quick intro about like Venice. So, Venice is a hybrid system. It's a combination of like GPU GPUs and FPJS. And for for the GPU part like we thank uh succinct for uh sharing the code of the hyper cube system with us and by like a very detailed uh benchmark on the on the code we found like some of the uh kernels they are not very efficient like for instance the constraint polomial evaluation takes about like 40% of the time and also there are like so many

like small like kernels which like if you want to launch the kernel on the GPU then the launch time the context switching on the GPU is like also very uh uh time consuming. And the last the the ping pong uh synchronization between the CPUs and the GPUs like this say for instance the sum check and also the F shame is also like well crosses this synchronization um issue. So that's why like we we propose this like uh FPJ plus like G GPU system the so unlike this like GPUs like the FPJs are actually like very natural for this like polinomial evaluation you can just evaluate or you can express uh

the polomial as the native circuits on on the FPJs and they are also very efficient for doing some trace generation hashing and constraint polomial evaluation and also with some like dynamic reconfiguration on the like microscond scale we can essentially basically map all this like like problem like the bottleneck arithmetic circuit into the real circuit on on on the FPJs. Yeah. So that's the first night. Okay. Yeah. So based on this like uh conjecture we built our like on board.

So the goal is to achieve real-time proving I guess like for at least 90 95 to 99% of the block. We want to do it for real time under 10 kilow and the idea is to like uh here is to use our customized FPJ board which use uh seven FPJ chips. Uh so seven FPJ chips is around I guess like 1.4 4 kilow and then we rely on 16 uh RTX uh 4090 GPU cards which cost around like 7.2 kilowatt plus some like either for for the CPU and also for the memory. So our goal is to achieve realtime proving under 10 kilowatt. So that's our goal and we are

right now I guess like on the right track to towards that. So the goal is to say for the upcoming quarter uh from October to December we want to integrate our thing with it proof and we will also open source our like bit string of the FPJs under dual license like if you want to try it you can deploy it on this like F2 in instance. Uh yeah, so here is a picture of the of the board and we are integrating with our GPU resources to hopefully to get real time ping under 10 kilowatts in the coming months. Yeah. So that's all.

>> Perfect. Thank you for the update. I guess I'm curious if you were to remove the FPGAs and do everything on GPUs, how much slower would the system run? So that's um so like so right now to be honest uh Venice right now is a pure uh GPU system and yeah we are probably like in the coming months we will first try to achieve it on the GPUs probably like it with like many more GPUs such as like 16 to uh 32 uh GPUs and also for probably like a lower percentage of the blocks and we are do like benchmarking on all the things and yeah we will keep

uh keep the community updates with our like uh updates on the real time proving on that part. Yeah. So right now the FPJ like we use as you can see we use like seven uh FPJs like uh one VU 1502 like one like uh two VU 70 uh 70 uh uh 47P and one um and four VU 13P. So that's something like we we built this board we built this customized board with all these FPJs and yeah we will like do this like for the FPJs and also we we will do it for the pure GPU system. Yeah. So the current

the exact number we will release to the community as soon as we have some concrete and also confident result on that. Okay, great. And did I understand correctly that you have access to the SP1 hyper cube uh prover and you've modified the GPU acceleration. Is this going to be upstreamed in SP1 hyper cube or will it stay as a separate standalone prover from SCIC? Um yeah, we are right now in discussion with the flex thinking on that part.

Yeah. So like we optimize a lot on the GPU prover and we will probably like first demonstrate our result to the sinking team and since like we have access to their code we want to make sure like we we don't v any uh we don't violate any agreement uh with a sax team and after we demonstrate our thing to sinking we release to to the community yeah on that thing. Okay, got it. Exciting. I mean, on on a single single GPU performance, Espon Hyper Cube is currently the fastest. So, it sounds like there's even more juice to squeeze that hasn't been integrated thanks to your optimizations.

>> Great to hear. Thank you so much, Leo. I'm not seeing any questions, okay, in the chat. Uh, next up we have Maxim from Nevermind who'll be talking about snogifying Nevermind. Hello. >> Hello. >> Uh, uh, hello. Uh, do you see my screen? >> Oh, perfect. Yeah. So, uh, yeah. So, I'm Maximov. I work at Nethermind. At Nethermind, we have made some progress on ZK proofs. So, uh I will tell you a bit more about it. Uh

Nethermind: zk Readiness

uh we have made a few blog posts about VK progress. Uh it's probably better to look through them right now because they have much more information about this topic and uh contain a bit more about the implementation details. Um right now we have done some work on execution witness we consider it done this we have made a stateless executor which is also done they've made a minimal EVM binary it works it's fine uh we I personally worked on risk 564 bit compilation of nezmine client it's also done um I'm also working on this

integration there is some work in progress right now because we have uh like a few not so big technical challenges to resolve and also we need to standardize some things uh regarding all other TKVMs. So um we also plan in future to support risk 532 bits if it still would be necessary and yeah risk zero and SP1. So um as for stateless executor and execution witness we the execution witness captures all the state access during block executing in including

contract bite code storage slots hash keys block headers and all this stuff uh and the stateless executor uh effectively uh replace blocks using only the witness file without touching disco network. This work is done by Danish Kikita and other Nethermind team members. It's not something I was doing. So I I'm a bit less I can tell you a bit less about it. Then as for risk 564 compilation pipeline, uh we built Alpine Linux without some risk 564 extensions. We built Net without it.

We add some B flat patches to net and have a custom compiler based on B flat. Effectively in the very end we have static dependencies. We have no relocations and we have a binary which is compiled out of file and native dependencies and assembly files linked together in our compiler. That's actually all. Thank you very much. Thank you, Maxim. Uh, yeah, it's great to see so much progress on on guest clients. We we started with our EVM. Uh, we now have, uh, Nevermind. Um, we have EVM1, I believe. Um, Matalabs have their

own implementation. Uh, and I'm I'm probably forgetting a few. Ess from GE. >> Oh, yes. GE, of course. Yes. Um I guess my question to you is related to performance because you worked on the the compilation to risk 5. Have you looked at the number of cycles it takes uh to risk 5 cycles to to execute an EVM block relative to uh our EVM for example? >> Uh no I can't give you specific information right now because we are still finalizing some work on it. But at least um the performance for net itself is quite native because we compile using

well Microsoft compiler with our additions. Uh we also link to native native dependencies static native dependencies. So the performance must be not bad. Of course it depends on VMs to execute this this needed performance. Got it. Okay. Uh any questions feel free to just raise your hand or unmute. Um if not we'll be moving to uh Will. Thank you so much Maxim again.

>> Thank you. >> Okay. Uh yeah. So, we've been working uh to I guess get all of Eth day uh set up. Had a really nice turnout. Uh okay, thanks. So, just a reminder, E3 day is going to be happening on the last day of Dev Connect, uh November 22nd in Buenoseris at La Rou. Um the goal is to like really showcase all the progress that we're seeing in real-time proving.

Ethproofs: Ethproofs Day & Ethproofs v3

So, we received over 60 proposals from speakers, which is fantastic. Uh, and they're all really great. Uh, we went through several rounds of reviews, engaged about 10 different researchers from the ZKVM team, cryptography, rig, protocol architecture. Um, and the goal was to like really try to distill the talks down so that they're maximally aligned with the uh I guess Northstar laid out in Sophia's blog post about real-time proving uh in regards to shipping an L1 ZK VM. And so the the talks that were selected were done so in service of that and the format and the structure of it is really just trying to

uh you know resemble an ETH proof call. So, lots of alpha, lots of content. Um, moving through things pretty quickly. Uh, and you know, you can see like this is going to be going live soon, but we're going to be starting with some uh uh updates from the from the ZK VM team, from Justin. We're going to have uh some updates from uh sorry from the uh photography team and then a lot of uh a series of keynotes and lightning talks throughout the day. We've got two different or sorry three different panel discussions. One on real-time proving, one on formal verification and fuzzing.

Um and then a final one that is on uh who pays the prover. So on uh prover economics and and incentives. And from there uh I'll hand it over to Farah, but real quick uh we've also been working on ethofroof day or sorry e proofs v3. And so you'll uh start to see some uh improvements to the website rolling out close to Devconnect uh some branding that just went out recently. Um and Farah can jump into that. But if you head over to the EF proofs uh GitHub or you'll see that there's now a a link to like a very uh lengthy uh product uh

requirements document and that kind of outlines a lot of the the the you know mission statement for the document and the things that we're going to be working on and they're all outlined on a project board and you can dive in and and look at all these different work streams that we are uh concurrently working on right now. Um, and a nice little glimpse of the the t-shirt that you're going to get if you attend ETH proof day. So, Farah, >> yeah, I mean, so >> we're kind of rebranding ETH proof, trying to simplify the branding so that this is kind of a sneak peek at the refactor branch that I'm working on for

version three. So, we're trying to really simplify things so that we focus the attention on the data that we're collecting and allowing the user to interact with it um a bit a bit easier. So we're adding some filtering and sorting and exporting of the data. Um and kind of we'll start to work on better data visualization so you can select one, two, three rows and kind of compare them in the UI. Um and then kind of simplify the routes and and navigation also. So um hopefully that will be easier for people to actually work with like what we're what we're uh the data we're gathering. So you can go to the next slide.

>> Oh, >> and from an engineering perspective, just for scaling with version three, we're going to try to simplify on boarding um and add a team dashboard. Um that's one of the big pain points right now I think is just a lot of stuff is being done manually so teams can actually maybe manage their versioning of the ZK VMs and their verification keys for in browser verification and things like that. Um we need to kind of standardize the hardware. Our cloud um instances have become kind of outdated. It's a it's a um static snapshot of data for cost. So we need to make improvements to that. Um we've added monitoring for approver uptime. So, we've created some Telegram bots and the status page that, you know, it's kind of

surfaced some infrastructure um scaling um problems that we need to confront, especially if we're going to do um you know, proofs for every block, which we want to do. Um we're going to continue to make improvements on the end browser verification. Like I said, we have two more um to add. So I'm about done with SP1 Turbo and then I need to finish Rift Zero VM. Um and then uh we'd like to make some improvement for external APIs in the documentation there. Um and then also we're going to be supporting client side proving benchmarks which Alex is going to do a presentation on. And then also we're

going to be supporting this phase zero uh ZK validation effort that Justin is working on. Um and then you can go to the next slide. And then just as a reminder, we have um kind of put up these ETH proof countdowns so that we can um kind of uh hold people accountable I think for what they're claiming on ETH proof. So um all the verifiers need to be open source by October 26. So that's in about 29 days now. And then all provers will need to be reproducible. So either open source or provide the binaries to reproduce um the prover. So that is um the deadline is December 3rd. Um and that's about 67

days from now. Um so at that point, you know, Justin kind of flagged those teams at risk for being deplatformed. So just this is a reminder. and hope to see you at E3. >> Amazing. Thank you so much uh Will and Farah for for pushing this effort forward. Um we have a new logo as well. Um it doesn't look like much, but now it's all on one all in one line, E and proofs instead of being on on two lines and I'm hoping that will mean that people spell it uh properly. So it's meant to be capital E, everything else lowerase. uh basically a port motto of

Ethereum and proofs. Uh nothing to do with ETH, the ticker. It's not all all caps. Uh and yeah, looking forward to to to getting a copy of the of the t-shirt, even though I won't be able to to make it in person. Uh next up, we have uh Alex um who will be talking about the uh a potential extension of EF proofs for client side proving. Alex is from PSSE. Alex, the floor's yours. Okay, Alex might not be here. I see Ali's from PC. Maybe you could ping him.

Um, okay, we'll move on to Kev then. Uh, Kev has a new website to tease. Uh, Kev, the floor is yours. >> Uh, yeah, can you hear me? Hello? >> Yes, we can hear you. >> Cool. Um yeah, I don't have any uh presentations. Uh this is just an announcement to say that uh the well the digital studio team are working on the Zika EVM website. Uh we've given the URL in the in Justin's slides. Um and essentially this will you can visit the website to see um the progress towards shipping ZKevm on L1 and the work that our team has been doing uh to help this uh move forward. Uh there will be some

zkEVM Team: new website announced

opinionated takes on there. Uh so take some of it with a grain of salt. Yeah, thank you Kevin. It literally just came uh up today just a few hours ago. There's still a bunch of of rough edges, but uh now we have a dedicated website from the ZKM team in addition to uh to Eve proofs. Um, I see that Alex Kuzzman is back on. Alex, the the floor's yours. If you'd like to talk about client side proving, >> hey guys. Uh my name is Alex and I'm

PSE: client-side proving quarterly update

from the client side proving team of uh PSC which is a part of Ethereum foundation and I would like to present you a new initiative that we are about to launch that is called uh client side proving quarterly report uh which is all about benchmarks. So the motivation behind that is that client side proving is now on the rise and as we see the more and more proving systems are created specifically uh to be tailored for um low resource devices like mobile phones. Um we did uh some benchmarks for ZK project uh earlier

this year and uh caught some attention of the community. So we decided to continue the effort but since the landscape is ever evolving um it's not enough to just benchmark something once uh we think that uh it needs to be a continuous effort. Uh so we are planning to do it once uh every quarter and also another uh part of the motivation is that a no existing benchmark is uh exhaustive. So um it's a work in progress but uh we uh have already like fleshed out most of it. So there is a repository and there is uh like u road map for the first uh edition of the

course report that we are uh hopefully we're going to present uh at Dev Connect. And uh our goal is to help navigate the multi-dimensional space of tradeoffs in uh uh zero knowledge proving systems and ZKVMs because no uh system is good enough to like cover all the needs and uh we would like to do it by creating the like most thoroughly automated suite of benchmarks. Um yeah, I see I'm running out of time. So a couple of other things to notice is that uh we are going to uh publish the results at if proofs as uh far said

earlier and uh we will focus on some specific metrics that are relevant for uh client side and u our codebase will be very u easy to contribute to like here is an example of uh rust harness for your benchmarks where you just need to override a couple of functions like uh prove and verify and uh the benchmark suite will do everything for you like uh measuring uh statistics and collecting uploading the metrics and we also provide the uh non- rust harness so uh you're welcome to contribute um and that's it >> perfect thank you Alex so I guess the

concept is uh to benchmark these cryptographic primitives, right, like hashes and ECDSA that are relevant to client side proofing as opposed to whole uh EVM blocks that also have all of the the logic around it. Um and um yeah, it's great to see that uh PSSE is focusing exclusively on on privacy uh going forward. It's been renamed to uh privacy stewards of Ethereum. Um and I'm hoping that very very soon there will be more announcements related to PSSE including an org chart uh that will detail all the various teams including Alex's team which is the client side uh proving team.

Uh I'm not seeing any questions in the chat. So uh and I'm also not seeing Ventali. So I think we can just uh move on to the main presentation of today's call which is uh from Luca of L2 beat will be talking about native floorups. Luka the >> Oh Kev sorry go ahead. >> Oh sorry I just had one question. When do you think this will be integrated into E proofs? >> Uh it should be done before dev connect.

Luca from L2BEAT: native rollups

Yeah, we're shooting for Dev Connect for it to be live on ETH Bruce. >> There's going to be so much happening for Dev Connect. Um, it's going to be fireworks in terms of things that we that we all ship collectively. Uh, Luca, the floor's yours. >> Can you see the screen? >> Okay. Um, so thanks so much for having me. Um, I'm Luca. I do research at alt bit. I've been doing this for the past two and a half years. Um mainly doing risk assessments uh you know the the risk pizza of all of all the altos. I've been maintaining the stages framework and the stages assessments uh for for

these systems and I'm very happy now to also work on on native rollups on this effort. Um, and uh, before you know jumping in on native roll-ups, I think it's really important to kind of remind ourselves why we're at a certain stage and where we're going and why we're going in this direction. So what is happening today is that uh you know we have Ethereum that is doing uh 20T DPS which is uh you know really low number and uh we also have roll-ups and we had the need to have rollups for this exact reason that

Ethereum is very slow and these rollups are now today doing around 300 TPS uh which is kind of at the limit of what uh this availability uh reports today. Um but we need to understand why uh we have this difference, right? And the difference is that um uh of course uh we want uh all clients to be able to verify uh what's going on in these transactions. We want clients uh full nodes to be able to to compute the state. And for Ethereum, these nodes needs to reexecute everything. Well, for rollups, uh we have stuff like CK proofs and fraud proofs, right? So, um you

know, in the same way I like to say that in the same way that in DeFi, um we we're getting used to say to ask ourselves where does the yield come from? Uh when we see, you know, crazy numbers. Um I think in the context of scaling we should also get used to ask ourselves uh where does the scaling come from like what are you sacrificing if anything uh to to have the scaling right and here uh we don't want to sacrifice uh verification so that's why we're working on these uh solutions like zip proofs to to be able to maintain verifiability um while not doing execution which is the main bottleneck today right so we have this new which is uh you know see

proofs and for proofs and one can ask uh themselves like um why we're not using this tack on L1 directly um and one of the reason is that you know the tech was too experimental uh it was too expensive and there was no good way to mitigate bugs other than mod 6 so um in a way you know ziggraphs are too risky to use to on ethereum so five years ago with the rollup road map we kind of decided decided, okay, uh this new tech is very cool. Uh let's have rollups experiment with this tech. Um today, uh this is not true anymore. Like it it is kind of true uh in a sense, but we're getting more and more confident

that we can use this tech on L1 itself, right? So now let's imagine a world where we also have uh the ZKL1 ZVM, right? And potentially also let's assume that we scaled uh DA uh of course um so one thing that we can ask ourself is okay if we implement this zik attack on L1 itself what are we using uh the roll-ups for right and because you know previously we needed rollups because Ethereum was very slow now if we have zon one also L1 is potentially very fast so

the first reason is that if you think that 10,000 TPS is enough throughput for the work computer, you're not ambitious enough. Um potentially what is uh Ethereum is able to support is of course Ethereum res 10,000 TPS and this number comes from you know more or less the limits of serial execution. um there is maybe one order of magnitude of uncertainty but you know around 10,000 or 100,000 TPS um but DA the cool thing about this availability is that it is possible to to scale it to support much higher throughput uh than 10,000 TPS um if you do the math with like 1 GBTE per second

which is something for example the Celestia uh is uh pointing to uh you get around five to six million TPS that you you're able to support. And you know, we believe that no single chain is able to to go that fast. Uh and for this reason, you need um multiple chains that are running in parallel as synchronously to to saturate all this capacity. So ideally we would have um Ethereum that does 10,000 TPS and then um 1,000 rollups doing 1,000 TPSH uh for a total of you know around 10 million TPS.

Um and I really like you know the kind of narrative that Zync is uh has been using uh in the past of you know internet allows for limitless expansion. You can always add more servers, cable and connections um to the internet. And this is kind of the idea that is also here. You can al always add another server to the work computer um that runs like a synchronously from the others. Um and then rollups are very cool because enable custom environments to fit whatever need. Right? We've seen um rollups with very short block times with super fast confirmations. This is arbitrum that has been doing this for a

very long time. uh more recently uh there's been flash blocks from from uni chain and this is you know the customization that brings uh this is uh centralized sequencers right which is something that we cannot have uh on a one that we don't want to have uh ideally um of course there are there is some effort to also bring confirmations on a one but like um another type of customization is for example in inmax um inmax is a privacy chain uh we can do private transfers but they gate keep u the entrance of this rollup with some KYC or AML type of stuff. So this is also something that you can do

with roll-ups. Um it's very cool what chain did in the past which is also doing today with uh priority block pairs for for humans that have a verified word ID. This is another customization that you can do. You can have custom guest tokens. This is an example of a chain that is planning to use a yield very stable coin. Um you can have like a linear they have plans for native yield for the bridge. Uh you can have custom VMs of course at the limit of these customizations like kairo stylus with arbitrum or you know the SPM with Eclipse.

Um so the rough intuitions behind native rollup is that um rollups today need to have a proven system a dedicated proven system which is very complex and very hard to secure. is very complicated uh hence is very buggy and uh it's very hard to secure but eventually as we said also one will have its own proof system when we move to ZK um that will have the same problems but the thing here is that the Ethereum community will work very hard of course to maintain its high quality standards with all the initiatives that we've been talking about know through audits formal verification and client diversity and all projects that are on Ethereum depend

on these stock. So there's a clear common interest to converge and make uh this common stock secure. Um and then um EVM based rollups that want to stay up to date with new features uh they want to stay up to date with each feature and therefore they need to have upgrades in their own system. Uh but these upgrades are arbitrary. uh they cannot like limit themselves to all the things that Ethereum mods uh even though this might be their only need right uh they allow for arbitrary upgrades so increase the risk of users uh they need to have exit windows uh it gets uh complicated uh it's difficult to get rid of a

governing body of the system so here the solution is to try to expose since L1 is already using zk there is some form of zk verification already happening uh you can expose this EVMification uh pipeline uh in a form of a pre-ompile inside the L1 EVM itself. Um and you know of course we want projects to be to be stage two. Uh there has been this article um by the the founder founder of facets which I think is very good at understanding the problems. I kind of disagree on on on the solutions but uh the problem with stage two is you know of course there

are arbitrary upgrades. So they need to have an exit window. This exit window for stage 2 we said uh it has to be at least 30 days but a lot of applications um might need to have time locks that are longer than 30 days. You can think about you know token unlocks or like um cliffs and similar uh uh and these use cases would not be covered by uh the 30 days exit window because you would need to subtract your own time lock right so this is also a problem that is present in s and the only way to solve it today is to deploy something that is immutable but of course you would lose feature parity with one

so about the history of the idea behind native prolops. Uh this is something that is not new. Uh in you know this very nice image by Vitalik. Uh you can see uh in the verge at the very end there is an explore EVM verification pre-ompile from December 2023. Uh there was also this talk by Justin that I remember attending um ENZ summit 11 in Athens I believe uh that discusses the develops but there was also a very old uh like GitHub PR by by Vitalik in 2017 discussing um a execute transaction a way to just execute one single transaction inside DVM and one of the

reason why was this was discussed is was in the context of plasma because also plasma had the problem of you know something similar to prop proofs and this is by Kelvin that is now working on optimism on autopilops but was priv is working on on plasma and also here they have this need for having something to verify DVM inside DVM so how to implement this execute pre-ompile so the inspiration here is to use uh inde like the idea here is to reuse the citization functional one. So this is uh like a summary of the execution spec

um of the you know execution layer um for this transition. And the way it works is that it's a simple function that takes uh as input a blockchain which is a list of blocks and a block and applies this block on top of blockchain. And what this function does is some header checks um and then it executes the blocks. It calculates the new state when you apply this block uh to the previous list of blocks. And then uh let me wait let me activate the lazer. Okay. So there are some header checks at the very beginning. Then you fill this block environment which is all the field that you need to do the actual

state transition. The actual state transition is in behind like in this apply body where the actual body of the block is is u applied in the sense of it's uh the state is calculated and then there are some post execution header checks. So the idea here is for the execution pre-ompile to do a recursive call uh on this state transition. Right? So you can imagine the inputs of the execute pre-ompile as if they are passing uh this information this block environment information that then the state transition needs and you should not imagine these fields as they are today but you should imagine them as if we already have uh the ZKL1 and

statelessness. So for example here one of the input is a full state. This is like a very big object. uh you should imagine this as a pre-state right uh and you should imagine this execution that apply that is in apply body as stateless execution these transactions are supposed to be um the stateless version of this which are probably traces some some form of traces but if we have you know the ZKVM this is in practice uh the input to the verifier uh to the ziki verifier. Right? So the idea here is if Ethereum L1 already has a Ziki verifier that can verify transitions

from a pre-state to a post state given some transactions, we can also do it for arbitrary states and these arbitrary states would be the rollup states. Uh and these are some requirements that we want to have um in the execute pre-ompile. So as I said the goal of the execute pre-ompile is to try to do a recursive call to this function with the state of the rollup instead of instead of the state of L1. So what should this execute pre-ompile do? Uh it should properly handle the differences uh with L1 right so for example on a rollup you don't have B transactions uh all projects disable B transactions. So the execute pre-ompile

should also uh try to disable B transactions. There are some differences for example in the way that randow works because it's a value that is kept from the beacon chain and L2s are not directly connected to the beacon chain. This is also kind of um the same with the beacon block route. We're going to discuss uh this these cases uh in a moment. It should also support the 112 messages. Uh, of course, Ethereum doesn't have the concept of receiving messages, arbitrary messages from another place, but L2s do, right? So, this is a a difference that we should handle and an arbitrary, you know, recursive call to the state transition

wouldn't handle this. Uh, for example, and rollups today, they add custom code to handle this and we should be able to support this in like a minimal way, right? And L1, L2 messages are used for token deposits. So this is really crucial and then of course you need to go back from L2 tool one to to be able to implement token withdrawals. You should support gas token deposits. So one thing is to send messages. One thing is to get the gas token on the L2 usually uh from a token deposit but it's also something that on L1 uh is not uh doesn't really have this concept apart from there is one case but

we're going to discuss it. You should be able to uh support force transactions and it should allow for customization where possible. Uh we really like roll-ups also because they're customizable. So we should be able to support customization. For example, we should be able to support arbitrary sequencing strategies like um centralized sequencing with super fast preconfirmations. We should be able to support dedicated decentralized networks. We should be able to support base sequencing and any type of sequencing strategy like uh proof of governance type of rotation or whatever.

Ideally uh we would also want to support custom guest tokens base fee collection for example right only one the base fee is burned most of the L2s accept a linear which is a notable uh exception um they collect the base fee so they do modifications in the client to collect the base fee uh because this is something that they really want to do um so we should also be able to support this in a way or the other but the most important thing is that we should we should try to minimize the diff with a current execution layer.

Ideally, everything is inside this pre-ompile. All the other things are left untouched and also this pre-ompile itself is ideally very very simple. Um so let's try to to to try to solve these challenges one after the other. So the first that we mentioned is we need to disable B transactions. We can easily do this um inside the pre-ompile, right? So the pre-ompile you can imagine the pre-ompile having a transaction uh this as an input and you can just cycle through them and uh exclude them. So if you pass something that is a blob transaction it reverse. This is very nice

because uh all the like hop codes or instructions that are related to blobs would automatically work uh in the same way that they work uh for blocks on Ethereum where there are no blobs transactions, right? So like something like a blob hash or the blob base fee, they would all be zero or nothing um because there are no blobs, right? So this is something very easy to solve inside the XDX for pre compile. Another thing is the is rand. So again rando is something that you get from the beacon chain. The alters are not connected to the beacon chain. And if you look how the rollups handle these cases uh they handle it very

differently. So for example scroll doesn't really support randow it returns just the constant zero when you try to call it. Um arbitum returns the constant one. Uh so it's very uh interesting to see the the differences in behavior. Linear returns the constant two uh and can you guess what Zika sync uh returns? Zikasync returns uh this concept uh for reasons that are beyond me. So the only projects that kind of preserves the semantic of randow is um optimism. uh they have a concept of latest sync L1 block and they try to pass over the same

value from formula one. Uh so they have different behavior and this is kind of easy to solve because this can also be an input to to the execute pre-ompile. Uh this is something that again the the state transitional one gets from from the beacon chain and it is in this block environment that we discussed that is passed to to the actual apply body. So it can easily be passed as an input an arbitrary input uh which can also be something that you get from one and then you pass it and you constraint of course the the space of the inputs with a with a smart contract model.

Um, another challenge is how to implement 112 messages and this is related to what is called the anchoring problem which is in general how do you get anything from L12 like any piece of information and again this is not something that L1 has and the way that optimism and arbitrum solve this is with a new transaction type. So when you want to send a message from one to two, you send uh some information on a smart contract node one, usually they emit an event. Uh like in the case of optimism, there is a transaction deposited event.

Uh in the case of arbitrum is a little bit more complicated. Uh it's not just one new transaction type. They have like 10 different uh new transaction types. Um but the idea here is based on something that happens on L1 this new transaction type magically appears on the L2 uh based on some derivation rule and um instead there is another set of projects that don't want to add a new transaction type and notably there is linear which is arguably the most EVM equivalent system they try not to modify anything and I think they don't modify anything of the clients running linear so they cannot add a new transaction type which is also

what we don't want to do for native rollups and also tao does something similar to linear and what they do is instead of having a new transaction that magically appears uh when you want to send information from one to two they have a relayer that sends a transaction with a commit with a commitment uh that represents uh the messages um that needs to be relayed from L1 to L2 two and the validity of this commitment is checked inside these circuits outside of the core state transition function.

The way in the way that the way that this works at linear is that they have a permission doctor that can do this um because if the value that is passed is not correct uh the zika proof will fail. So they would have a livveness failure. uh tao is permissionless and the way that they solve this issue of passing uh run commitment is that they treat it as a n but of course treating it as a n is a modification to the EVM that linear didn't want to do. So they're also like u I guess working on a solution to this problem.

So um there are pros and cons uh to this approach. The pro of um optimism and arbitum approach is that contracts on L2 do not need to modify to support crosschain calls. And I'm about to to explain this in a second. And of course, the pro of line type is that they don't need a new transaction type. So they have u uh the diff is is uh smaller compared to L1 clients.

So what I mean by um the contracts do not need to be modified is is the following. The way that this transaction type is implemented is that they don't have a signature on the L2 because when you want to send a message from L1 to L2 the message can be already authenticated authenticated on L1. When you send from L1 you already have a message sender. So on the L2 you can create a new transaction that doesn't have a signature and has the message sender which is the same as L1 that you already have authenticated right so if you send a transaction with your UA on the L2 will a transaction will appear where the

message sender and transaction origin is also um the same address. So if you implement for example a nable contract on the L2 and you want the owner of this L2 contract to be an L1 address you don't need to do any modification because when you do a crosschain call um it already works right it will already have the proper message sender in the same way that it works for one um while for Lineia that doesn't implement this they need to additional logic to be able to distinguish uh to be able to authenticate who sent the message from L1. So you might be

familiar with this kind of syntax. This is linear as an example. But if you look at like optimism, arbitrum, they implement something very very similar which is you need to call the bridge on the L2 side where there is a method that will tell you who is the sender the crosschain sender on L1. Um so as I said in one case you don't need to modify uh one case is nice because you don't need to modify uh the contracts for example designable contracts uh but the other case is nice because we don't want to add new transaction types and what I suggest here to do for native rollups is to not add new transactions type because this new transaction type

is also something that uh would be available on L1. you would need to have a way to disable it for L1 but allow it for L2. Um it increases complexity and as I said this transaction new transaction type is nice because uh you don't need to modify the contracts on the L2 but on L1 when you need to go back from L2 to L1 you have the same problem uh because on L1 you don't have this new transaction type. So you have this UX that is maybe better when you go from L1 122 but from L2 to L1 you need to exactly implement the same uh functionality that is here on the screen. Uh so if we implement messages the way that linear works which is

instead of creating a new transaction type alto you pass a um a commitment and then you provide proofs against this commitment. um it's it's way easier and there is actually some kind of messaging that is present on L1 which is the messaging that you get from the consensus layer. So you can think about the relation that the consensus layer has with the execution layer similarly to the way that the one has with the L2 because in both cases it's one layer talking to another layer and the way that uh the consensus layer talks with the execution layer is with system transactions. So

for example there is this IP that saves the beacon block routt in the EVM and the way that this is implemented is that there is a pre-eploy on L1 where uh these block routts magically appear basically uh inside the storage uh of this transa of this contract and we could do the same uh to pass to solve the anchoring problem. how to pass messages from L1 to L2 inside the exiscript pre-ompile. We could add one of the system transactions. So let's imagine that we require these native rollups to have a pre-eploy which will call a anchor predeploy at a certain address

and you will pass uh to the execute pre-ompile uh an input which is a commitment ideally or a hash of something um which we'll call an L1 anchor and on the L2 what will happen is that this L1 anchor will magically appear in this predeploy and then the bridge on the alto side will be able to provide proofs to uh actually execute the messages and this is very very similar to the way that linear and tyco already works today uh but in the way that this is implemented it kind of reuses the logic for passing information from the consensus layer the execution layer so uh it's kind of the standard way to do it

um I was talking with uh some people in the past And as I said before, not many people are using uh the beacon, not many projects are using the beacon block route on the L2. So some projects uh were thinking why do we need to add a new system transaction and a new predeploy when we can just reuse uh the beacon beacon block route. So instead of on the L2 instead of in this pre-eploy having a become block route um let's pass arbitrary information from L1 that would be used for L12 messages and this is maybe uh this is open to to be discussed but the thing is there are some projects that want to preserve the

semantic of the brickcom block routt so I would rather have a new system transaction uh for this not to overload uh what is already um happening with with this other one. >> Um >> Luka, we have a question from Matt. Y >> um because authentication for L2 operations are also based on caller/ssage sender. Is that a question Matt? >> That was an answer. Okay. Sorry. >> Okay.

>> So my my question is why again do we need to have the message sent on the L2 be the same as the one on DL1 rather? >> No. What I'm arguing >> Yeah. Yeah. What I'm arguing is that we don't need it. So there might be an argument like I talked with some projects and they told me well maybe like think about adding a new transaction type uh because maybe we want to have this message sender. What I'm arguing is we don't really need it because first there are some projects that already don't have these and they work and when you go back from L2 to L1 you have this exact same problem. You cannot have the proper message sender from the L2. So if you're solving this problem from for L221, why not also using the same mechanism

from L122? so another thing that we want to support is force transactions. Uh this is something that we require for example for stage one uh is something really important. We really like to say that roll-ups uh should inherit uh censorship resistance uh from LU1 uh even in the presence of centralized sequencers. Right? So uh and post transactions are a very complicated mechanism. Um like here on the left I have the way that it they work on optimism. It is again quite complicated. they have a new transaction

type just to support for first transactions uh and messaging as well. Um and the way that this first transactions are derived uh is not easy. Arbitum also adds uh plenty of new transaction types uh including you know uh for example the unsigned transaction type which is the second one uh that is used for first transactions. Um, Daiko at the bottom um has this forced inclusion store which is a contract that is supposed to handle our force transactions in the context of uh preconfirmations and all of them are very complicated uh in a way and

one way that I think we can simplify so all of these mechanisms in principle are possible to support with native rollups without any explicit support like you would be able you would need to have a mechanism um to be able to collect transactions both from the centralized sequencer and from users. And then when you do a C transition, you need to have a way to check that the transactions that the centralized sequencer in sequencing includes the force transactions, right? And this can be done out of band in a way, but it's complicated. uh all projects prefer doing it without inside the state transition function or inside

the derivation. and one way that we could simplify all this work for the projects is to use fossil. Uh so fossil what fossil does is that it gets two transaction lists. One is the inclusion list and one is the list of transactions from the from the builder. And inside the state transition function, I showed here on the right um the uh modifications to the state transition function that Fossil introduces. The way that it works is is um in this apply body of course there is this environment of data. There are the

transactions but there is another input which is the inclusion list transactions. And at the end of the like block execution what happens is this function gets called which is the validate inclusion list transactions which checks that the list of transaction that is passed here includes valid transactions from the inclusion lists and this is kind of the implementation of um this this check and what I'm proposing is if L1 implements for uh native rollups would uh automatically also will be able to access this feature and they would be able to pass a separate list of transactions that they can collect in a different way other

than the centralized sequencer and and the state transition function will make sure that these transactions are included. So you know we can call this L2 fossil and the full flow of the way that it works is uh you can force transactions with L1 fossil on L1 they would uh be inserted in a Q L1 and then they would be included on an L2 with this L2 fossil mechanism through the execute pre-ompile. Um uh so this is also one reason to to kind of um uh include fossil in in one of the next forks uh in my opinion.

Another topic is how to do gas token deposits. So yes, we can send messages maybe but we need to find a way to get the gas token and the way that opisto and orbit stock work is that again they have a new transaction type that can mint the gas token. uh in arbitum is a a different transaction uh type in optimism is always the same one that has also the ability to mint the gas token. A lot of projects have decided not to add this new transaction type like a mint because it's a you know you don't want to have bugs related to to this uh notably you know linear tyco scroll and also polygon zvm decided not to

implement a transaction that can mean the gas token. So the way that um the way that users can get the gas token in these projects is using the regular L12 messages. So this is a screenshot from scroll uh the L2 side of the scroll bridge. And if you look at the balance uh of this bridge is I think max uh of something uh it's a very very big number. It's a it contains preminted tokens and the way that you get uh the gas token on scroll and also these other projects that I mentioned is by unlocking uh this uh preminted tokens. So you

don't need a new transaction type. You can just unlock from an escrow that premints. Uh so this is kind of again a pretty standard way to handle this case. Um, and the cool thing about this is that it's with this method, it's trivial to support custom cast tokens because to to unlocks uh to lock these tokens, you need a message and what message triggers the unlock can be arbitrary. So for example, it can be an deposit on L1 triggers the alloc tokens or it could be a deposit of USDC.

Uh, and in this case, you basically would have a native rollup with a custom cast token that is USC or it could be another ERC20 or it could be an NFT or it could be some mining uh mechanism or it could be a pool of 10 stable coin. Um, like with this method, it's very trivial to to support custom gas tokens. Uh, and it's like very exciting that this is possible to to do also with native problems. Um so this is also a fun problem uh to have which is the first deposit problem.

Uh this is a problem that's many projects already have and of course all the like L1 also have which is if to claim these tokens I need to claim a transactions on the L2 right but it's the first time that I'm depositing I don't have the gas and I'm doing this transaction to get the gas token. Uh so like how can how can I first get the the gas token? I need someone else maybe a relayer to to claim uh this first transactions for me and there are you know mechanisms in some projects that do this or I need to use maybe an intent protocol but it's kind of weird. So um the way to solve this is first maybe

we don't solve it because again this is a problem that exists in other projects. So maybe it is not worth it uh since these other projects are kind of doing fine without an explicit mechanism. And by the way both optimism and arbitum do not have this problem because they have uh this new transaction type token but all all the others that I mentioned have this problem. So there is a mechanism that allows to mint actually the gas token on L1 and this mechanism are is uh withdrawals uh withdrawals from the beacon chain. So when you withdraw some ETH from the beacon chain you actually are minting ETH on the E on the execution layer. So in principle if we want to uh solve this

problem which again is not necessary but maybe it's a nice to have uh we could allow another input to the execute pre-ompiler which is a withdrawal field and if you look at the way that L1 processes withdrawal basically um it does this by uh increasing the balance of the of the of an address without any action. Uh so this is also something that is uh let's say that could be reused from what one already happens. It's a little bit weird to use withdrawals for deposits.

Uh maybe uh it's kind of an overloading of the mechanism but something to keep in mind. Uh another challenge is how to collect fees. So the the state transition function in this block environment again is passed to the apply body. One of the paramps is the coinbase which is the one that collects the priority fees and this again can be an input to the execute pre-ompile. So there are a lot of inputs right um and this could be a DO this could be a multiig this could be whatever you want. So there is a way to collect the priority fees very easily and this is something that of course roll-ups want to do because it's kind of their business model. Um and this is an

example of you know um a modification that um OPAC does to collect the base fee because again collecting the priority fees is kind of easy but the base fee is burn. So if you want to collect the base fee usually you need to modify the L1 state function and if we can we would rather avoid it and there is a very simple way to to do this uh which is by that I found which is a basically a oneline change or two line change depending how you count um which is instead of modifying the client to not burn the base fee and redirect um to

a multisync let's say what we can do is we can count the amount of it that is burnt and then provide it as an output. Uh so this is the modification that would be uh outside of the execute pre-ompile and the only one that I actually found that is needed but it's very simple because it's it doesn't modify anything. is just reports in the output uh what is the amount of fees that have been burned and then um what you can do with this value is that you can pass it on one and a smart contract on one can for example credit it credit uh this value to a multisc would be able to withdraw this balance

from the L1 escrow because otherwise if these fees are burned this would be uh funds that are stuck in the bridge and no one can withdraw uh but if you have this information of how much you've burned, you can credit this amount to to one single address. So this is a very simple way to support um collecting the base fee without major modification to to the client. One big challenge uh for which I don't have a good solution is um that most L2s handle the fear market a little bit differently compared to L1. So uh the difference between L2 and L1

transactions is that L2 transactions also need to take into account the cost of posting the call data inside blobs. So what these projects do is that they add a new field um in the pricing which is the L1 gas price or the L1 gas used that you can see for example here in OP stock or in orbit room or in in scroll there are maybe a couple of solutions.

So one solutions one solution is what Lina does which is nothing uh simply they don't have this additional uh field but what they do is that they have a a new RPC API call that you can do where it kind of suggests you what is uh the price that you should set the priority fee that you should set so that the centralized sequencer will include you if you pay enough. Uh they will basically censor you and you know you might need to to go through force transactions or whatever. But this is intended to be to be used only for projects that don't pay enough. Sorry,

for users that don't pay enough to cover the uh to cover blobs. which is you know maybe it works but it's not uh like there must be a reason why these projects want to add this different transaction fee, right? uh I tried to look at some new EAPs here on maybe there is a way to solve this problem. One of them is this unified multi-dimensional fee market that was proposed to for inclusion for Glamsterdam which basically adds yeah this multi-dimensional uh fee where one dimension can for example uh be calculated

uh based on another dimension. So you could imagine for example if you pass the information of the blob base fee from L1 to L2 you could have a mechanism that kind of uh conditions the L2 call data dimension based on the L1 blob dimension but in the way that this is implemented in this I don't think it works uh very well. uh if you look at the way that this is implemented for example in opist stock it's a linear formula more or less uh a linear relation um but in general as I said I don't have a good solution to this problem but this

is also a problem that the L1 uh zk upgrade will have because in the future when ethereum upgrades to zk ideally L1 itself will use blob right And if L1 uses blobs, uh there's also needs to be this translation between call data that is posted to L1. Uh and that needs to be translated in the cost of posting to blobs. So I have the feeling that this problem will kind of solve itself uh when the Ziki team will start to think about how to support blobs for for a one.

H another one is another challenge is how to support uh past blobs references. So the way that roll-ups work today is that first they sequence transaction they post them in an inbox and then at a later time they prove uh these transactions the execution after these transactions. Um so L1 instead it's different. Uh when you post transactions you need to execute them and with VKL1 it's also the same. That's why we we're interested in real time proving. You post a block you need to prove it. You post a block you need to prove it. Here instead there can be more or less arbitrary delay. And

this is needed to for example um some projects do this because they only want to generate proofs when the ordering is finalized. It might be a risk to prove things before because you might waste some ziki proof but mainly because you want to have one proof for multiple blobs, right? uh instead of L1 you kind of have again as I said one block one proof in the rollup world usually have multiple blocks one proof and it's kind of an open question how to how to support this uh if L1 decides to support for example recursive

uh proofs in the in a similar fashion as Mina protocol where they have just one proof to to prove the whole history maybe it is possible to to support this very easily and also one other constraint um yeah that I wanted to mention that we need to have is um we need to know uh that the data is available when we call the execute pre-ompile right and the way that it works for uh existing rollups is the post blob blobs they save the blob hash and the execute pre-ompile doesn't take the full blob as an input it only takes takes a commitment which is a blob hash as an input and the x2 pre-ompile has no

idea that the data was available because the data availability check is done usually in the box which is another construct. Um, and since we want the the execute pre-ompile should know that the data is available because we want to be able to detect bugs like let's say there is a bug in ZK. Uh we don't want to allow calling the execute pre-ompile with data that is not available because otherwise we will not be able to reexecute naively and detect bugs. So for this reason we need to have a way in the execute pre-ompile to be able to reference blobs that are in the past not through a blob hash because again a

random hash doesn't give us the guarantee that the data was indeed available but something that actually references the the actual blob that was available. The blob hash doesn't work here as I said because blobs the blob you can only use blob hash in the current transaction in the current transaction environment. you cannot reference, you cannot call blob hash in the same way that you can call block hash. Uh it's quite different. So we will need to have a way to support this. Uh but again I think I don't have a good solution yet. Uh I think it's solvable.

Uh but I also think that uh the way to solve this will become clearer uh once we get closer to ZKL1. So I have a couple of challenges left. Um this one is whether the execute pre-ompile should do a recursive call to the state transition function or only the apply body. And the difference here is that um the apply body if we do a recursive code to apply body we can skip the header checks and the header checks are not really fundamental.

uh like if you think about the original proposal by Justin Drake that was done in January this year uh the way that the interface of the execute pre-ompile was proposed is you have a pre-state root a postthood a trace and that's it maybe guess used but that's irrelevant um it doesn't have all the information that we usually have in a header right uh we don't have block hashes we don't have gas used we don't have bi um And so one natural question uh that I had is you know I was looking at uh block access lists and uh one of the reasons why we want to have native rollups is that they get the features

that one also has. But if we implement this native rollups will not be able to to get block level access automatically because this information is a header information something that is validated within a header. Uh and this is you know kind of the spec that I was looking at. Um which is you have the apply body here but the actual check of validity of the block level access list is outside of the apply body as in the this is the state transition function. So I have a spec or the execute um a draft of a spec but it's actually two drafts which is one that uses the apply body.

Uh so it it is it only provides the minimal things to do this state transition and one that reuses the state transition but also includes the other checks. It's an open question whether we should use this one or the other one. My feeling is that the transition one is better because we want to be more similar to what Telvan does. And the final challenge is that okay we do this recursive call to the state transition function either it being apply body or state transition but and if anything changes inside the apply body for example there is a new transaction type let's say 7702 uh or there is a new pre-ompile or there is a new way to I don't know something new inside this anything a new

instruction right all the native rollups would automatically get this upgrade of course because it's a recursive call. This function changes also the one that the Pop uses changes. But the thing is what happens if this function is updated like the interface uh not inside but the interface of this function is updated. And you might think that these interfaces do not change very often. For example, the state transition function is super simple. It's a blockchain and a block. Why would you ever want to change this interface, right? And the thing is that um it actually does change. Uh in in Fossil, you don't have a blockchain

and a block alone anymore. You also have an increased list and it is an open question how the execute pre-ompile would be able to support these cases. Um may like in most cases maybe it is possible you know not to add a new input and just have a default value. We could be which could be an empty in this case list but we might want to support inclusion list. So it's an open question whether uh an execute pre-ompile would imply also maybe in the future having you know execute one execute two which is kind of ironic uh if you think about the goal of of native rollups but this is of course only

um like most of the other changes would uh would be able to we would be able to support um and that's all I had um thanks I have this uh book um which you can find at this QR or at this link where I collected all this information that I kind of explained with also the draft of the pre-ompile uh the spec of the pre-ompile and you know more in-depth information about all these topics and happy to chat uh if you want to learn more.

>> This is amazing. Thank you so much, uh, Luca, and I'm so glad that, uh, you're championing this and, uh, and making so much progress. We have Peter that has his hand up. Peter, go ahead. >> Yeah. Hey, thanks for the great presentation. Uh, you mentioned a couple of times that native ROS might incorporate some L1 information like for Randall, we might relate the latest Randall or relate the latest album hash as the anchor. I'm curious if we talk about non-based native roll apps. So in that case kind of the sequencing is async the sequencer creates a batch and submits it to the next block or maybe couple of blocks later. So by that time this uh environment might have changed.

In that case would that invalidate the batch? Would the native roll up fail or would that possibly change the execution outputs and invalidating the the premps that the sequencors should? >> Yeah. So the way that they see this is uh for example randow is a simple input to the execute pre-ompile. So if you're based uh you can constrain this input to be the same as the one where you sequence the block in in your base block. If you're not based for example you can decide not to support altogether and always pass a constant zero or a constant one or two depending on on the project. Um or what you can do is

uh similar to what optimism does which is they don't provide the latest uh randow value on L2 the latest that is on L1 they provide the latest synced uh value which basically means that you might have some extra logic when you sequence that maybe collects the rando beforehand or and then like the execute pre-ompile has no uh constraint on on this value like this is a simple input and you decide

yourself how to pass it. So if you want to uh for example support preconfirmations, you need to have a way to and you was you want to pass the correct value, you need to have a way to check that what you passed is uh was present at some point on one as well. But this is again all outside of the execute pre-ompile. If you don't want to deal with this, just pass zero, plus one, plus two, plus whatever you want, and the pre-ompile will work.

Jordi is asking, instead of adding a pre-ompile, why don't you just expose the verification key of the ZK circuit inside the state transition function? >> Yeah. So like the actual way um this is implemented in the client I'm not sure uh because also this is very dependent on the way that L1 will verify Z proofs. So in whatever way L1 will do this, we will use the same exact mechanism and the difference is L1 will get the pre-state that one has and uh the native rollups will get will use

the same stack but with their own state. So if this is done you know with the execute pre-ompile or not uh really depends on how ZL1 works uh but this shouldn't really modify uh anything that is said here or right so there is a world Jordi where we have this notion of an enshrined ZKVM where we pick a single one and here we would have the verification key basically be burnt into consensus.

But there's like previous stages in the shorter and more medium term where um you know some of the validators they if they choose to not run a ZKVM they can just run it the normal way. And even if you do choose to run uh a ZKVM there would be a multitude of them not just one. Uh and there might be some logic like like K of N. So three out of five or two out of three uh would need to agree. Um, and by not enshrining these ZKVMs, you can fix bugs, for example, much faster without doing a hard fork. Um, and there there's just generally more flexibility. And it's a similar setup to what we have today with

client diversity where the validators are choosing uh which uh which clients to to run. And this is something that I didn't mention but there is also a word where uh we use risk five instead of uh EVM and you could in principle pass as an input the host program. Uh so you would have you could for example uh use the EVM uh the host program of the EVM which is which would be kind of enshrined uh in the context of risk 5. Uh but in principle you could also use the same zika stack but with a different host program. Uh and in this case you would

be able to we would be able to support native rollups with uh arbitrary execution environments which like arbitrary VMs which would be very cool. Uh of course with some trade-offs >> can I say something? >> Yeah. Just I mean the idea is not to I mean the idea is to be much much less invasive. I mean you just publish the the verification key and the clients they don't need to do anything else. I mean if you want to use this you just implementing your own smart contract. I mean your own smart contract you just read this key and if and you roll up you just read this key if you want it. And the idea is that you you can even uh have different versions of this verification key maybe for different uh zk rollups. So the implementation is

very easy. It's just publishing the a verification key which can even be wrong but the client doesn't do anything else. just you just guarantee that in each fork you have a new verification key that theoretically follow the same the same transition function but the client so you need to you need to implement if you want to use this you need to implement a smart contract that actually do a verification that actually verifies the the verifies what I mean whatever you want to verify I mean you verify the so you you send a proof to the smart contract and the client only verifies the proof that's it like any other proof but you don't need to do anything else I I think this as a previous version I mean as a transition maybe the the final solution is a a full pre-ompile but

a good way to start is just this is just putting one key in a state that's it >> yeah I guess one downside of putting one key in a state is that you might not have EVM equivalents so the L1 EVM might go down one fork and then if there is a bug for whatever reason in the verification key then it will go down a different fork. So imagine for example if 60% of the validators are running with normal nonZK validators that's a different situation where 60% are running with ZK validators and and they they might fork off um does that make sense? Yeah, I mean you

just Okay, we can move move forward. Just can talk about that. >> Sounds good. Um, Alex from Lineia is um talking about the economics of of settling ZKPs and basically um one of the questions is related to the gas cost of the execute pre-ompile. Is that completely free and handled by Ethereum or is there a gas cost to calling execute pre-ompile? I would expect uh there to be a gas cost uh based on the cost of verifying the zik proof. So I would expect the cost to

be very very small. Uh but yeah, I would expect there to be to be a cost like this is like in the way that I proposed this uh right now it's uh with a a pre-ompile call. So you would have a way to to price this uh this call. But again, this very much depends again on the pricing. This is also for ZL1. Jiune in the chat highlighted that on October 7th there is a fossil session, a fossil call uh which will discuss the intersection of native rollups and fossil. So if you'd like to join um it's in the uh the Ethereum uh calendar

public calendar, but you could also message Whale or June. Um, Jordy also had a comment around an elegant way to pass messages where you only send the state route of the L1 to L2s and you store the L2 states in L1. >> Sorry, >> do you want to expand on your comment, Jordi?

>> Oh, yeah. I mean, this is a much simple way to for all the messaging. Of course, this requires maybe extra work inside each chain, but from the communication perspective, instead of sending messages back and forth, uh if you just uh have a way of transferring the the state route of the L1 to the L2s and then the state root of L2s to L1 that you just store in the state, you can always prove uh something inside the L2 that you deposit something in L1 for example or that you send some messages in L1. But the idea is that just passing a single hash I mean just passing a single state route of the chain this is enough this should be enough for transferring anything and

this is a very simple way of course this adds a lot of work in the inside the clients because I mean you need to but here with zk you can you can also prove whatever you want in L2s regarding L1's requires some extra zk um extracting I guess you need to go through all the patricia trees and this has another complexities for managing the state but from the communication perspective this is very simple and then it's just a single just another parameter which is uh uh the L1 uh state route that you pass. >> Yeah. Yeah. Exactly. So I I looked into the way that this works for different projects and you could pass the L1 state route. So first you you need to have the mechanism to pass something uh which is I propose to do with a system

transaction. Um but of course there could be different ways uh to do it. Uh I think Tao uses the L1 state route and provides all the Merkel proofs uh to to get the messages which is kind of expensive but I would expect also all the work on statelessness to help with this work uh to make it uh to make it cheaper and simpler. uh but a lot of projects pass arbitrary information like for example linear passes a rolling hash of the messages and then on the L2 kind of proves all these uh messages in the rolling hash and what I propose is let's make this uh as general as possible let's allow like let's allow all the projects to pass an arbitrary commitment

and then decide by themselves how to handle this it could be a state route if they want to it could be a running hash of messages or or anything Okay, so uh we are out of questions. Um thank you so much uh Luca. I guess if anyone would like to help with this effort, uh please uh please feel free to to reach out. Um, I think at some point it'd be nice to have an EIP. Um, and uh,

I believe that Luca hasn't written an EIP yet. So, if you're familiar with the process and would like to to to collaborate, um, feel free to to reach out again. And, you know, we're going to need help with tests and devets and and all sorts of other things. So, um, yeah, plenty plenty of work to be done and, uh, yeah, very again very grateful to have Luca, uh, helping out. On that note, thanks again everyone for joining and see you on the proof call number six. Bye.