-
Notifications
You must be signed in to change notification settings - Fork 33
Description
By adding a new flow for verifying proofs within the fraud proof mechanism, we can achieve very cheap proof verification for non-financial applications.
Here’s how it works:
- The application/user sends a proof request to the prover network.
- The prover network generates a proof.
- The proof is published on the smart contract, but the proof verification function isn’t called immediately. Instead, a new element—a fraud proof deadline—is added.
- If someone calls the challenge method before the deadline, the proof verification logic (e.g., a Groth16 verifier) is executed. If the proof is invalid, the prover gets slashed from their collateral. If the proof is valid, the challenger pays for the transaction fee, receives nothing, and the proof is finalized.
- If no one challenges the proof by the deadline, the contract considers the proof valid.
This idea may introduce some MEV-related concerns, but with a reasonable deadline for proof finalization, these risks are acceptable. Moreover, application developers could set their own acceptable deadlines.
This approach will significantly reduce on-chain costs and lower fees for end users. In the future, it could also enable succinct verification of zk proofs that require curves currently unavailable on Ethereum.
(In general, the succinct labs prover network could create a built-in, alignedlayer(https://alignedlayer.com/). or even integrate prover network with their protocol )