ZKP Two-Step Submission

Two-Step Submissioin Process

Lumoz has proposed a two-step submission algorithm for ZKPs to achieve decentralized proof-of-work. This algorithm can prevent ZKP race attacks while allowing more miners to earn rewards, thereby encouraging more miners to stay online and providing stable and continuous ZKP computational power.

The submission epoch (the number +10 here) is adjustable according to the network's computing power

Step 1: Submit hash

  • After a prover calculates a ZKP for a certain sequence, it first calculates the hash of (proof / address) and submits the hash and address to the chain-level smart contract. Here, proof is a zero-knowledge proof for a certain sequence, and address is the address of the prover.

  • Assuming that the first prover submits the hash of the ZKP at the Tth block, it is accepted until the T+10th block without any limit. From the T+11th block, new provers cannot submit the hash anymore.

Step 2: Submit ZKP

  • After the T+11th block, any prover can submit a ZKP. As long as one ZKP passes verification, it can be used to verify all the submitted hashes. Validated provers receive PoW rewards based on the ratio of miners' staked amounts.

  • If no ZKP passes verification before the T+20th block, all provers who have submitted hashes will be slashed. The sequence is then reopened, and new hashes can be submitted, returning to Step 1.

A simple case:

let's assume that each block has a PoW reward of 128 MOZ on the Lumoz network, and there are currently 64 rollup slots available. Each rollup sequence is assigned a PoW reward of 2 MOZ.

If three miners, A, B, and C, successfully submit the correct ZKP for a sequence in succession, and the three miners' miner stakes (MOZ) are 200K, 500K, and 300K, then, A, B, and C can each earn a PoW reward of 0.4 MOZ, 1 MOZ, and 0.6 MOZ, respectively.

Prover's token stake and punishment

To prevent malicious behavior related to provers, the Prover needs to register in a special system contract and stake tokens.

If the prover commits the following actions, different levels of punishment will be applied:

  • The prover submits an incorrect hash.

  • For a certain sequence, if no corresponding ZKP passes verification, all provers who have submitted hashes will be punished.

The slashed token will be burned.

Considerations

Why allow multiple provers to submit hashes?

  • If only the first prover to submit a hash is rewarded, other provers may not have an incentive to submit a proof after the first prover submits a hash.

  • If a malicious attacker delays submitting the proof for a long time after submitting a hash, it may slow down the verification of the entire sequence.

Therefore, it is necessary to allow multiple provers to independently and simultaneously submit hashes to avoid monopoly of ZKP verification by a single attacker.

Why is there a time window (submission epoch)?

  • If anyone can submit a proof immediately after submitting a hash, the proof may still be stoled. Attackers can immediately submit a hash associated with their address and then submit a proof to earn rewards.

By setting a time window, provers who have submitted hashes have no incentive to submit proofs within the window, thereby avoiding the possibility of being raced.

Why is the reward allocated based on stake?

  • Multiple provers can submit hashes for the same sequence within a time window. In fact, miners can submit multiple hashes using their generated proof (only needs multiple addresses). This can lead to the majority or even all of the PoW rewards being taken by several miners.

To avoid this attack, the reward for a sequence will be allocated based on the ratio of miner's stake amount.

Last updated