Thanks to ZeroKPunk for the review and feedback.

Zero Knowledge Proof (ZKP) has many application scenarios, including rollup, bridge, and oracle. This leads to the development of projects like ZK-rollup, ZK-bridge, and ZK-oracle.

Hybrid and optimistic designs have been recently applied to ZKP technology. For example, Orbiter Finance proposes an optimistic ZK bridge protocol, while Taiko presents a progressive hybrid rollup solution.

Optimistic ZK operates under the presumption that all state transitions are correct, without requiring an immediate validity proof. However, it establishes a predetermined challenge window, during which any participant can dispute a fraudulent activity by submitting either a validity proof or a fraud proof.

This design reduces the overall proving cost for ZKP projects while still ensuring safety by incentivizing decentralized challengers to monitor the systems and challenge fraud behavior.

Orbiter Finance is a prominent cross-rollup project. It proposes the "Orbiter Cross Rollup Protocol: Optimistic For The Obedient Majority And Severe Arbitration For Malicious Minority".

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

There are several important factors to consider for such a design.

Firstly, historic bridge projects have experienced multiple security issues, resulting in significant losses for users. Centralization also poses security concerns. Therefore, decentralization is crucial for bridges.

Secondly, there needs to be a mechanism to ensure accurate transactional processes between the source chain/rollup and the destination chain/rollup.

Furthermore, it is essential to find a cost-effective way to generate such proof. ZKP is a viable option with less gas fee, compared with on-chain Merkle proofs.

In particular, for a cross-rollup bridge, the cost is a primary consideration, and the entire design aims to minimize expenses. This means reducing on-chain transactions and minimizing gas usage for each on-chain transaction are of utmost importance.

In Orbiter's design, apart from the bridge payment scenario, there is another scenario that requires ZKP. In this scenario, a role called "submitter" aggregates the cross-rollup transaction information and sends it to L1 to ensure accurate rewards for decentralized dealer roles.

Orbiter's protocol assumes that the majority of actors are not faulty and handles cross-rollup events optimistically to ensure timely execution. If each cross-rollup transaction requires proof, the execution of the entire bridge transaction will be slow. Therefore, when there is no malicious behavior, there is no need to generate proof, saving the cost of proving. However, if malicious behavior is detected in the maker or submitter, the challenger can generate proof and the challenged submitter should also submit proof.

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

1. Full zk: In this mode, each transition requires a ZKP. This can be achieved through projects like ZK-bridge, such as Polyhedra, or ZK-rollup such as Scroll.

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

When defining an abstract model, it becomes apparent that both ZK-bridge and ZK-rollup can share some similarities. Specifically, this can be seen in the relationship between ZKP requestors and ZKP provers, as illustrated in the picture below. Here the ZKP requestors refer to the module that has requirements to generate a ZKP.

The scenarios are as follows:

1. In the ZK-rollup project:

   • In full zk mode, the sequencer works as the ZKP requestor.

   • In optimistic zk mode, the challenger works as the ZKP requestor.

2. In the ZK-bridge project:

   1. In full zk mode, the maker works as the ZKP requestor.

   2. In optimistic zk mode, the challenger works as the ZKP requestor.

As mentioned before, in optimistic zk, there may not always be a proving task. Therefore, if we combine the ZKP requestors and ZKP provers in the same module, the provers may be idle, and their computation power may not be fully utilized.

However, if we design a requestor-prover separation model and make the prover a shared pool, we can improve the prover's utilization rate. When there are no challenges for the optimistic scenario, the prover can take on proving tasks from other ZKP projects. That means ZKPool plays a significant role in zk-bridge projects, particularly in hybrid and optimistic scenarios.

The ZKP requester-prover separation model applies not only to rollup and bridge but also to oracle and all other ZKP projects.

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

1. ZKP (Zero-Knowledge Proof) technology is essential for ZKP projects, including rollup, bridge, oracle, and other related projects.

2. ZKPool allows us to consider the maker/submitter of ZK-bridge and the sequencers of ZK-rollup as the same role, known as the ZKP requestor.

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

Thanks to ZeroKPunk for the review and feedback.

Zero Knowledge Proof (ZKP) has many application scenarios, including rollup, bridge, and oracle. This leads to the development of projects like ZK-rollup, ZK-bridge, and ZK-oracle.

Hybrid and optimistic designs have been recently applied to ZKP technology. For example, Orbiter Finance proposes an optimistic ZK bridge protocol, while Taiko presents a progressive hybrid rollup solution.

Optimistic ZK operates under the presumption that all state transitions are correct, without requiring an immediate validity proof. However, it establishes a predetermined challenge window, during which any participant can dispute a fraudulent activity by submitting either a validity proof or a fraud proof.

This design reduces the overall proving cost for ZKP projects while still ensuring safety by incentivizing decentralized challengers to monitor the systems and challenge fraud behavior.

Orbiter Finance is a prominent cross-rollup project. It proposes the "Orbiter Cross Rollup Protocol: Optimistic For The Obedient Majority And Severe Arbitration For Malicious Minority".

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

There are several important factors to consider for such a design.

Firstly, historic bridge projects have experienced multiple security issues, resulting in significant losses for users. Centralization also poses security concerns. Therefore, decentralization is crucial for bridges.

Secondly, there needs to be a mechanism to ensure accurate transactional processes between the source chain/rollup and the destination chain/rollup.

Furthermore, it is essential to find a cost-effective way to generate such proof. ZKP is a viable option with less gas fee, compared with on-chain Merkle proofs.

In particular, for a cross-rollup bridge, the cost is a primary consideration, and the entire design aims to minimize expenses. This means reducing on-chain transactions and minimizing gas usage for each on-chain transaction are of utmost importance.

In Orbiter's design, apart from the bridge payment scenario, there is another scenario that requires ZKP. In this scenario, a role called "submitter" aggregates the cross-rollup transaction information and sends it to L1 to ensure accurate rewards for decentralized dealer roles.

Orbiter's protocol assumes that the majority of actors are not faulty and handles cross-rollup events optimistically to ensure timely execution. If each cross-rollup transaction requires proof, the execution of the entire bridge transaction will be slow. Therefore, when there is no malicious behavior, there is no need to generate proof, saving the cost of proving. However, if malicious behavior is detected in the maker or submitter, the challenger can generate proof and the challenged submitter should also submit proof.

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

1. Full zk: In this mode, each transition requires a ZKP. This can be achieved through projects like ZK-bridge, such as Polyhedra, or ZK-rollup such as Scroll.

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

When defining an abstract model, it becomes apparent that both ZK-bridge and ZK-rollup can share some similarities. Specifically, this can be seen in the relationship between ZKP requestors and ZKP provers, as illustrated in the picture below. Here the ZKP requestors refer to the module that has requirements to generate a ZKP.

The scenarios are as follows:

1. In the ZK-rollup project:

   • In full zk mode, the sequencer works as the ZKP requestor.

   • In optimistic zk mode, the challenger works as the ZKP requestor.

2. In the ZK-bridge project:

   1. In full zk mode, the maker works as the ZKP requestor.

   2. In optimistic zk mode, the challenger works as the ZKP requestor.

As mentioned before, in optimistic zk, there may not always be a proving task. Therefore, if we combine the ZKP requestors and ZKP provers in the same module, the provers may be idle, and their computation power may not be fully utilized.

However, if we design a requestor-prover separation model and make the prover a shared pool, we can improve the prover's utilization rate. When there are no challenges for the optimistic scenario, the prover can take on proving tasks from other ZKP projects. That means ZKPool plays a significant role in zk-bridge projects, particularly in hybrid and optimistic scenarios.

The ZKP requester-prover separation model applies not only to rollup and bridge but also to oracle and all other ZKP projects.

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

1. ZKP (Zero-Knowledge Proof) technology is essential for ZKP projects, including rollup, bridge, oracle, and other related projects.

2. ZKPool allows us to consider the maker/submitter of ZK-bridge and the sequencers of ZK-rollup as the same role, known as the ZKP requestor.

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