Skip to main content

Why choose to customize the challenge period for your Arbitrum chain

Choosing or configuring the challenge period refers to setting the duration (measured in parent chain blocks) during which state assertions—claims about the chain's execution history, block hashes, and inbox messages—can be disputed via fraud proofs before they are confirmed as valid on the parent chain (e.g., Ethereum or an Arbitrum L2).

This period is a core security parameter in optimistic rollups, ensuring time for validators to detect and challenge invalid states, after which unchallenged assertions achieve finality, enabling secure withdrawals. Configuration is done during deployment or post-deployment by the chain owner, allowing trade-offs between security (longer periods) and speed (shorter periods). It's composed of two main parameters: the primary challenge period (confirmPeriodBlocks) and an extra buffer (extraChallengeTimeBlocks).

It's set by the chain owner and can be chosen based on the application's risk tolerance—e.g., high-value DeFi might opt for longer periods, while gaming appchains favor shorter ones.

Key Concepts​

  • Challenge Period (confirmPeriodBlocks): The main window for validators to bond stakes and initiate challenges against potentially fraudulent assertions. If no valid challenge is raised, the assertion confirms, and the chain's state advances securely.
  • Extra Challenge Period (extraChallengeTimeBlocks): A post-main-period buffer to resolve any ongoing disputes or last-minute challenges, preventing premature finalization.
  • Measurement: Always denominated in the underlying L1 chain's blocks (e.g., Ethereum's block.number, ~12 seconds per block), even for L3 chains settling to an L2 like Arbitrum One. This ensures consistent timing aligned with the parent chain's finality.
  • Defaults:
    • Primary: Approximately 45,818 L1 blocks (~1 week or 6.4 days on Ethereum).
    • Extra: 200 L1 blocks (~40 minutes).
  • Related Features: Interacts with minimum assertion periods (default 75 L1 blocks or ~15 minutes) to prevent rapid assertions, and can be shortened dramatically (e.g., to 15 minutes) via fast withdrawals in AnyTrust mode, where the Data Availability Committee (DAC) accelerates verification.

Compatibility​

  • With DA Modes: Fully compatible across Rollup (full on-chain DA), AnyTrust (DAC-based), and Alt-DA (e.g., Celestia). In AnyTrust, fast withdrawals can reduce the effective period to 15 minutes by leveraging the DAC for rapid verification, bypassing traditional delays.
  • With Gas Tokens: No direct impact; works with native ETH or custom ERC-20s, as the period governs validation timing rather than fee mechanics.
  • With Validation (e.g., BoLD): Integrates with BoLD's permissionless disputes, where the period sets the initial challenge window, but BoLD bounds total delays to at most two periods (~12.8 days max on Ethereum) during active disputes, mitigating delay attacks.

Pros​

  • Customizability: Allows optimization for specific use cases, e.g., shorter periods for low-risk, high-speed apps like gaming (reducing withdrawal waits from days to minutes via fast withdrawals).
  • Enhanced Security with Longer Periods: Provides ample time for fraud detection, especially in permissioned or high-stakes setups.
  • Buffer for Reliability: The extra period ensures dispute resolution in high-latency environments.

Cons​

  • Trade-Offs in Length: Shorter periods risk undetected fraud if validators miss the window; longer ones delay finality, impacting UX (e.g., 6.4 day waits for withdrawals).
  • Dependency on Parent Chain: Timing is tied to L1 block times, which can vary (e.g., Ethereum congestion), and misconfiguration could lead to stalled chains or economic attacks.
  • Complexity in AnyTrust Fast Withdrawals: Requires DAC setup and minimal hardware (e.g., 8-16 GB RAM, 1.2 TB SSD), but introduces mild trust assumptions for the speed gains.

Examples​

  • Standard High-Security Setup: Arbitrum One uses ~1 week for broad DeFi compatibility, balancing security with Ethereum settlement.
  • Fast AnyTrust Chain: A gaming L3 might configure 15-minute periods via fast withdrawals, enabling near-instant cross-chain asset moves (672x faster than defaults).
  • Custom Adjustment: Set primary to 30,000 blocks (~4.5 days) for moderate-speed apps, with extra at 300 blocks for added buffer in latency-prone environments.

When to configure​

  • During Deployment: Specified in the RollupCreator configuration (e.g., via the Orbit SDK deployment portal or scripts like createRollup.ts). For example, set confirmPeriodBlocks to 30,000 for ~4.5 days.
  • Post-Deployment: Dynamically updated via owner-privileged contract calls, such as Rollup.setConfirmPeriodBlocks(newValue) for the primary period or Rollup.setExtraChallengeTimeBlocks(newExtraTimeBlocks) for the extra buffer (e.g., using tools like cast for onchain transactions).

This parameter underscores Arbitrum's modular design, allowing chains to fine-tune validation without compromising core fraud-proof security. For implementation, refer to the official docs, or your RaaS; a list of RaaSes is on the Third-party providers page.