NewsFlash Articles Data Fundraising BlockBeats Pro

Will OP+ZK, Hybrid Rollup become the ultimate future of Ethereum's scalability?

Jaleel加六

Read this article in 15 Minutes

The future of Ethereum Rollup is actually a combination of two main methods: ZK and Optimistic.

Original author: @kelvinfichter

Translated by: Jaleel, BlockBeats

I am recently very convinced that the future of Ethereum Rollup is actually a combination of the two main methods, ZK and Optimistic. In this article, I will try to explain the basic points of this architecture as I imagine it, and why I believe this is the direction we should move forward. Please note that I spend most of my time studying Optimism, which is Optimistic Rollup, but I am not a ZK expert. If I make any mistakes in discussing the ZK aspect, please feel free to contact me and I will correct it.

I don't intend to go into detail about the workings of ZK and Optimistic Rollups in this article. If I were to spend time explaining the essence of Rollups, this article would be too long. So this article is based on the assumption that you already have some understanding of these technologies. Of course, you don't need to be an expert, but you should at least know what ZK and Optimistic Rollups are and their general operating mechanisms. In any case, please enjoy reading this article.

We start with Optimistic Rollup

A system that combines ZK and Optimistic Rollup was initially based on the Optimism's Bedrock architecture. Bedrock was designed to be highly compatible with Ethereum ("EVM equivalence") by running an execution client that is almost identical to an Ethereum client. Bedrock takes advantage of Ethereum's upcoming consensus/execution client separation model, significantly reducing the differences with EVM (although there will always be some changes in the process, but we can handle them).

Like all excellent Rollups, Optimism extracts block/transaction data from Ethereum, sorts this data in a deterministic way within the consensus client, and feeds it to an L2 execution client for execution. This architecture solves the first half of the "ideal Rollup" puzzle and provides us with an L2 equivalent to the EVM.

Of course, the problem we need to solve now is to tell Ethereum what happens inside Optimism in a verifiable way. Without this, smart contracts cannot make decisions based on the state of Optimism. This means that users can deposit funds into Optimism, but cannot withdraw their assets. Although one-way Rollup can be achieved in some cases, in most cases, two-way Rollup is more effective.

By providing a certain commitment to the state and proving that the commitment is correct, we can inform Ethereum of the state of all Rollups. In other words, we are proving that the "Rollup program" is executed correctly. The only substantial difference between ZK and Optimistic Rollups is the form of this proof. In ZK Rollup, you need to provide a clear zero-knowledge proof to prove the correct execution of the program. In Optimistic Rollup, you can make a declaration without providing clear evidence. Other users can force you to participate in a "game" of back-and-forth scrutiny and challenge through challenges and questioning of your declaration to determine who is ultimately correct.

I don't intend to go into detail about the challenges of Optimistic Rollup. It's worth noting that the latest technology in this area is to compile your program (in the case of Optimism, Geth EVM + some edge parts) into simple machine architectures such as MIPS. We do this because we need to establish an interpreter for the program on the chain, and building a MIPS interpreter is much easier than building an EVM interpreter. EVM is also a constantly changing target (we have regular upgrade forks), and it cannot fully contain the programs we want to prove (there are also some non-EVM things inside).

Once you have built an on-chain interpreter for your simple machine architecture and created some offline tools, you should have a fully functional Optimistic Rollup.

Turn to ZK Rollup

Overall, I firmly believe that Optimistic Rollups will dominate in the coming years. Some people think that ZK Rollups will eventually surpass Optimistic Rollups, but I do not agree with this view. I think that the relative simplicity and flexibility of Optimistic Rollups means that they can gradually evolve into ZK Rollups. If we can find a pattern to achieve this transformation, then there is no need to work hard to establish a less flexible and more fragile ZK ecosystem. We can simply deploy it to an existing Optimistic Rollup ecosystem.

Therefore, my goal is to create an architecture and migration path that allows existing modern OP ecosystems (such as Bedrock) to seamlessly transition to the ZK ecosystem. I believe this is not only feasible, but also a way that goes beyond the current zkEVM approach.

We start with the Bedrock architecture I described in my previous article. Please note that I have already briefly explained that Bedrock has a challenge game that can verify the validity of certain executions of L2 programs (MIPS programs running EVM + some additional content). One major drawback of this approach is that we need to reserve a period of time for users to have the opportunity to detect and successfully challenge a proposed incorrect program result. This will add a considerable amount of time to the asset extraction process (7 days on the current Optimism mainnet).

However, our L2 is simply a program running on a simple machine (such as MIPS). It is entirely possible to construct a ZK circuit for this simple mechanism. Then, we can use this circuit to explicitly prove the correct execution of the L2 program. Without making any modifications to the current Bedrock codebase, you can start publishing validity proofs for Optimism. It's that simple in practice.

Why is this method reliable?

To clarify, although I mentioned "zkMIPS" in this section, I actually use it as a term representing all general and simplified zero-knowledge proof virtual machines (zkVMs).

zkMIPS is easier than zkEVM

Building a zkMIPS (or any other type of zk virtual machine) has a significant advantage over zkEVM: the target machine architecture is simple and static. EVM often changes, gas prices are adjusted, opcodes are modified, and some elements are added or removed. However, MIPS-V has not changed since 1996. By focusing on zkMIPS, you are dealing with a fixed problem space. Whenever EVM is updated, you do not need to change or even re-audit your circuit.

zkMIPS is more flexible than zkEVM

Another key point is that zkMIPS is more flexible than zkEVM. With zkMIPS, you can freely modify client code, perform various optimizations, or improve user experience without the need for corresponding circuit updates. You can even create a core component that turns any blockchain into a ZK Rollup, not just Ethereum.

Your task has shifted to proving time

The expansion of zero-knowledge proof is along two axes: the number of constraints and the size of the circuit. By focusing on circuits of simple machines like MIPS (rather than more complex machines like EVM), we can significantly reduce the size and complexity of the circuit. However, the number of constraints depends on the number of machine instructions executed. Each EVM opcode is decomposed into multiple MIPS opcodes, which means that the number of constraints significantly increases, and your overall proof time also significantly increases.

However, reducing proof time is also a problem deeply rooted in the Web2 field. Considering that the MIPS machine architecture is unlikely to change in the short term, we can highly optimize circuits and provers without considering the future changes of EVM. I am very confident in hiring a senior hardware engineer to optimize a well-defined problem, and the number of such engineers may be ten or even a hundred times the number of engineers needed to build and audit a constantly changing zkEVM target. Companies like Netflix may have a large number of hardware engineers optimizing transcoding chips, and they are likely to be willing to use a bunch of venture capital funds to meet this interesting ZK challenge.

Proof time for circuits like this may exceed the withdrawal period of 7 days for Optimistic Rollup. Over time, this proof time will only decrease. By introducing ASIC and FPGA, we can significantly speed up proof time. With a static target, we can build a more optimized prover.

Ultimately, the proof time of this circuit will be lower than the current 7-day withdrawal period of Optimism, and we can start considering removing the challenge process of Optimism. Running a prover for 7 days may still be too expensive, so we may want to wait a bit longer, but this is reasonable. You can even run two proof systems at the same time, so we can start using ZK proofs as soon as possible and switch back to Optimism proofs if the prover fails for any reason. When ready, Optimism proofs can be removed in a way that is completely transparent to the application, and your Optimistic Rollup becomes a ZK Rollup.

You can go and focus on other important issues

Running a blockchain is a complex issue that involves not only writing a lot of backend code. At Optimism, much of our work is focused on improving the experience for users and developers by providing useful client tools. We also invest a lot of time and effort in "soft" issues: talking to projects, understanding their pain points, and designing incentive mechanisms. The more time you spend on chain software, the less time you have to deal with these other things. While you can always try to hire more people, organizations do not scale linearly, and each new employee adds to the internal communication costs.

Due to the fact that the work of zero-knowledge circuits can be directly applied to existing chains, you can simultaneously build the core platform and develop proof software. Since the client can be modified without changing the circuit, you can decouple your client and proof team. Optimistic Rollup using this approach may be years ahead of zero-knowledge competitors in actual chain activity.

Conclusion

To be very frank, I don't think the zkMIPS proof system has any obvious shortcomings, unless it cannot be significantly optimized over time. The only real impact on applications, in my opinion, is that gas costs for different opcodes may need to be adjusted to reflect the increased proof time for these opcodes. If it really is impossible to optimize this proof system to a reasonable level, then I admit that I have failed. But if this proof system can really be optimized, then the zkMIPS/zkVM approach may completely replace the current zkEVM approach. This may sound like a radical statement, but not long ago, single-step optimistic fault proofing was completely replaced by multi-step proofing.