Skip to main content

Assertions

The Rollup chain assertions vs. child chain blocks

The Rollup chain consists of assertions, which serve as checkpoints summarizing multiple child chain blocks.

  • Child chain blocks contain individual transaction data
  • Assertions provide state summaries recorded on Ethereum
  • Each assertion may represent multiple child chain blocks, optimizing gas costs and reducing Ethereum storage usage.

Validators submit assertions by calling createNewAssertion in the Rollup contract. Assertions contain structured data known as AssertionInputs, which capture the before-state and after-state of execution for future validation.

Contents of an assertion

Each assertion consists of:

  • Assertion number: A unique identifier
  • Predecessor assertion: The last confirmed assertion
  • Number of child chain blocks: The total child chain blocks included
  • Number of inbox messages: Messages consumed during execution
  • Output hash: A cryptographic commitment to the resulting state

Arbitrum ensures assertions are automatically confirmed or rejected based on protocol rules:

  1. An assertion is confirmed if:
    • Its predecessor is the latest confirmed assertion
    • The dispute window has passed without challenges
  2. An assertion is rejected if:
    • Its predecessor assertion is invalid
    • A conflicting assertion has been confirmed

For more details on how the Rollup chain works under BoLD, the gentle introduction provides an overview that touches on the Rollup chain.

note

Validators and proposers serve different roles. Validators validate transactions by computing the next chain state using the chain's STF, whereas proposers can also assert and challenge the chain state on the parent chain.

Except for the assertion number, the contents of the assertion are all just claims by the assertion's proposer. Arbitrum doesn't know at first whether any of these fields are correct. The protocol should eventually confirm the assertion if all of these fields are correct. The protocol should eventually reject the assertion if one or more of these fields are incorrect.

An assertion implicitly claims that its predecessor assertion is correct, which means that it also claims the correctness of a complete history of the chain: a sequence of ancestor assertions that reaches back to the birth of the chain.

An assertion also implicitly claims that its older siblings (older assertions with the same predecessor), if there are any, are incorrect. If two assertions are siblings, and the older sibling is correct––then the younger sibling is considered incorrect, even if everything else in the younger sibling is true.

The assertion is assigned a deadline, which indicates how much time other validators have to respond to it. For an assertion R with no older siblings, this will equal the time the assertion was posted, plus an interval of time known as the challenge Period; subsequent younger siblings will have the same deadline as their oldest sibling (R). You don't need to do anything if you're a validator and agree that an assertion is correct. If you disagree with an assertion, you can post another assertion with a different result, and you'll probably end up in a challenge against the party who proposed the first assertion (or another party acting in support of that assertion). More on challenges below:

Delays

Even if the Assertion Tree has multiple conflicting assertions and multiple disputes are in progress, validators can continue making new assertions. Honest validators will build on one valid assertion (intuitively, an assertion is also an implicit claim of the validity of all of its parent assertions). Likewise, users can continue transacting on the child chain since transactions will continue to post in the chain's inbox.

The only delay users experience during a dispute is their Child to parent chain messages (i.e., withdrawals). A key property of BoLD is that we can guarantee that, in the common case, their withdrawals/messages will only get delayed for one challenge period. In the case of an actual dispute, the withdrawals/messages will be delayed by no more than two challenge periods, regardless of the adversaries' behavior during the challenge.

Staking and validator incentives

Arbitrum requires validators to bond ETH as a security deposit to ensure honest participation and prevent malicious behavior. This mechanism enforces economic accountability:

  • Proposers (validators submitting assertions) must bond ETH to support their claims.
  • Challenges against incorrect assertions result in bond forfeiture for dishonest validators.
  • Successful challengers receive a portion of the dishonest validator's bond as a reward.

Validators can adopt different roles:

  1. Active validators: Regularly propose new assertions.
  2. Defensive validators: Monitor the network and challenge incorrect assertions.
  3. Watchtower validators: Passively observe and raise alarms when fraud is detected.

The protocol design requires only one honest validator to secure the system, making Arbitrum trustless and resistant to Sybil attacks.

Staking mechanism

Some validators will act as bonders at any given time, while others remain passive. Bonders deposit ETH bonds into Arbitrum's smart contracts, which are forfeited if they lose a challenge.

note

Nitro chains exclusively accept ETH as collateral for staking.

A single bond can secure a sequence of assertions, meaning a validator's bond applies to multiple checkpoints of the chain's history. This checkpoint allows efficient resource use while maintaining security.

A validator must be bonded to its predecessor to create a new assertion. The bond ensures that validators have economic risk in any assertion they make.

Handling disputes and delays

Multiple disputes may be active simultaneously if conflicting assertions arise in the Assertion Tree. However, Arbitrum's protocol ensures that:

  • Honest validators can continue asserting, building on the last correct assertion.
  • Users can keep transacting on the child chain without disruption.
  • Child-to-parent chain withdrawals may experience delays - Typically, withdrawals experience a single challenge period (6.4 days) delay. - A key property of BoLD is that we can guarantee that in the common case, withdrawals/messages will only experience delay of one challenge period. In the case of an actual dispute, the withdrawals/messages will be delayed by no more than two challenge periods, regardless of the adversaries' behavior during the challenge.

Despite these delays, Arbitrum guarantees that honest assertions always succeed, maintaining Ethereum-level security.