Detailed Instructions

The process begins when a user locks assets, like 10 ETH, in a smart contract on the source chain (e.g., Ethereum). The bridge protocol then mints a corresponding representation, often called a wrapped asset, on the destination chain (e.g., Arbitrum). This action is recorded as a state claim, asserting that the user is entitled to 10 wrapped ETH on the destination. Unlike zero-knowledge (ZK) proofs, which cryptographically verify the claim's correctness before finality, optimistic verification operates on a "innocent until proven guilty" principle. The state claim is accepted as valid immediately, initiating a challenge period (typically 7 days) during which it can be disputed.

• Sub-step 1: Lock assets - Call the bridge's deposit function, specifying amount and destination address.
• Sub-step 2: Generate claim - The bridge's oracle or relayer observes the lock event and posts a Merkle proof of the transaction to the destination chain.
• Sub-step 3: Mint tokens - The destination chain's bridge contract mints the wrapped tokens to the user's address, contingent on the challenge period.

Tip: Always verify the bridge contract address (e.g., 0x1231DEB6f5749EF6cE6943a275A1D3E7486F4EaE on Ethereum) to avoid scams. The speed here is a trade-off for security, relying on watchers to catch fraud.

Detailed Instructions

A designated proposer (or sequencer) aggregates multiple transactions into a batch and posts a cryptographic commitment, known as a state root, to the destination chain. This state root represents the new state of the bridge after the included transactions. Critically, this update is not instantly finalized. Instead, it enters a fraud proof window, a predefined time frame (e.g., 7 days or 20160 blocks on Optimism) where any network participant can challenge the validity of the state transition. This is the core of optimistic rollup design applied to bridges. During this window, the assets on the destination chain are technically not fully secure; their validity depends on the community's vigilance. Zero-knowledge bridges, in contrast, use validity proofs (like zk-SNARKs) to verify correctness in minutes, eliminating this delay.

• Sub-step 1: Batch transactions - The proposer collects pending transfers into a single batch for efficiency.
• Sub-step 2: Compute state root - Generate a Merkle root hash of the post-batch state using a function like keccak256.
• Sub-step 3: Submit to L1 - The proposer calls submitStateRoot(bytes32 root) on the destination chain's verification contract, paying a bond.

Tip: Monitor the proposer's bond amount; a high bond (e.g., 10 ETH) incentivizes honest behavior, as it's slashed if fraud is proven.

Detailed Instructions

If a watcher (any vigilant node or user) detects an invalid state root—such as a claim for assets that were never locked—they can submit a fraud proof to the verification contract. This proof is a succinct cryptographic argument demonstrating the inconsistency between the proposed state and the canonical source chain history. The proof typically includes Merkle proofs of the specific transaction in question. Upon receiving a valid fraud proof, the system will slash the proposer's bond, revert the fraudulent state update, and reward the watcher. This mechanism ensures economic security. The process is computationally lighter than generating a ZK proof but requires active monitoring. For example, a watcher might run a script checking for discrepancies every block.

• Sub-step 1: Monitor events - Watch for StateRootUpdated events on the verification contract.
• Sub-step 2: Validate against source - Cross-reference the proposed state with the source chain's data via an RPC call.
• Sub-step 3: Construct proof - If a mismatch is found, compile the necessary transaction data and Merkle proofs.
• Sub-step 4: Submit challenge - Call challengeStateRoot(uint256 batchIndex, bytes calldata proof) within the dispute window.

codeCopy
// Example pseudocode for a fraud proof check
if (proposedRoot != calculateRoot(sourceChainData)) {
    verificationContract.challengeStateRoot(batchIndex, merkleProof);
}

Tip: Running a watcher requires infrastructure costs but can be profitable via slashing rewards. The challengeStateRoot function must be called before the window closes (block.number < submissionTime + 201600).

Detailed Instructions

After the challenge period elapses without a successful fraud proof, the state root and all associated transactions are considered finalized. The wrapped assets on the destination chain transition from being provisionally credited to being fully secured and redeemable. This finalization is automatic and irreversible. The user can now freely trade or use their assets. This model offers lower transaction fees and higher throughput than ZK-based bridges, as it avoids the intensive computation of generating proofs for every batch. However, it introduces a withdrawal delay (the 7-day window) for full security. Some bridges offer instant liquidity via liquidity providers who front the funds, assuming the fraud risk for a fee.

• Sub-step 1: Wait for period end - The system checks if block.timestamp > stateRootTimestamp + 604800 (7 days in seconds).
• Sub-step 2: Execute finalization - The contract's finalizeStateRoot(uint256 batchIndex) function is called, often by a keeper bot.
• Sub-step 3: Update security status - The assets' status changes, and any locks on disputing the batch are removed.

Tip: Users preferring speed over cost might use a liquidity provider, but understand they are trusting that provider's risk assessment. For maximum security, always wait for the full challenge period to pass before considering large sums final.

Establishing a Trusted Source of Truth

State commitment is the foundational cryptographic proof that anchors the entire verification process. For a cross-chain bridge, this is typically a Merkle root representing the current state of all locked assets and pending withdrawals on the source chain. This root is periodically posted to the destination chain, often via a light client or a trusted relay. The commitment acts as the single source of truth that both optimistic and ZK verification mechanisms will later validate against.

• Sub-step 1: State Snapshot: The bridge operator or a decentralized set of validators creates a snapshot of the bridge's state (e.g., all user deposits) on the source chain (like Ethereum).
• Sub-step 2: Merkle Tree Construction: This state data is hashed into a Merkle tree. The final root hash, a 32-byte value like 0x4f6e...c3a1, becomes the commitment.
• Sub-step 3: Commitment Broadcast: The root is transmitted and recorded on the destination chain (like Polygon). This is often done via a smart contract function call: bridgeContract.postStateRoot(rootHash, blockNumber).

Tip: The security of the entire system depends on the integrity of this commitment. ZK proofs can verify its correctness without revealing the underlying data.

Relying on Economic Incentives for Security

Optimistic verification operates on the principle of "innocent until proven guilty." When a new state root is submitted, it is accepted optimistically and withdrawals can be proposed. However, a challenge period (typically 7 days) begins where any watcher can dispute the root's validity by submitting a fraud proof. This system relies on economic staking; actors who submit false roots have their stakes slashed, while successful challengers are rewarded.

• Sub-step 1: Root Submission & Bond Posting: A prover submits a new state root to the destination chain's bridge contract, along with a substantial bond (e.g., 100 ETH).
• Sub-step 2: Challenge Initiation: A watcher who detects an invalid root (e.g., a non-existent deposit) initiates a challenge by calling challengeStateRoot(submissionId) and providing a small bond.
• Sub-step 3: Fraud Proof Execution: The challenger must provide specific transaction data and Merkle proofs to a verifier contract, which re-executes the disputed state transition on-chain to prove fraud.

Tip: While capital-efficient, this model introduces significant withdrawal delays due to the mandatory challenge window, impacting user experience.

Cryptographically Guaranteeing Correctness

Zero-knowledge proofs (ZKPs), specifically zk-SNARKs or zk-STARKs, allow a prover to generate a succinct proof that a state transition is valid without revealing the underlying private data. For a bridge, this means proving that the new Merkle root correctly reflects all valid deposits and withdrawals, according to the bridge's rules, based on the previous root and the intervening transactions. This proof is generated off-chain and then verified on-chain almost instantly.

• Sub-step 1: Witness Generation: The prover (bridge operator) privately computes the witness data—the set of all valid transactions and their Merkle proofs linking to the old root.
• Sub-step 2: Proof Computation: Using a pre-defined circuit (the bridge's business logic), the prover runs a ZKP system like Circom or Halo2 to generate the proof. For example: snarkjs groth16 prove circuit.zkey witness.wtns proof.json public.json.
• Sub-step 3: Public Inputs Preparation: The prover prepares the public inputs for the verifier: the old state root, the new state root, and any necessary public transaction hashes.

Tip: The computational cost of proof generation is high off-chain, but on-chain verification is cheap and constant-time, enabling fast finality.

Achieving Secure and Fast Cross-Chain Transfers

The final step is the on-chain verification of the ZK proof. A verifier smart contract on the destination chain, pre-loaded with the verification key for the specific circuit, checks the proof against the public inputs. If valid, the new state root is immediately finalized, and users can withdraw their assets without any delay. This replaces the multi-day challenge period with instant cryptographic finality.

• Sub-step 1: Proof Submission: The prover submits the proof data and public inputs to the verifier contract via a function like verifyAndUpdateState(proof, oldRoot, newRoot).
• Sub-step 2: Cryptographic Verification: The contract runs its fixed verification algorithm. For a Groth16 zk-SNARK, this involves checking a pairing equation. A successful return is a simple boolean true.
• Sub-step 3: State Finalization & Withdrawal: Upon successful verification, the contract updates its canonical state root. Users can now instantly submit Merkle proofs (e.g., proof: bytes32[] calldata) against this finalized root to claim their assets on the destination chain.

Tip: This model offers superior security and UX but requires complex, audited circuit design and significant off-chain proving infrastructure.