Advancing OP Stack to ZK Rollup: Achieving Efficiency and Security with Zero Knowledge Proofs

자막 제공 및 자막 제공 및 광고를 포함하고 있습니다. Hi, how are you guys doing? So I'm TA, aka FakeDev. I'm a ZK engineer from Chroma. So today I would like to share our experience of advancing OP stack into ZK rollup.

So we're trying to enhance efficiency and security with zero knowledge proofs. So for those of you who don't know about Chroma, I want to first celebrate our successes from last year, our mainnet launch. So we were one of the projects built on OP stack, so we're one of the first, I mean we're the very first optimistic roll-up with an active fault-proof system. So we utilize ZK proofs for it. And so ZK enables to solve some problems in traditional fault-proof systems.

And first we approach with a circuit-based implementation of ZK provers, but it has a very, very big issue. So we're trying to transit from circuit-based approach to ZDK VM-based approach. And lastly, we're also building a ZK backend library to push the boundaries of proof generation speed. So why ZK fault proofs? So in traditional fault proof systems, it requires a lot of interactions, which leads to high bond amounts, which decreases the level of decentralization.

So with ZK fault proofs, we can just narrow it down to a block level instead of instruction level, which requires much less interactions. So it not only reduces the operational cost itself, since there's less interaction, so we need less computation, but also it can significantly reduce the bond requirement. So it naturally leads to better decentralization and security of the network. So moreover, for like arbitrage fold, if we apply ZK technology into it, we would be able to reduce the bond requirement significantly that is usually used for blocking Sybil attacks. Also Optimism is putting a lot of resources into exploring ZK fault proofs.

So we have an announcement that we have received retro PGF round 5 from Optimism to explore more on the ZK fault proof size. And this recognition, I think, shows how much important and possibilities are there into building a permissionless fault proof system with ZK. So we've looked at our achievements since last mainnet launch. And now I would like to share some of our lessons learned and challenges that we've experienced for building ZK file proof systems in our mainnet. So the very important fact that we learned is that the circuit-based approach is just not sustainable.

So we currently have about 100k lines of code, which are for custom circuits. So we have to write it in a circuit language like Plunkish. And it's very, very hard to write and debug and verify. So what we're trying to do is check the integrity of EVM state transition function. But we need several specific custom circuits written in circuit languages to verify that the state transition function, given the input, is done correctly.

And back in 2022, Vitalik even mentioned at the time there was no like production ready ZK EVM circuit codes, but they had a POC version of it in Ethereum's PSE. And back in the days, it was like 35K lines of code. But even Vitalik mentioned that it's never going to bug free for a long, long time. So it's very prone to errors, very prone to human errors. So to sum up, there are two challenges.

Writing the circuit itself is tough because it's hard to audit and debug. And also, since Optimism and Ethereum keep bringing upgrades to their mainnet to support full compatibility, we have to keep up with the protocol upgrades they're making, which means that we have to modify circuits again and again 메인넷을 통해 전체 공정에 도움이 되는 경우, 프로토콜 업그레이드를 계속 만들어야 합니다. 즉, 업그레이드들이 계속 늘어나는 때마다 모든 공정을 계속 변화시켜야 합니다. 이런 경우, 더 많은 변화를 만들면 더 많은 error의 가능성이 생길 것입니다. 이는 메인넷의 안전을 부담할 것입니다.

그래서 더 좋은 방식이 필요합니다. 저희의 메인 넷의 확장에 영향을 미칠 것입니다. 그래서 우리가 더 좋은 방법을 필요로 하고 있습니다. 그래서 지금 저희가 ZKVM에 대한 방법을 고려하고 있습니다. ZKVM은 우리에게 전형성과 정의성, 즉, 이 방법의 의미는, 제가 말했던 루틴 적용 방법에서 루틴을 Plunkish 같은 루틴 언어로 적용해야 합니다.

이것은 매우 불가능합니다. we need to write circuits in a circuit language like Plunkish, which is very unfamiliar. And because of that, the auditors will also have a hard time auditing, and even us can't really verify well that our code is written well. But ZKVMs allow us flexibility. We can write any program that we want to verify the computation in Rust.

And since it's written in Rust, it's very, very better to audit and debug. So now I would like to dive in more to ZKVM area. So how we are trying to move on from circuits to ZKVMs. So as I mentioned, ZKVMs can provide a general purpose environment for verifiable computation. So what it means is that we don't need to implement circuits anymore.

We can just write Rust program and ZKVMs can basically execute the program and give a proof which proves that the computation was done correctly. So how it works is, first, each ZKVM vendor would have a compiler toolchain that can compile a Rust program into, let's say, if it's based on RISC-V, it would turn into a machine code based on RISC-V에 의해 기술을 만들 수 있습니다. 그리고 ZKVM 안에, 프로그램을 실행하는 기술이 있습니다. 이 기술은 실행 트레이스입니다. 실행 트레이스는 기본적으로, 기술의 규모에 따라서의 폴리노미오가 있습니다.

그전에는, 기술을 적용해서, 기술의 인풋 데이터를 폴리노미어에 적용하고, 그 다음에는 그에 대한 규칙을 얻을 수 있습니다. 그런데 지금 ZKVM 실크리티는 그것을 해결할 수 있습니다. 그래서 지금 우리는 그냥 Rust 코드를 적용할 수 있습니다. 더욱 더 flexibly. 그리고 ZKVM가 실크리티를 적용한 후에, execution trace, it would commit to the trace and then generate a proof.

So I have a summary kind of picture that we can compare, like how it's different. So the colored green parts are the code that we used to maintain and we have to maintain. So back then, we would have to maintain like ZK EVM circuits written in Plunkish에 적혀 있는 ZK EVM circuit을 지정해야 했죠. EVM, ROP, NPT, 그리고 통제 circuit가 있었죠. 이는 EVM의 행동을 반복하는 것이죠.

그래서 이는 통제 체계와 통제 체계의 연계를 확인할 수 있었습니다. 예를 들어, 블록 헤더와 블록 바디와의 비교는 핸셋과 블록 캐시를 비교하는 것입니다. 이것은 우리가 사용할 때 사용하는 것입니다. 하지만 매우 어렵습니다. 그런데 지금, 오른쪽에는 ZKVM의 시선이 있습니다.

ZKVM 시선은 그것을 대응할 것입니다. 대신 블록 실행 프로그램을 적용할 것입니다. circuits would handle that and instead we will just write a block execution program which for us as an Ethereum layer 2, we would derive the batch from L1 and then execute it on L2. So that would be the program we were trying to write. And some of you might ask like Vitalik mentioned in 2022, we launched our mainnet in 2023 and then then why didn't you guys first approach with ZKVMs at first?

Why did you guys write circuits and do all that hard work? That's because back then, ZKVMs were not performant. So since the proving time is long, within the challenge period we have, there can be possible attack vector for delay attacks. So that's one of the reasons why we chose a circuit-based approach. But now, risk zero calls it continuation and SP1 calls it sharding.

There was a breakthrough called sharding, which with the full execution trace, you can now divide it into a unit called shards. So it's usually represented in the number of cycles of RISC-V. So SP1, they kind of have an optimal number of like two to the power of 22 22차체의 수단을 사용할 수 있습니다. 수단을 나누어 분리할 수 있도록 수단을 사용할 수 있도록 수단을 사용할 수 있도록 그리고 나중에 한 개의 수단으로 수단을 공급합니다. 이제는 수단을 공급할 수 있도록 더욱 높은 수단을 사용할 수 있습니다.

그래서 우리가 노력하고 있는 것입니다. 그리고 거의 메인 네트에 배송되고 있습니다. We can parallelize proofs. So that's what we're trying to do. And we're almost there, shipping it to the mainnet.

And now I want to share more of my thought that what we can explore more in the future to overcome barriers to become from an optimistic rollup to a ZK roll-up. So my concerns about ZKVM-based approach is since ZKVM vendors business model is usually running a prover network, so they get a delegated proof and then they generate a proof for it and then return the proof to the client. But there might be a situation where ZKVM prover network might fail. So usually ZKVM vendors, since they've built their ZKVM, they're very, very good at giving a good performance. So usually they will have a cluster of machines, and then they would split the workloads to each machine, and then orchestrate it, and then create a proof and return.

But since most of the such proven network-related codes are closed-sourced, maybe to handle this kind of network reliability issue, we might have to, like us, Chroma, might have to implement a code to orchestrate multiple machines 크로마는 여러 기술을 모아야 할 것입니다. 모든 validator가, 이 내용이 맞는지 모르겠지만, 네트워크에 증명을 받을 수 있는 클러스터를 운영해야 합니다. 또 다른 문제는, 지금 단계 1 롤업이 더 많을 것입니다. Another concern might be, so now there's going to be more stage one roll-ups, but for stage two, we only want the security console to come in and resolve the problem if the failure is only on-chain provable. But currently, in my perspective, for the ZKey VMs, currently there's no way to make the network failure to be on-chain provable.

So that's another concern. ZK VM의 경우, 네트워크 실패가 안체인으로 인정될 수 없다는 점이 제 생각입니다. ZK VM의 경우, ZK VM이 부가가 될 수 있을 수 있습니다. 그래서, 우리가 부가를 감소시킬 수 있는 멀티 프로브 시스템을 필요로 해서 그에 대해 버그에 대처할 수 있는 것을 생각합니다. 그래서 그 경우에는 네트워크의 확장력을 향상시킬 것이며, 하지만 상승을 원하지 않습니다.

그래서 우리가 더 오래 사용할 수 있는 시기가 없기 때문에요. 그래서 멀티 프로브 시스템의 3가지 종류가 있을 수도 있습니다. three types of multi-prover schemes instead of having a single prover. One, I think most of the networks like scroll and Tyco is trying to use T's. In my opinion, there's a trust issue that we have to trust the T implementation itself.

There's also hydro centralization problems, so we might have to come up with a clever idea to maybe use three vendors of Ts and then have a multi-sig kind of thing. And another one would be kind of very, very labor intensive, but come up with another circuit-based CKVM. So instead of Plunkish and Halo 2, another circuit-based ZK-EVM. So instead of Plunkish and Halo 2, you might have to write another ZK-EVM circuit code with another language. I don't think no one will try that.

And I think the best would be our approach to have another ZK-EVM-based ZK-EVM. I'll tell you why we think this is the best. And if we have a multi-prover system and if we have ZKVMs now, we could really, really easily ship ZK roll-ups than past one or two years. But I've did some benchmarks. 제가 ZKVM을 사용한 적은 몇 개가 있습니다.

하지만 아직도 비용이 부족합니다. 첫 번째는 비용 범위를 제공하는 것입니다. 이것은 매우 중요합니다. 제 의견으로는, 사용자에게 사용할 수 있는 것을 매우 어렵게 계산할 수 있습니다. 대부분의 레이어2, charge the users to use it since most of the layer 2s and most of the optimistic rollups now have very very cheap fees.

So there are three types of costs that we need to pay to run a ZQ rollup. First, it's the biggest bottleneck which is the proving cost. So I've tested with a network with about three TPS, and you need about a million dollars for proving the blocks for a year. So I think it's not that feasible now, and also we would have to commit to the batches we've settled into layer one, so there will be settlement fees also. And to finalize the blocks, we would have to send the proof to the contract and verify on chain.

So there's also going to be verification piece. But that's gonna be really really small because we will be able to aggregate proofs inside a ZKVM, which will be way cheaper. But there's to be trade-off between finality. And also we could explore more on future directions where I introduced the multi-prover system and also the CKVM vendors would have to consider more about prover decentralization where they don't keep the clusters running on only their network and getting proof requests, but instead have an incentive mechanism so that Prover network can be decentralized a bit more. We're also pushing, at the same time, pushing the boundaries of proof generation.

We have our own very unique open source library called Tachyon, which is a particle that's known to be faster than light. 저희는 자키온이라는 독특한 오픈소스 라이브러리를 가지고 있습니다. 자키온은 빛보다 빠른 공간이라고 불리는 공간입니다. 자키온은 모듈러 CK backend 라이브러리입니다. GPU 확장 기능도 있습니다.

Halo 2를 통해 CK VMM을 구축하고 있습니다. 먼저 Halo 2를 많이 정리를 했고, 저희는 1.5X, 6X 더 빠른 벤치마크를 가지고 있습니다. 그리고 저희는 지금 SP1 ZKVM을 사용하고 있습니다. 그래서 저희는 Plunky 3를 정리를 하고 있습니다.

SP1에서 사용되고 있습니다. 마지막으로, CIRCUM은 매우 많은 공간에서 사용되고 있습니다. optimize Plancky3 as well, which is used by SP1. And last, since circum is very, very widely used in the community, we also optimize a lot in terms of rapid snark. So it's also faster.

And we could wrap up into this one figure where if Chroma has a multi-CKKVM prover backing the network, we would also have Tachyon, which is a modular ZK backend library, which could support all kinds of ZKVMs. So we would only have to maintain the very front, like ZKVM main, which is written in Rust, and which mainly uses the library Kona, which is maintained from Optimism, which has block derivation logic and execution logic, so we could easily write a program for our mainnet within like 200 lines of code. And we would have an input, which would be the block we were trying to prove, and we would have a multi-prover, like one of the frontiers, RISC-0, SP1, O1VM, Alida, maybe. And then we have Atakion, which is backing with powerful GPU optimizations, which will accelerate the proof generation speed. Yep, that's it for today.

And you can contact me with fakedev999 on Twitter, Telegram. Yep, that's it for today. And you can contact me with fakedev9999 on Twitter, Telegram. Please contact. We can share more about fault proof systems.

I would like to hear your ideas. And that's it. Thank you. . You can just stay over here.

All right. Great talk, TA. So thank you to the crowd for submitting all these amazing questions. We do have less than five minutes to go through some of them. Let's go through the most upvoted one.

How is it different than OP Succinct? Yeah. Some of you guys might know and not know, but OP succinct and us, we have a very, very similar logic. Actually, we were working underwater for about two months. We shared it to the SP1 team about, oh, we have a Proma SP1 prover repository.

You could take a look if the logic would be 있습니다. ZKVM-based Prover에 대한 정보가 정확한지 확인해 주시면 좋겠습니다. 그리고 그들은 동일한 정보를 사용하고 있습니다. 거의 비슷한 정보를 가지고 있습니다. 그리고 그들은 제가 말씀드린 동일한 정보를 분류하는 것에 대한 추가적인 기능을 가지고 있습니다.

그래서 정보는 비슷하지만, of what I mentioned of aggregating the proofs. So the logic is very similar, but basically we built the same thing. So I'm going to mark this as answered. Any stats on prover cost, specs, and time? So the prover cost for our fault proof system for about a block with a TPS of 3 to prove a faulty block of TPS 3, I think it costs about like, currently, so it depends on the pricing of the prover network you're trying to use, but if you're just using an on-demand plan, which would be the most expensive per cycle, if I remember correctly, it was about like 20 bucks for a block with about like TPS3.

And the stats and the machine specs, it's not revealed at the moment for SPO and Prover Network, so I'm not sure about that. All right. Do you know if the Arb ecosystem have similar plans? Yes, I definitely know. And I also know the fact that they have a fast withdrawal feature now with zkproofs.

I didn't have much time to like deep dive into it, but I definitely think like Arbitrum also is going through the right path, so maybe we could collab more and talk more about it. Alright, great. So we can go through, I guess, two more questions real quick. In your prior implementation by Plunkish Circuit, you mean Plunky 2 or 3 or something custom? Oh, it's actually Halo 2's Plunkish arithmetization.

It might have confused you a little bit, but we're using a back end currently, Halo 2. All right. So one last question. What happens if the guest program panics? Can you still produce a proof?

So if a guest program panics, then you can't produce a proof. So, I'm not sure the person who is asking the question is intentionally panicking the program or not. But like, yeah, if it's a bug that's causing panic, then proof is not produced. So this is one also another thing I mentioned in the slides before is we need a way to like overcome if the program panics but if it's a bug inside a CKVM or if it's a bug in a program then we would need a way to verify it on chain or have a way to prove it on chain so that security counsel could intervene or what. All right.

Great. So our time is up. Thank you so much, TA.