OAK-M14 — Multi-Prover Redundancy

Description

OAK-M14 is the canonical architectural defence against light-client and zk-bridge verification bypass (OAK-T10.005). It pairs the cryptographic verification primitive with two structural redundancies: (1) multiple independent zk-prover implementations (different proof systems, different teams, different codebases) producing proofs of the same statement, with the on-chain verifier requiring agreement before finalisation; and (2) trusted-setup MPC ceremonies with a public participant list, published transcripts, attestation hash chains, and reproducible verification scripts — eliminating the structured-reference-string compromise surface where the proof system requires one. Where the proof system supports universal or transparent setup (PLONK with shared powers-of-tau, STARKs without trusted setup), M14 prescribes preferring those constructions and pinning ceremony provenance.

The mitigation directly targets the dominant T10.005 failure class: industry analyses attribute roughly 96% of disclosed SNARK bugs to under-constrained circuits [soksnarkvulns2024]. A single-implementation deployment — same team writing the spec, the circuit, the prover, and the verifier — concentrates the under-constrained-circuit risk on one codebase and one team's review capacity. Multi-prover redundancy across genuinely independent stacks reduces this exposure to the much smaller probability that all stacks share the same soundness gap. The 0xPARC zk-bug-tracker [zkbugtracker] documents the bug-class diversity that makes implementation-diverse stacks structurally safer than implementation-monoculture stacks.

M14 also prescribes pre-deployment circuit audit by circuit-specialist firms and formal verification of the consensus-rule encoding — independent specification of the source-chain consensus rule, mechanised proof that the circuit's constraint system implements the specification, and published artefacts (proof scripts, SMT outputs, machine-checked theorems) sufficient for a reviewer to reproduce the verification. The audit and formal-verification components are themselves subject to OAK-M16 (Pre-Deployment Audit and Formal Verification) and the mitigations are designed to compose: M14 names who and with what cryptographic structure, M16 names to what assurance standard.

How it applies

• OAK-T10.005 (Light-Client Verification Bypass): require multi-prover redundancy across independent proof systems or independent implementations of the same proof system before finalisation; require trusted-setup MPC ceremonies with public participants, transcripts, and attestation hash chains where the proof system requires a setup; prefer universal/transparent-setup constructions where feasible; require circuit-specialist audit and formal verification of the consensus-rule encoding; pin all cryptographic-primitive artefacts (circuit, SRS, verifier-contract bytecode hash) and treat any circuit upgrade as a new bridge for due-diligence purposes.

Limitations

• Multi-prover redundancy multiplies proving cost; deployments with tight latency or fee budgets commonly defer it as an aspirational future state, leaving single-prover exposure in production.
• "Independent" provers are only as independent as their dependencies — shared cryptographic libraries, shared circuit DSLs (Circom, Halo2), or shared compilers can re-introduce correlated failure modes that defeat the redundancy argument.
• Trusted-setup ceremony transparency does not bound circuit-correctness risk; an SRS generated by a transparent ceremony still verifies a circuit that may be under-constrained.
• Formal verification of the consensus-rule encoding is bounded by the specification: a circuit that correctly implements a mis-specified consensus rule is formally verified and unsound.
• Circuit-specialist audit capacity is the binding constraint; v0.1 has limited firms (Veridise, Trail of Bits, ZK Security, Zellic, OpenZeppelin's ZK practice) with deep coverage and queues are long.

Reference implementations

• Polyhedra zkBridge, Succinct, Electron, Avail, Polymer — production zk-bridge architectures that defenders should evaluate against M14's multi-prover and ceremony-transparency criteria; per-bridge maturity varies and most v0.1 deployments are single-prover.
• 0xPARC zk-bug-tracker [zkbugtracker] — community-maintained catalogue of disclosed circuit bugs; primary public reference for circuit-bug case studies and a forcing function for multi-prover-redundancy adoption.
• Veridise, Trail of Bits, ZK Security — circuit-audit specialist firms providing the audit component of M14; Zellic and OpenZeppelin's ZK practice as adjacent coverage.

Citations

• [verichainsdragonberry2022] — Verichains disclosure of the ICS-23 Merkle-proof soundness bug ("Dragonberry") affecting IBC light-client verification across Cosmos-SDK chains; canonical worked example of the failure class M14 addresses.
• [soksnarkvulns2024] — academic SoK characterising ~96% of disclosed SNARK bugs as under-constrained circuits; quantitative justification for implementation-diverse multi-prover deployments.
• [xie2022zkbridge] — original zkBridge construction paper introducing zk-SNARK-based cross-chain bridge architecture and its security model.
• [zkbugtracker] — 0xPARC community-maintained catalogue of disclosed bugs in apps using ZK cryptography.
• [zhou2023sok] — academic taxonomy classifying bridge-design assumption failures including cryptographic-primitive-layer gaps.