How TeQoin detects and prevents invalid state transitions
Understanding TeQoin’s fraud proof mechanism that ensures state validity and protects user funds without requiring trust.
TL;DR:Fraud proofs allow anyone to prove that a sequencer posted an invalid state transition. If fraud is detected, a cryptographic proof is submitted to L1, the invalid state is reverted, and the sequencer is penalized. This ensures security without trusting the sequencer.
Without fraud proofs:- Must trust sequencer completely- No way to verify state is correct- Sequencer could steal funds- Centralized security modelWith fraud proofs:- Don't need to trust sequencer- Anyone can verify state- Invalid states are proven and reverted- Decentralized security model
// Start from previous state root let currentState = loadState(batch.prevRoot); // Execute each transaction for (const tx of transactions) { currentState = executeTransaction(currentState, tx); } // Compute resulting state root const computedRoot = currentState.getMerkleRoot();
Verifier computes what the state should be
4
Compare State Roots
Compare computed root with sequencer’s claimed root
if (computedRoot === batch.newRoot) { console.log('✅ Batch is valid'); // No action needed } else { console.log('❌ FRAUD DETECTED!'); console.log(`Expected: ${computedRoot}`); console.log(`Claimed: ${batch.newRoot}`); // Prepare fraud proof generateFraudProof(batch, computedRoot); }
FraudProof { // Identification batchIndex: number, txIndex: number, // Transaction data transaction: { from: address, to: address, value: bigint, data: bytes, nonce: number, signature: bytes }, // State information preStateRoot: bytes32, // Before invalid TX claimedPostState: bytes32, // What sequencer claimed correctPostState: bytes32, // What it should be // Proof data merkleProofs: bytes32[], // Prove state access witnesses: bytes[] // Additional data needed }
Why Merkle proofs are needed:
State Root = Merkle tree of all accounts To verify a transaction, need to prove: 1. Account balances before TX 2. Account storage before TX 3. Account nonces before TX Merkle proof allows verifying WITHOUT sending entire state Example: State has 1M accounts Full state: 1GB Merkle proof for 2 accounts: ~10KB Size reduction: 100,000x smaller
Structure:
MerkleProof { leaf: account_data, siblings: [hash1, hash2, ..., hashN], path: bits (left/right directions) } Verification: 1. Hash leaf 2. Combine with sibling hashes following path 3. Should equal state root
Additional data for verification:
Witnesses { // Account states accountsBefore: { sender: { balance, nonce, code }, recipient: { balance, nonce, code } }, // Storage slots accessed storageBefore: { contract_address: { slot_1: value_1, slot_2: value_2 } }, // Accessed accounts list accessedAccounts: [address1, address2, ...], // Gas used gasUsed: number }
Purpose: Provide all data needed to re-execute transaction
Sequencer Stakes: $10,000,000 Daily Revenue: $100,000 Annual Revenue: $36,500,000 If Honest: - Keep earning $100K/day - Maintain $10M stake - Build long-term value If Dishonest: - Lose $10M stake (slashed) - Lose all future revenue - Get caught within 7 days - Reputation destroyed Expected Value: Honest: $10M + $36.5M/year = infinite (ongoing) Dishonest: -$10M (one-time loss) Rational Choice: Stay Honest
Why verifiers monitor:
Cost to Run Verifier: - Server: $100/month - Bandwidth: $50/month - Maintenance: $50/month Total: $200/month = $2,400/year Fraud Proof Reward: - 50% of sequencer slash - If sequencer has $10M staked - Reward: $5,000,000 Break-Even Analysis: If fraud happens once in 2000 years: Still profitable If fraud happens once per year: $5M - $2.4K = $4.9M profit Expected Value: Highly positive even with rare fraud Result: Multiple verifiers monitor continuously
Stable equilibrium:
Players: 1. Sequencer (wants profit) 2. Verifiers (want fraud rewards) 3. Users (want security) Strategies: Sequencer: [Honest, Dishonest] Verifiers: [Monitor, Don't Monitor] Payoff Matrix: Monitor Don't Monitor Honest (High, Low, High) (High, 0, High) Dishonest (-∞, High, Low) (High, 0, Low) (Sequencer, Verifier, User payoffs) Nash Equilibrium: (Honest, Monitor) - Sequencer maximizes profit by being honest - Verifiers profit from monitoring - Users get security No player can improve by deviating unilaterally