Multi-proofs
Last updated
Last updated
In the Wischain ecosystem, a block can exist in one of three distinct states:
Proposed
Proved
Verified
A proposed block is one that has been submitted but must pass certain intrinsic validity tests at the block level to be accepted by the Wischain Layer 1 (WischainL1) contract. After this initial step, the proposed block can be classified as either valid or invalid, contingent upon whether it successfully undergoes the transaction list intrinsic validity test. If a block fails this test, it is deemed invalid and will not be recorded on Wischain.
Once a block is proposed, it can be "proved," meaning that it possesses a valid proof that demonstrates a successful state transition from a parent block to the current block. However, it's important to note that proving occurs in parallel across a network of decentralized provers. As a result, while a block can successfully demonstrate the transition from its parent block, we may not yet know if the parent block itself has been verified.
To achieve full verification, both the current block and its parent block must have their state transitions validated. It is generally accepted that the genesis block, which does not have a parent, is always verified. Therefore, for any child block—from the genesis block to the current block—to be considered verified, all intermediate blocks must also provide valid proofs of their state transitions.
A recent update to our protocol has introduced batch verification of blocks. In the past, a block was considered verified as long as its verifiedTransitionId in the block data was non-zero. Under the new batch verification method, only the last block in each batch will carry a non-zero verifiedTransitionId.
This means it is now possible for a block to be verified while having a verifiedTransitionId of zero.
For those who prefer visual aids, a diagram illustrating the three stages (proposed → proved → verified) can help clarify these concepts further.
The primary objective of proving blocks in Wischain is to establish certainty for bridges regarding the execution that has taken place within the rollup. For a bridge to trust the state resulting from operations performed in the rollup, it requires a proof that verifies the correctness of those operations.
In Wischain, users have the opportunity to operate a node as a prover and generate proofs for blocks without needing permission. This enables them to inspect the proposed blocks on the Wischain Layer 1 (L1) contract and produce the necessary proofs to validate them. Currently, any individual acting as a prover can create proofs for these proposed blocks, leading to a scenario where the number of possible "state transitions" is effectively limitless. This is because the correct state transition is not predetermined, allowing for various possibilities.
The first prover to successfully generate a valid proof for the correct state transition is rewarded with ETH, and potentially other forms of compensation such as ERC20 tokens or even NFTs, depending on the specific implementation of the Prover pool. This system fosters competition among provers and encourages the efficient validation of state transitions within the Wischain ecosystem.
The process of proving blocks in Wischain demands substantial computational resources to generate the necessary proofs for submission and verification on the Ethereum blockchain. To attract provers—who are essential for this work—adequate compensation is vital. However, determining the appropriate payment for a proof can be complex due to several factors:
Unpredictable Ethereum Gas Costs: The gas fees associated with publishing and verifying a proof on Ethereum can fluctuate significantly, making it challenging to establish a consistent pricing model.
Mismatch Between Proof Generation and Gas Costs: The expenses incurred in generating proofs do not always align with the gas costs required for their verification, complicating the economic model for provers.
Variable Proof Generation Costs: The cost of generating proofs evolves as the software used for proving is optimized and hardware capabilities improve. This variability means that costs are not static and can change frequently.
Time Sensitivity: The urgency with which a proof needs to be generated also impacts its cost. Faster generation typically incurs higher fees due to the need for more resources.
To address these challenges and enhance network efficiency, Wischain introduces a comprehensive off-chain proof market. In this dynamic marketplace, proposers actively seek out proof service providers for each block they wish to propose. A key element of this system is a publicly available API that allows proposers to interact with potential proof providers off-chain.
Once a proposer and proof service provider reach an agreement on the proving fee for a specific block, the selected provider is responsible for issuing a cryptographic signature to the proposer. This signature acts as a binding commitment, indicating the provider's obligation to deliver the proof within the agreed timeframe.
Provers in this off-chain market can be categorized into two main types: Externally Owned Accounts (EOAs) and Prover pools. For a contract to qualify as a Prover pool, it must meet certain criteria, implementing either the IProver interface or the IERC1271 (isValidSignature) interface.
Upon the submission of a block by a proposer, the signature from the chosen provider undergoes verification. If any discrepancies are found, the transaction will be reverted.
To incentivize proposers further, the system incorporates the issuance of WIS tokens. This additional reward mechanism acknowledges that proposing blocks may not always yield profit, especially when factoring in Ethereum's on-chain fees alongside the proving fee. The emission rate of WIS tokens is dynamically adjusted based on a comparison of each block proposal to the previous one.
The rewards are contingent on the agreement made with the proof service provider. For EOAs and Prover pools implementing the IERC1271 interface, rewards are distributed in ETH. In contrast, for providers utilizing the IProver interface, fees can be paid in ETH, other ERC20 tokens, or even NFTs, depending on the negotiated terms.
To enhance the security and reliability of the process, provers are required to stake a substantial amount of WIS tokens per block as a form of insurance. Should a prover fail to deliver the proof within the specified timeframe, a portion—specifically 25%—will be allocated to the prover, while the remaining 75% will be permanently burned. Conversely, if the proof is successfully delivered on time, the staked tokens will be returned to the prover.
This structured approach not only encourages timely delivery of proofs but also strengthens the overall security and efficiency of the Wischain network.
Multi-proof is a technique used within the realm of zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge) to enhance efficiency and scalability, particularly in proving the validity of multiple statements or transactions simultaneously.
Efficiency: Instead of generating separate proofs for each statement or transaction, multi-proof allows the aggregation of multiple proofs into a single succinct proof. This significantly reduces the computational overhead and the size of the proof, making it faster and less resource-intensive to verify.
Scalability: Multi-proof enables the scaling of blockchain applications by allowing a large number of transactions or statements to be verified with minimal impact on performance. This is particularly important for systems that require high throughput, as it reduces the burden on the underlying blockchain.
Security: By using zk-SNARKs, multi-proof maintains the security and privacy guarantees of the original zk-SNARK framework. It ensures that the validity of the aggregated statements can be verified without revealing any underlying data, preserving the confidentiality of the information involved.
Use Cases: Multi-proof can be particularly useful in scenarios like batch processing transactions, validating multiple claims in decentralized finance (DeFi) applications, or proving the correctness of complex computations involving multiple inputs. This versatility makes it a valuable tool for enhancing the functionality of zk-SNARKs in various applications.
Implementation Considerations: While multi-proof offers significant advantages, it also requires careful implementation to ensure that the aggregation of proofs does not compromise security. Developers must consider the potential trade-offs and carefully design the proof generation and verification processes.
Multi-proof in zk-SNARKs represents a powerful advancement in the quest for efficient and scalable zero-knowledge proofs. By enabling the simultaneous validation of multiple statements while preserving privacy and security, it plays a crucial role in enhancing the capabilities of blockchain applications and expanding the potential use cases for zk-SNARK technology.
