How to realize the decentralized Prover? Opside innovatively proposes a two-step submission algorithm for ZKP
first level title
Why we need a decentralized prover
Currently, there are already multiple ZK-Rollups running on the Ethereum mainnet. However, the decentralized design of ZK-Rollup is still in its early stages. We are currently focusing on the decentralization of Sequencer, and most people ignore it. In fact, most of the current ZK-Rollup projects do not have a decentralized prover.
first level title
Challenges of decentralized provers
Decentralized prover can solve the above problems well, but it also brings some challenges, which is one of the reasons why several zkEVM solutions that have been launched recently adopt the centralized prover solution. For example, the beta mainnet of Polygon zkEVM relies on trusted aggregator to submit ZKP, and zkSync era is similar.
In terms of technical details, when ZK-Rollup's smart contract verifies ZKP, it needs the original proof data, which may trigger various on-chain attacks. For example, when a prover submits the calculated ZKP to the contract on the chain, it needs to send an L1 transaction. When the transaction sent by the prover is broadcast to the transaction pool, the attacker can see the original proof data, and the attacker can set a higher gas fee to send the transaction, so as to preferentially package it into the block to obtain PoW rewards.
first level title
Two-step commit for ZKP
Opsidesecondary title
Step 1: Commit hash
For a certain sequence, after the prover calculates the ZKP, it first calculates the hash of (proof / address), and submits the hash and address to the smart contract on the chain. Among them, proof is a zero-knowledge proof of a certain sequence, and address is the address of the prover
secondary title
Step 2: Submit ZKP
In blocks T+11 and later, any prover is allowed to submit ZKP. As long as one ZKP passes the verification, all submitted hashes can be verified according to the ZKP. Provers who pass the verification can get PoW rewards, and the reward amount is distributed according to the proportion of miners' pledged amount.
If no ZKP passes the verification before the T+20th block, all provers who have submitted the hash will be slashed. At this point, the sequence is reopened, allowing new hashes to be submitted, and returning to step 1
secondary title
Prover's pledge and punishment
In order to avoid malicious behavior against the prover, the prover needs to be registered in a special system contract and pledge a certain number of tokens. If the current pledge amount is less than the threshold, hash and ZKP are not allowed to be submitted. The rewards obtained by the prover for submitting ZKP will also be distributed according to the proportion of the pledged amount, so as to avoid the malicious behavior of the prover submitting ZKP multiple times.
When the prover has the following behaviors, different degrees of punishment will be imposed
prover submitted wrong hash
For a sequence, if no corresponding ZKP passes the verification, all provers who have submitted the hash will be punished
Forfeited tokens will be burned.
first level title
several considerations
Why are multiple provers allowed to submit hashes? If the first hash submitter can get the reward, then after the first prover submits the hash, other provers will have no incentive to submit proof. If a malicious attacker delays submitting the proof after submitting the hash, it will hinder the speed at which the entire sequence is verified. Therefore, multiple provers should be allowed to submit hashes independently and in parallel to avoid ZKP verification being monopolized by a single attacker.
Why do you need to set a time window? Assuming that anyone can submit the proof immediately after submitting the hash, the proof may still be preempted. Because the attacker will immediately submit a hash associated with his own address, and then submit the proof to obtain rewards. After the time window is set, the prover who has submitted the hash has no motivation to submit the proof within this time window, thus avoiding the possibility of the proof being used by attackers.
first level title
Summary and Planning
The ZKP two-step submission algorithm proposed in this paper, while realizing the decentralization of the prover, can well avoid the front-running attack against the prover, and encourage more miners to provide stable and continuous ZKP computing power. The initial version will go live on Opside's Pre-alpha testnet. In the future, Opside will also carry out more innovations in more ZKP mining fields. For example:
Dynamically adjust the reward distribution ratio of PoS and PoW according to the supply and demand relationship of ZKP computing power of the entire network
Estimate the workload based on ZK-Rollup type, Rollup transaction quantity, gas usage, etc., and establish a personalized pricing mechanism for Rollup batch
Application developers subsidize the ZKP generation of their Rollup to incentivize miners to provide computing power
