Skip to main content

Customizable challenge period

The challenge period defines the time frame during which state updates (assertions) submitted to the parent chain remain open for scrutiny and potential challenges before they are finalized. This mechanism ensures that participants in the system have the opportunity to verify the validity of state updates and raise challenges if necessary.

The length of the challenge period is measured based on the parent chain's notion of time, typically reflected in block.number. For L3s settling to Arbitrum chains, this period is determined by L1 block progression rather than Arbitrum's (L2) blocks.

In addition to the main challenge period, an extra challenge period provides a buffer to resolve any pending challenges after the main period ends. Together, these parameters help balance security and confirm the chain's state.

Default challenge period and extra challenge period​

How time is measured in challenges

Chains settling to Ethereum or Arbitrum chains use block.number for all block calculations, which corespond to the chain's view of Ethereum's block number. For example, an L3 Arbitrum chain settling to Arbitrum One, will calculate block progression based on Ethereum's (L1) block number.

By default, the challenge period lasts approximately one week, which equates to roughly 45,818 L1 blocks for chains that settle to Ethereum or an Arbitrum chain. The default duration design is to provide sufficient time for validators to detect and challenge fraudulent assertions.

On the other hand, the extra challenge period adds a buffer of 40 minutes by default, 200 L1 blocks for chains settling to Ethereum or an Arbitrum chain. This time ensures that any last-minute challenges or ongoing dispute resolution processes can be completed before the rollup finalizes its state.

These default values are selected to carefully balance security and performance for most rollup use cases. However, developers and Orbit chain owners may wish to customize these parameters to suit their specific requirements.

Customizing the challenge period​

Challenge period blocks​

The main challenge period configuration uses the confirmPeriodBlocks parameter, which specifies the duration of the challenge window based on the parent chain’s notion of block.number. This parameter can is customizable in two ways:

  1. During deployment: Developers can specify the desired value in the confirmPeriodBlocks field of the RollupCreator configuration when deploying the rollup.
  2. Post-deployment: The chain owner can update this value dynamically by calling the Rollup.setConfirmPeriodBlocks(newValue) function.

For example, setting confirmPeriodBlocks to 30,000 blocks reduces the challenge period to approximately 4.5 days. This configuration might be suitable for applications prioritizing faster state confirmation, while increasing the value would extend the challenge period, improving security.

Extra challenge period blocks​

The extra challenge period is governable using the extraChallengeTimeBlocks parameter, which defines the additional buffer duration after the main challenge period. This period ensures that pending challenges are processed before the rollup state gets finalized.

By default, the extra challenge period is set to 200 blocks, providing a short but sufficient buffer for most networks. However, developers can increase this value for applications requiring additional dispute resolution time or operate in environments with higher latency between the parent and child chain.

Like the main challenge period, this parameter is customizable in two ways:

  1. During deployment: The value can be set in the extraChallengeTimeBlocks field of the RollupCreator configuration.
  2. Post-deployment: The chain owner can dynamically adjust the parameter using the Rollup.setExtraChallengeTimeBlocks(newExtraTimeBlocks) function.

For example, the following command can update the extra challenge period to 300 blocks based on the parent chain’s notion of block.number:

cast send <ROLLUP_ADMIN_ADDRESS> "setExtraChallengeTimeBlocks(uint256)" 300 \
  --rpc-url <RPC_URL> \
  --private-key <PRIVATE_KEY>

Replace:

<ROLLUP_ADMIN_ADDRESS> with the contract address of the rollup admin. <RPC_URL> with the appropriate RPC endpoint. <PRIVATE_KEY> with the private key of the authorized admin account (e.g., chain owner).

For Orbit chains aligned with Arbitrum One's configuration, the recommended settings are:

  • Challenge period blocks: 45,818 Ethereum blocks (approximately one week).
  • Extra challenge period blocks: 200 Ethereum blocks (approximately 40 minutes).

These values offer a robust and balanced setup for most rollup use cases. Developers should consider their application’s requirements when adjusting these parameters:

  • Shorter periods: Suitable for applications that benefit from faster state confirmation, such as rollups prioritizing quicker exits or user withdrawals. For chains settling to Ethereum or an Arbitrum chain, this reduces challenge duration based on L1 block times.
  • Longer periods: Recommended for applications requiring higher security, such as cross-chain asset transfers or large-value transactions. The actual duration depends on the parent chain’s block intervals (e.g., Ethereum vs. other chains).