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

Original Author: 0x3d18, ZKPool

Translation: Qianwen, ChainCatcher

Zero-knowledge proofs have many applications, 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 has proposed an Optimistic ZK bridging protocol, while Taiko has proposed a progressive hybrid Rollup solution.

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

This design reduces the total proof cost of ZKP projects, while ensuring security by incentivizing decentralized challengers to monitor the system and challenge fraudulent behavior.

Optimistic ZK Bridging Protocol

Orbiter Finance is a well-known cross-Rollup project. It has proposed the "Orbiter Cross-Rollup Protocol: Be optimistic about compliant majority and arbitrate harshly against 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.

Decentralized design of Orbiter

Several important factors need to be considered in such a design:

First, past bridging projects have experienced 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 processes between source chain/Rollup and 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 choice with lower gas fees.

In particular, cost is a primary consideration for cross-Rollup bridges, and the goal of the entire design is to minimize costs. This means reducing on-chain transactions and minimizing the gas consumption of 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 the "submitter" aggregates the cross-transaction information and sends it to L1 to ensure that decentralized traders receive accurate rewards.

Decentralized submitter design of Orbiter

Orbiter's protocol assumes that the majority of participants will not make mistakes and optimistically handles cross-Rollup events to ensure timely execution. If every cross-Rollup transaction requires a proof, the execution of the entire bridging transaction will be very slow. Therefore, in the absence of malicious behavior, no proof needs to be generated, saving costs. However, if malicious behavior is detected by the maker or submitter, challengers can generate proofs, and the challenged 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 modes available:

1. Full zk: In this mode, a ZKP is required for each transition. This can be achieved through projects like ZK-bridge (such as Polyhedra) or ZK-Rollup (such as Scroll).

2. Optimistic zk: In this mode, a ZKP is only required when a transition is challenged. Taiko and Orbiter are examples of this mode.

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 following figure. Here, the ZKP requester refers to the module that has the demand to generate ZKP.

Scenarios are as follows:

1. In ZK-Rollup projects:

• In the full zk mode, the sequencer works as the ZKP requester.
• In the Optimistic zk mode, challengers act as ZKP requesters.

2. In ZK-bridge projects:

• In the full zk mode, the maker acts as the ZKP requester.
• In the Optimistic zk mode, challengers act as ZKP requesters.

ZKP requesters and ZKP provers

As mentioned earlier, in Optimistic zk, there may not always be proof tasks. Therefore, if we merge ZKP requesters and ZKP provers into the same module, the prover may be idle, and its computing power may not be fully utilized.

If we design a requester-prover separation model and make the prover a shared pool, we can increase 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 when combined with Optimistic and other modes.

ZKPool shares the role of ZKP prover among ZKP requesters

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

Summary

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 consider 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 increased. This model also promotes decentralization in all ZKP projects.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。