Detailed Explanation of the New ZKP Bridging Scheme: Introducing the "Requester-Prover" Separation Model of Optimistic into zk

Original Title: ZKP Requester-Prover Separation model to support Full ZK and Optimistic ZK

Original Author: 0x3d18, ZKPool

Compiler: Qianwen, ChainCatcher

Zero-knowledge proofs have many application scenarios, including Rollup, bridging, and oracles. This has led to the development of projects such as ZK-Rollup, ZK-bridge, and ZK-oracle.

Hybrid and Optimistic designs have recently been applied to ZKP technology. For example, Orbiter Finance proposed an Optimistic ZK bridging protocol, while Taiko proposed a progressive hybrid Rollup solution.

Optimistic ZK assumes that all state transitions are correct and does not require immediate validity proofs. However, it establishes a predetermined challenge window during which any participant can dispute fraudulent activities by submitting validity proofs or fraud proofs.

This design reduces the overall proof costs of ZKP projects while ensuring security through incentives for decentralized challengers to monitor the system and challenge fraudulent behavior.

Optimistic ZK Bridging Protocol

Orbiter Finance is a well-known cross-Rollup project. It proposed the "Orbiter Cross-Rollup Protocol: Optimistically treat the compliant majority and severely arbitrate the malicious minority."

Optimistic Rollup cross-transaction process (from Orbiter Finance)

It defines a decentralized, secure, and cost-effective cross-Rollup design supported by ZKP technology.

Orbiter's decentralized design

Such a design has several important factors to consider:

First, past bridging projects have encountered multiple security issues, causing significant losses to users. Centralization also brings security risks. Therefore, decentralization is crucial for bridging.

Second, there needs to be a mechanism to ensure the accuracy of transaction flows between the source chain/Rollup and the destination chain/Rollup.

Additionally, a cost-effective way to generate such proofs must be found. Compared to on-chain Merkle trees, ZKP is a viable option with lower gas fees.

In particular, for cross-Rollup bridges, cost is the primary consideration, and the goal of the entire design is to minimize expenses. This means it is crucial to reduce on-chain transactions and minimize the gas amount for each on-chain transaction as much as possible.

In Orbiter's design, in addition to the bridging payment scheme, there is another scheme that requires ZKP. In this scenario, a role called "submitter" aggregates and sends cross-aggregated transaction information to L1 to ensure that decentralized dealers receive accurate rewards.

Orbiter's decentralized submitter design

Orbiter's protocol assumes that most participants do not make mistakes and optimistically handles cross-Rollup events to ensure timely execution. If each cross-Rollup transaction requires proof, the execution of the entire bridging transaction will be slow. Therefore, in the absence of malicious behavior, there is no need to generate proofs, saving costs. However, if malicious behavior is detected by the maker or submitter, the challenger can generate proofs, and the disputed submitter should also submit proofs.

Orbiter Optimistic zk bridging design

ZKPool Requester-Prover Separation Model

When it comes to using ZKP technology, there are different models available:

1. Full zk: In this model, a ZKP is required for each conversion. This can be achieved through projects like ZK-bridge (e.g., Polyhedra) or ZK-Rollup (e.g., Scroll).

2. Optimistic zk: In this model, ZKP is only required when the conversion is challenged. Taiko and Orbiter are examples of this model.

Full zk and Optimistic zk

When defining the abstract model, it is clear that ZK-bridge and ZK-Rollup have some similarities. Specifically, this difference is reflected in the relationship between ZKP requesters and ZKP provers, as shown in the diagram below. Here, the ZKP requester references a module that generates ZKP requirements.

The scenarios are as follows:

1. In ZK-Rollup projects:

• In the full zk model, the sequencer acts as the ZKP requester.
• In the Optimistic zk model, the challenger acts as the ZKP requester.

1. In ZK-bridge projects:

• In the full zk model, the maker acts as the ZKP requester.
• In the Optimistic zk model, the challenger acts as the ZKP requester.

ZKP requesters and ZKP provers

As mentioned earlier, in the Optimistic zk model, there may not always be proof tasks. Therefore, if the ZKP requester and ZKP prover are merged into the same module, the prover may be idle, and its computational power may not be fully utilized.

If we design a requester-prover separation model and make the prover a shared pool, we can improve the utilization of provers. When the Optimistic scenario is not challenged, provers can take on proof tasks from other ZKP projects. This means that ZKPool plays an important role in zk-bridge projects, especially in cases where Optimistic is combined with others.

ZKPool shares the role of ZKP provers among ZKP requesters

The ZKP requester-prover separation model is applicable not only to Rollup and bridging but also to oracles and all other ZKP projects.

Conclusion

Based on the information provided, we can draw the following conclusions:

1. ZKP technology is crucial for ZKP projects, including Rollup, bridging, oracles, and other related projects.

2. ZKPool allows us to view the creators/submitters of ZK-bridge and the sequencers of ZK-Rollup as the same role, collectively referred to as ZKP requesters.

3. By using ZKPool's ZKP requester-prover separation model, the utilization of provers can be improved. This model also promotes the decentralization of all ZKP projects.