Why do we need decentralized proofers?
There are currently multiple ZK-Rollups running on the Ethereum mainnet. However, the design of decentralized ZK-Rollups is still in its early stages. We are currently focusing on the decentralized sequencer issue, but most people overlook the fact that the ZK-Rollup project does not implement decentralized proofers.
For ZK-Rollups, a central proofer is still safer and does not introduce the same cersorship issues as a central sequencer. However, a central proofreader can also cause many problems.
First, if there is only one validator, a single node failure may cause the entire ZK-Rollup to be unable to provide proof of validity, thus affecting the accuracy of transactions.
Second, a central validator is costly and cannot meet the computational demand for massive ZK-Rollups in the future. Finally, from an economic point of view, a central validator alone has a fraction of the profit, which is actually unfair from a token economy perspective.
Challenges of Decentralized Attorneys
Decentralized proofers can effectively solve the above problems, but they also come with some challenges. This is one of the reasons why several recently launched zkEVM schemes have adopted a centralized prover scheme. For example, Polygon zkEVM’s beta mainnet relies on a reliable aggregator to send ZKPs, and the zkSync era is similar in this respect.
From a technical standpoint, when a ZK-Rollup smart contract validates ZKP, it needs genuine proof data. This can potentially trigger various on-chain attack behaviors. For example, when a given proofer presents the calculated ZKP to the chain-level contract, it must submit a Tier-1 transaction. When this transaction is broadcast to the transaction pool, attackers can see the original proof data and set a higher transaction fee for sending a transaction, so they can be packed first in a block and earn PoW rewards.
In addition, since proofers compete with each other based on computational power, there is no reliable identification mechanism and it is difficult to establish a communication mechanism. Different miners can do duplication, which wastes computational power.
Two Stage Shipping of ZKP
Step 1: Send hash
After a proofreader calculates a ZKP for a given string, it first calculates its (proof/address) hash and sends the hash and address to the chain-level smart contract. Here the proof is the zero knowledge proof for a given sequence and the address is the address of the prover.
Assuming that the first proofreader sends the digest of ZKP in T. block, without any limitation T+10. up to the block. T+11. As of block, new proofers can no longer send hashes.
Step 2: Submit the ZKP
T+11. After the block, any prover can send a ZKP. As long as a ZKP passes verification, it can be used to verify all submitted hashes. Verified proofers receive PoW rewards based on the ratio of miners’ deposits.
T+20. If no ZKP passes the verification before the block, all the hash-sending proofers are cut. Then the queue is reopened and new hashes are sent to return to Step 1.
Here’s an example: Let’s say in the Opside network, each block has a PoW reward of 128 IDEs and there are currently 64 rollup slots available. Therefore, a PoW bounty of 2 IDEs is assigned to each rollup thread. If three miners A, B, and C successfully send the correct ZKP for a string, and the miner shares (IDE) of the three miners are 200K, 500K, and 300K, respectively. In this case, A, B and C can each win a PoW prize of 0.4 IDE, 1 IDE and 0.6 IDE respectively.
Prover’s Token Share and Penalty
To prevent malicious behavior of the proofer, the proofer must sign up for a special system contract and stake a certain amount of tokens. If the current stake is below the threshold, the prover cannot send the hash and ZKP. The reward for the proofer’s submission of the ZKP will be distributed according to the proportion of the stake, preventing the proof from sending more than one ZKP.
Different levels of penalties will apply if the prover performs the following actions:
- The authenticator sends an incorrect hash.
- For a given string, if no corresponding ZKP passes verification, all proofers who submit hashes will be penalized.
The lost token will be burned.
Readers are encouraged to refer to the Opside official documentation for more details and consideration of ZKP’s two-step submission mechanism. Certain numbers of the prover’s share and penalty may be changed in the future.
A few points:
Why allow multiple validators to send hashes?
If only the first proofer to submit a hash is rewarded, other proofers may not have the incentive to submit a proof after the first proof has submitted a summary. If a malicious attacker delays sending proof for a long time after hashing, it can slow down validation of the entire string. Therefore, it is necessary to allow multiple authenticators to hash independently and simultaneously to avoid monopolizing the ZKP verification by a single attacker.
Why is there a time window?
If anyone can provide a proof immediately after posting a hash, the proof can still be stolen. Attackers can immediately send a hash associated with their address and then submit a proof to earn a reward. By setting a time window, hashing proofers have no incentive to present evidence within the window, thus eliminating the possibility of competition.
Why is the prize distributed by stock?
Multiple authenticators can send hashes for the same queue within a time interval. In fact, miners can send multiple hashes using the proofs they create (it only needs multiple addresses). This could lead to most or even all of the PoW rewards being received by miners. To avoid this attack, the reward of a string will be allocated according to the ratio of the miner’s stake.
Summary and Planning
The two-step forwarding algorithm for ZKPs proposed in this post realizes the decentralization of the proofer while effectively avoiding race attacks and encouraging more miners to provide stable and continuous ZKP computing power. The first version of the algorithm will be launched on the Opside pre-alpha testnet. In the future, Opside will also present more innovative ideas in the field of ZKP mining, such as:
Dynamically adjusting the reward allocation ratio between PoS and PoW based on the supply and demand of ZKP computing power across the entire network.
Personalized pricing mechanism for Collection groups based on the ZK-Collection type, the number of Collection transactions and the gas usage of the Collection.
Subsidies to app developers to produce ZKPs for their associated Aggregations to encourage miners to provide computational power.
42920
