
Introducing FidCore: Trusted Infrastructure for Verifiable Computing
zkVM and its Continuation Technology
Firstly, welcome to the zkML demo, which operates on ZKPool and is built on RISC Zero's zkVM solution.BackgroundIncreasingly, projects such as RISC Zero are building zkVM, while others like Taiko and Optimism are utilizing zkVM to develop applications for Ethereum Layer 2. The zkVM solution is gaining more recognition. Previously, there were concerns about its performance. However, teams have continually optimized it from both the ZKP protocol and hardware perspectives. It's getting...

The Infra Ecosystem of ZK-rollup: Sequencers, ZKPool, Provers, MEV, etc.
In the ZK-rollup ecosystem, the infrastructure includes nodes, sequencers, provers, and more. In Ethereum Layer 1, there are validators but no provers. Flashbots can connect MEV searchers with validators.Flashbot architecture (Reference 1)ZK-rollup or Layer 2 (L2) has some differences. It has provers, and each block must be proved and have a proof. Here is a landscape of the ecosystem based on our understanding, using the Taiko project as an example. The Taiko project defines itself as a base...
Trusted Infrastructure for Verifiable Computing.

Introducing FidCore: Trusted Infrastructure for Verifiable Computing
zkVM and its Continuation Technology
Firstly, welcome to the zkML demo, which operates on ZKPool and is built on RISC Zero's zkVM solution.BackgroundIncreasingly, projects such as RISC Zero are building zkVM, while others like Taiko and Optimism are utilizing zkVM to develop applications for Ethereum Layer 2. The zkVM solution is gaining more recognition. Previously, there were concerns about its performance. However, teams have continually optimized it from both the ZKP protocol and hardware perspectives. It's getting...

The Infra Ecosystem of ZK-rollup: Sequencers, ZKPool, Provers, MEV, etc.
In the ZK-rollup ecosystem, the infrastructure includes nodes, sequencers, provers, and more. In Ethereum Layer 1, there are validators but no provers. Flashbots can connect MEV searchers with validators.Flashbot architecture (Reference 1)ZK-rollup or Layer 2 (L2) has some differences. It has provers, and each block must be proved and have a proof. Here is a landscape of the ecosystem based on our understanding, using the Taiko project as an example. The Taiko project defines itself as a base...
Trusted Infrastructure for Verifiable Computing.

Subscribe to FidCore

Subscribe to FidCore
<100 subscribers
<100 subscribers
In a ZKP (Zero Knowledge Proof) system, multiple types of proofs can be generated for the same proving task. The verifier can only verify a state transition when all the generated proofs are verified. The types of proofs include ZK-SNARK, ZK-STARK, SGX, and so on.

Vitalik proposed the multi-prover design in a speech.

Especially, SGX proof is a type of proof guaranteed by hardware. It eliminates the need for complex proving computations using special hardware to execute code and ensure honest computation securely.
To run SGX, the prover must have a dedicated machine with SGX support.
It's because ZK-EVM or ZK-VM won't be bug-free for a long time. The multi-prover system can avoid the error state being mistakenly verified by error-proof. Requiring and verifying all different proofs guarantees a much safer condition.

Here is a picture to illustrate the meaning of multi-prover.

Prover operators then face a significant challenge. The ZKP project needs provers to generate multiple proofs simultaneously (to save gas fees) or at different times (like Taiko’s progressive hybrid rollup design) for the same block. It becomes difficult for individual or institutional operators to have ZK and SGX prover capability.
ZKPool can act as a super-prover by aggregating proofs from independent SGX and ZK provers and then sending the aggregated proofs to the verifier.
Therefore, each individual can use either ZK provers or SGX provers exclusively.
Furthermore, in a multi-prover system, by comparing different proofs off-chain before submitting, we can save on-chain costs. The decentralization of off-chain multi-prover benefits such honest comparison.
ZKPool aims to support different Zero-Knowledge Proof (ZKP) projects. It enables using different kinds of provers to generate proofs for various projects, thereby maximizing hardware utilization.
This is how ZKPool benefits the multi-prover based ZK-rollup.

We are firmly convinced that a multi-prover approach is crucial for the development and success of the ZK-rollup ecosystem and other ZK-related applications, such as ZK-bridge and ZK-oracles.
Taiko's progressive hybrid rollup design: https://github.com/taikoxyz/taiko-mono/pull/14705
Multi-prover introduction from Taiko: https://taiko.mirror.xyz/Kx1Mp4WJjd83K1KDEwp1pM7xi9QmpSahxJg3S_N7NE4
Vitalik's proposal on "Multi-Prover for Rollup Security,": https://www.youtube.com/watch?v=6hfVzCWT6YI
In a ZKP (Zero Knowledge Proof) system, multiple types of proofs can be generated for the same proving task. The verifier can only verify a state transition when all the generated proofs are verified. The types of proofs include ZK-SNARK, ZK-STARK, SGX, and so on.

Vitalik proposed the multi-prover design in a speech.

Especially, SGX proof is a type of proof guaranteed by hardware. It eliminates the need for complex proving computations using special hardware to execute code and ensure honest computation securely.
To run SGX, the prover must have a dedicated machine with SGX support.
It's because ZK-EVM or ZK-VM won't be bug-free for a long time. The multi-prover system can avoid the error state being mistakenly verified by error-proof. Requiring and verifying all different proofs guarantees a much safer condition.

Here is a picture to illustrate the meaning of multi-prover.

Prover operators then face a significant challenge. The ZKP project needs provers to generate multiple proofs simultaneously (to save gas fees) or at different times (like Taiko’s progressive hybrid rollup design) for the same block. It becomes difficult for individual or institutional operators to have ZK and SGX prover capability.
ZKPool can act as a super-prover by aggregating proofs from independent SGX and ZK provers and then sending the aggregated proofs to the verifier.
Therefore, each individual can use either ZK provers or SGX provers exclusively.
Furthermore, in a multi-prover system, by comparing different proofs off-chain before submitting, we can save on-chain costs. The decentralization of off-chain multi-prover benefits such honest comparison.
ZKPool aims to support different Zero-Knowledge Proof (ZKP) projects. It enables using different kinds of provers to generate proofs for various projects, thereby maximizing hardware utilization.
This is how ZKPool benefits the multi-prover based ZK-rollup.

We are firmly convinced that a multi-prover approach is crucial for the development and success of the ZK-rollup ecosystem and other ZK-related applications, such as ZK-bridge and ZK-oracles.
Taiko's progressive hybrid rollup design: https://github.com/taikoxyz/taiko-mono/pull/14705
Multi-prover introduction from Taiko: https://taiko.mirror.xyz/Kx1Mp4WJjd83K1KDEwp1pM7xi9QmpSahxJg3S_N7NE4
Vitalik's proposal on "Multi-Prover for Rollup Security,": https://www.youtube.com/watch?v=6hfVzCWT6YI
Share Dialog
Share Dialog
No activity yet