Challenge

Welcome to the Web3 world, where digital finance and applications are shown in a revolutionary way through the fusion of blockchain technology, cryptocurrencies, and a pioneering spirit. Are you overwhelmed by the wealth of terms in the Web3 world that you don’t understand? Are those slangs barriers for you to learn about Web3? Don’t worry! We’re here to explain the obscure terms to guide your learning. Today, we're diving into an exciting development in the world of Ethereum scaling solutions: [Arbitrum Challenge].

When two Stakers have conflicting views on the appropriate judgment for an Assertion, they can be entered into a challenge. This challenge is adjudicated by the contracts on the base chain. Ultimately, one staker will prevail in the challenge. The protocol ensures that the truthful party will invariably win; the losing party must surrender their stake.

Source: CoinMarketCap

Window of time (1 week on Arbitrum One) is allotted during which a declared RBlock may be contested, and after this period, the RBlock can be confirmed.

The process through which RBlocks are submitted, challenged, and eventually verified is governed by the Challenge Protocol. This protocol ensures that only legitimate RBlocks are confirmed, assuming there is at least one honest Active Validator present.

The ChallengeManager oversees the adjudication of challenge games. Below is a diagram illustrating the challenge state machine:

Source: Arbitrum Docs

The challenge starts by dividing across global states (including block hashes). The conflict is first refined to a single block before any actual machine execution is debated. When the challenge has been narrowed down to a particular block, the current responder can initiate challengeExecution. This process is akin to a bisection where the responder must submit an alternative global state and machine state, which then facilitates the move into the execution challenge phase.

After narrowing the focus to a specific block, the actual machine execution can then be segmented further. When the execution has been segmented down to a single step, the current responder can invoke oneStepProveExecution. At this point, the responder is required to supply evidence needed to execute a step of the machine. If executing this step results in a state that differs from the one initially claimed, the current responder triumphs in the challenge.

The ChallengeLib helper library features a method called hashChallengeState, which processes a list of segment hashes, a starting position, and the total length of segments to produce the challengeStateHash of the ChallengeLib.Challenge. This provides sufficient information to determine the position of each segment hash. The term "degree" in the challenge context refers to one less than the total number of segment hashes. The distance between segments is calculated as floor(segmentsLength / degree), but for the last pair of segments, the remainder of segmentsLength divided by degree is added to the usual distance, ensuring the total distance equals segmentsLength.

Source: Cointelegraph

A challenge typically starts with just two segments (a degree of one), based on the asserter's original claim. The bisection game then commences on the challenger's turn. During each game round, the current responder must select a neighboring pair of segments to contest, thereby challenging the claim that starting from the first segment and executing the determined steps will lead to the second segment. At this juncture, both parties agree on the accuracy of the first segment but dispute the outcome of the second. The responder is then required to provide a bisection starting from the first segment and ending in a different segment than the second, thus subdividing the challenge into smaller segments, and shifting the play to their opponent. Each bisection should maintain a degree of at least min(40, numStepsInChallengedSegment) to ensure the challenge progresses.

Moreover, a segment that is only one step long cannot be further divided. The specific actions at this stage depend on the challenge phase, which could involve a challengeExecution or oneStepProveExecution.

This protocol is unique in its symmetry; unlike traditional bisection protocols where one side proposes and the other chooses to challenge, here both participants alternately propose challenges and bisections.

It's important to note that currently, winning a challenge does not result in immediate victory. Rather, it positions the current responder as the opponent of the winner and resets the state hash to zero. In this state, the party has no viable moves and will ultimately lose due to a timeout. This approach is taken as a safety measure, allowing time to identify and correct any errors in the challenge resolution through a contract upgrade if necessary.

Arbitrum Challenge introduces a refined dispute resolution mechanism for Ethereum scaling, specifically within the Arbitrum network. This protocol ensures that only legitimate Rollup Blocks (RBlocks) are validated through a structured challenge process managed by the Challenge Protocol and the ChallengeManager. If two stakers disagree on an assertion, they enter into a challenge where the veracity of RBlocks can be contested over a one-week period. The resolution involves bisecting global states down to individual blocks and even further into specific machine operations. Participants use a "bisection game" strategy, choosing segments to challenge and defend, ultimately proving their claim with evidence for a particular machine step. This meticulous process ensures that the honest participant prevails, with the loser forfeiting their stake.