IIP-57: Trustless Bridge: Replacing Keys with Proofs

[raullenchai]

Summary

• Replace compromised ioTube bridge with a ZK Light Client Bridge using Succinct SP1 zero-knowledge proofs
• Trustlessly verify IoTeX's 24-delegate BFT consensus on Ethereum — no private keys in the trust path
• Preserve IoTeX's full L1 sovereignty (not becoming a rollup)
• Enable secure bidirectional bridging of USDT, USDC, WETH, and WBTC

Key Design Decisions

• ETH→IoTeX deposits: Delegate BFT attestation (17/24 consensus threshold), zero gas cost
• IoTeX→ETH withdrawals: SP1 ZK proof of block validity + receipt Merkle inclusion
• Competitive proving: Any delegate can submit proofs; first valid submission wins 50% of fees
• CPU proving sufficient: ~8-9 min on standard delegate hardware (16 cores), GPU optional (~1 min)
• Hybrid fee model: max($5 fixed, 0.1% × amount) with per-token fee configuration
• Fee distribution: 50% relayer, 30% treasury, 20% security reserve
• Safety: $100K per-epoch withdrawal cap, timelock + multisig governance, no admin bypass
• Future-proof: Migration path to Ethereum Native Rollup (EIP-8079) with 1-line contract change

Security Highlights

• Eliminates the exact attack vector that caused the ioTube hack ($4.4M loss)
• Three explicit trust assumptions: ZK proof soundness, IoTeX BFT consensus, smart contract correctness
• Defense in depth: withdrawal caps limit worst-case loss even if all assumptions fail
• SP1 verifier audited by 4 independent firms (Veridise, Cantina, Zellic, KALOS)
• Production precedent: Succinct's ZK light client bridge secures $40M+ TVL on Gnosis Chain

Specification Scope

1. iotex-core changes: Yosemite hard fork, BridgeAttestation system action, bridge protocol, receipt proof API
2. SP1 Rust program: Proves 17 ECDSA signatures + Merkle inclusion (~6.5M RISC-V cycles)
3. Ethereum contracts: IoTeXLightClient.sol, BridgeVault.sol (with per-token fees, withdrawal caps)
4. IoTeX contracts: BridgeManager.sol, WrappedToken.sol (×4 tokens)
5. Relayer service: Go service for batching, proving, and submitting to Ethereum

Test plan

• Review specification for completeness and correctness
• Validate security assumptions and threat model
• Review fee economics and delegate incentive alignment
• Verify consistency across all sections (competitive proving model, fee calculations)
• Community feedback from delegates on operational requirements

🤖 Generated with Claude Code