中文版 · Blockchain learning guide · Previous article
Blockchain learning · Article BC047
An optimistic state assertion is a claim that can become accepted through a specified challenge process. Its protection depends on more than the existence of a button labelled “challenge”: someone must be able to obtain the relevant data, check the correct rules, submit a valid dispute in time and carry that dispute through the required procedure.
A waiting period does not itself calculate whether a claim is correct. Nor does an unanswered assertion prove that every transaction behind it was valid. The mechanism’s security argument needs explicit monitoring, data, inclusion, execution and administrative assumptions.
This lesson follows a deliberately small challenge process from assertion to resolution. It separates a correct calculation, a timely challenge, an accepted state and a later exit condition.
Choose your reading route
In this guide
- 1. An assertion must identify its subject
- 2. What the observer needs before calculating
- 3. Calculate the classroom trace
- 4. Specify the challenge machine before starting its clock
- 5. Follow the successful challenge
- 6. Examine the exact boundary
- 7. An unanswered invalid assertion exposes an assumption
- 8. A challenge is not automatically a winning challenge
- 9. Data availability is a prerequisite, not a decorative link
- 10. Permission and inclusion matter as much as detection
- 11. Correct adjudication requires exact binding
- 12. Acceptance, base-chain finality and exit are separate
- 13. Administrative controls belong in the evidence packet
- 14. Exercise: classify the timeline cards
- 15. Frequently asked questions
- Sources and next reading
Begin with the observer’s evidence checklist. Then calculate the two-step classroom trace and follow the height-120 deadline. Compare an unresolved dispute, a late challenge and a correctly defended assertion before completing the exercises.
The entire challenge machine below is fictional. Its block-height deadline and simple arithmetic verifier are teaching rules, not the rules of OP Mainnet or any other deployed rollup. No live challenge, bond, transaction, withdrawal or financial action is performed.
Primary references were checked on 12 October 2026. Named OP Stack specifications are used to show that real systems define particular game types, states, clocks and resolution procedures. A specification page is not evidence of every network’s currently deployed configuration.
Back to contents · Next section
1. An assertion must identify its subject
An operator’s assertion needs more context than “the new result is 14”. Our fictional assertion identifies application ArchiveCounter, rule version AC1, the starting-state commitment, an ordered batch commitment, the ending-state commitment and the relevant base-chain context.
The commitments are assumed correctly bound to their objects under the exercise’s cryptographic assumptions. We use readable values to inspect the computation, but we do not pretend a decimal number is a real state root or that a displayed label authenticates its origin.
Changing the batch, starting state or rule version creates a different claim. An observer who proves that another batch gives 13 has not necessarily disproved the actual assertion about this batch.
The first task is therefore alignment: are the operator and observer talking about exactly the same ordered inputs and rules? Only then is a disagreement about the output meaningful.
Back to contents · Next section
2. What the observer needs before calculating
Our observer O needs the authenticated starting state, the complete relevant batch data, its order, the precise AC1 transition rule and the assertion’s identity. O also needs the applicable challenge permissions, deadline convention and dispute procedure.
The Ethereum optimistic-rollup overview describes the role of published data and fraud challenges. We use that high-level relationship, not a universal withdrawal duration or a claim that absence of challenge logically proves correct execution.
For the main exercise, the relevant data is actually retrievable and correctly matched to the published commitment. O has the resources and permissions needed to prepare the specified evidence. These conditions are supplied explicitly so that we can focus first on the timeline.
Later variations remove one condition at a time. That is more informative than calling a mechanism “trustless” without saying which honest participant can act, what they must possess or what happens if they cannot get their action processed.
Back to contents · Next section
3. Calculate the classroom trace
AC1 maintains one nonnegative integer counter. Each authorised instruction adds an integer from 0 through 3 inclusive. The starting counter is 10, and the authenticated ordered batch contains Add(2), then Add(1).
All authorisations and other validity checks are supplied as passing. The correct trace is therefore 10 to 12 to 13. The final value must be 13 under these inputs and this rule.
The operator instead asserts a final value of 14 and, in the dispute, supplies the trace 10 to 12 to 14. The first step agrees. The second step does not: 12 plus the specified 1 is 13, not 14.
This arithmetic localises the disagreement. It is not a production fraud proof by itself. The fictional adjudication contract must still verify that the alleged step, its pre-state, input and claimed post-state belong to the exact committed assertion being disputed.
Back to contents · Next section
4. Specify the challenge machine before starting its clock
The assertion is recorded on base chain L at block height 100. Its initial challenge deadline is height 120, inclusive. A properly formed initial challenge must be included and accepted by the relevant L contract at a height no greater than 120; simply broadcasting it before that height is insufficient.
The fictional machine uses these rules:
- Before acceptance, an assertion can be pending without a dispute or pending with an unresolved dispute.
- An eligible initial challenge accepted by height 120 starts a dispute. An initial challenge first included at 121 is too late under this rule.
- Any timely unresolved dispute prevents acceptance, even after height 120.
- A successful challenge causes the assertion to be rejected.
- A failed challenge removes that dispute as an obstacle, but acceptance still requires height greater than 120 and all other supplied conditions.
- Acceptance requires a separate successful contract action. The passage of height alone does not execute it.
We assume one relevant dispute for these traces, correct adjudication, no administrative override and sufficient ongoing L processing. The simplified resolution schedule is supplied by each case; we do not model every move or clock extension of a production protocol.
Back to contents · Next section
5. Follow the successful challenge
O obtains the data, computes 13 and recognises the incorrect assertion of 14. O’s correctly bound challenge is included at height 118. The contract records a pending dispute against the named assertion.
At height 121, the original challenge-opening window has ended, but this dispute is unresolved. The assertion is not eligible for acceptance merely because 121 is greater than 120. The unresolved-dispute condition still blocks it.
At height 125, the supplied adjudication process correctly verifies the second-step inconsistency and resolves in O’s favour. The assertion is rejected. There is no subsequent acceptance of this rejected assertion just because additional blocks pass.
The accepted starting state remains the prior state in this toy process. A corrected assertion would need its own specified submission and acceptance path. We do not silently install the observer’s value as a new accepted state unless a rule actually instructs the contract to do that.
Back to contents · Next section
6. Examine the exact boundary
Now move O’s initial challenge to height 120. Because the fictional rule is inclusive, a correctly processed challenge at 120 is timely. If it is still unresolved at 121, it continues to block acceptance.
Move the first inclusion instead to height 121. It is late. Sending the request while an interface showed 119 does not establish that the contract accepted it before the deadline. The relevant observation is the recorded action in the relevant L history.
Real systems can use timestamps, inherited clocks, multiple rounds, extensions or other timing rules. The OP Stack Fault Dispute Game specification includes its own game-clock and resolution machinery. Our single inclusive block-height window is deliberately not a substitute for those details.
The general lesson is to read the inequality and the event it measures. “Before the deadline” could mean very different things if someone confuses preparation, broadcast, inclusion, successful processing and finality of the containing block.
Back to contents · Next section
7. An unanswered invalid assertion exposes an assumption
Return to the incorrect assertion of 14. In a variation, no eligible challenge is successfully processed by height 120. At 121, suppose a valid acceptance action executes, and all other toy conditions are met.
Under this optimistic machine, the unchallenged assertion can be accepted even though our independent arithmetic shows it is wrong. This is precisely why the security argument needed an effective honest challenge, rather than merely the abstract possibility that one existed.
The result does not mean every optimistic system accepts every invalid claim. It means the stated toy mechanism relies on specified conditions that this variation has removed. Different real protocols may add safeguards, but they must be identified rather than imagined.
When writing a security summary, use the complete conditional: an invalid assertion is prevented from being accepted if an eligible honest observer can obtain the data, detect the error, get the necessary actions processed in time and complete a sound dispute process under the system’s other assumptions.
Back to contents · Next section
8. A challenge is not automatically a winning challenge
Consider a separate assertion with the correct final value 13. Someone challenges it at height 118, but the supplied adjudication at 125 confirms the claimed trace is correct and the challenge fails.
At height 121, while the dispute is unresolved, acceptance is still blocked. At 125, after the failed challenge is resolved, the height condition is satisfied and there is no unresolved or successful challenge. The assertion becomes eligible for acceptance under the remaining conditions.
It has not necessarily been accepted yet. If the separate acceptance action runs successfully at 126, that is the acceptance event to record. If no such action runs, the worksheet should say “eligible” rather than “accepted”.
The OP Stack dispute-game interface distinguishes an in-progress game from challenger-winning and defender-winning outcomes. Those real status distinctions reinforce the reading habit; our toy state machine and its extra acceptance action remain separately defined.
Back to contents · Next section
9. Data availability is a prerequisite, not a decorative link
Suppose O can see the batch commitment but cannot obtain the required batch bytes or starting-state data. The commitment helps identify what data would match; it does not supply the missing content needed to recompute the trace.
O cannot honestly report that it checked Add(2), Add(1) if the actual batch was never obtained. A screen saying “data posted” also needs the relevant publication and retrieval context. The main case supplied actual retrievability, not just an operator’s claim.
This variation removes a prerequisite for effective monitoring. It does not by itself define how the contract reacts to missing data. If a real design has a separate data-availability rule, timeout or fallback, that mechanism must be examined on its own terms.
Nor does the observer’s later possession of some data prove it had enough time earlier. A review should record when the data became usable relative to the relevant challenge and response deadlines.
Back to contents · Next section
10. Permission and inclusion matter as much as detection
O might calculate the error correctly yet lack permission to challenge under a permissioned game. Or O might be eligible but unable to get a required action included before its deadline. In both cases, mathematical detection and effective protocol intervention diverge.
Our main case explicitly grants O eligibility and successful processing of its actions. Remove either assumption and the conclusion must narrow. A public specification explaining a challenge procedure does not prove that every deployment enables every reader to use it.
The OP Stack fault-proofs explainer discusses proposals, challenges and additional safeguards, including privileged intervention and delays. This is a reminder to check the installed game and relevant controls, rather than assuming the general label describes all operational permissions.
No one needs to perform a real challenge to learn this distinction. An architecture review can ask for the active game type, authorised participants, timing rules, software assumptions and evidence of the path from detection to included protocol action.
Back to contents · Next section
11. Correct adjudication requires exact binding
In the arithmetic example, a reviewer needs more than the sentence “12+1=13”. The evidence must connect that step to AC1, the authenticated initial state, the ordered batch and the disputed commitment.
Suppose a challenger substitutes Add(2), Add(2). That alternative batch ends at 14, but it is not the committed batch in our case. Likewise, proving a step under another rule version does not resolve a claim about AC1.
A real multi-round game may narrow a larger dispute down to a step, with commitments and other evidence connecting the pieces. The correctness of that connection matters as much as the final step evaluator. The toy exercise assumes it is implemented correctly instead of pretending two lines of arithmetic implement the full system.
An incident record should therefore identify the disputed assertion and procedure, not just attach a screenshot of an unexpected result. Reproducible disagreement requires shared context before it requires persuasive language.
Back to contents · Next section
12. Acceptance, base-chain finality and exit are separate
After a correct assertion’s acceptance action succeeds on L, the containing block may still need the relevant L finality evidence. An application should report the accepted branch and finality context separately rather than assuming contract success is the last possible condition.
An exit based on that state has its own requirements. In our conceptual model, it must reference an accepted state, provide correctly bound evidence of the eligible exit, satisfy replay and authorisation conditions, and meet the relevant L processing and finality requirements.
We do not set a universal withdrawal duration. Real protocols can have challenge clocks, additional waiting periods, pausing powers or other conditions. A liquidity service offering an earlier payment would be a separate arrangement with its own assumptions, not proof that the underlying protocol’s process ended early.
The lesson stops at interpreting these prerequisites. It provides no bridging instructions, fee recommendation or financial service route.
Back to contents · Next section
13. Administrative controls belong in the evidence packet
The toy baseline has no override or pause administrator. If a variation adds an authority that can suspend acceptance, replace the adjudicator or change the permitted game, the earlier timing calculation is no longer the whole story.
For example, reaching height 121 without a dispute would not establish practical acceptance if an applicable pause blocks the acceptance action. Replacing the step checker could also change what result the contract recognises as correct.
These powers do not become irrelevant because the system contains a fault-proof mechanism. A reviewer should name their scope, the actors who control them, any delays and the version of the rule being assessed.
Do not infer malicious intent merely from a technical power. The point is to include the dependency honestly so that the security statement describes what the installed system can do.
Back to contents · Next section
14. Exercise: classify the timeline cards
Apply only the fictional rules in section 4. No additional challenges or administrative powers exist unless stated.
- Incorrect assertion14, challenge accepted at120, still unresolved at121. Can an acceptance action succeed at121?
- Incorrect assertion14, first attempted challenge is included at121, no earlier challenge. Is that initial challenge timely?
- Correct assertion13, challenge at118, adjudication rejects the challenge at125, acceptance action succeeds at126. When does eligibility arise, and when does acceptance occur?
- Incorrect assertion14, no timely challenge, acceptance action succeeds at121. Does the lack of a challenge prove the arithmetic was correct?
- O finds the correct value13 but cannot retrieve the committed batch and used a guessed batch instead. Has O established the required dispute evidence?
- An accepted assertion appears in an L block without the required finality evidence. Is final settlement established by contract success alone?
Answers and reasoning
- No. The inclusive deadline makes the challenge timely, and unresolved disputes block acceptance even after the opening window ends.
2. No. Under the explicit rule, initial inclusion must occur at a height no greater than120. Earlier preparation or broadcast does not change the recorded inclusion height.
3. Eligibility arises after resolution at125, since125 is greater than120 and the unsuccessful dispute no longer blocks it. Acceptance occurs when the separate action succeeds at126.
4. No. The toy machine can accept an unchallenged bad assertion when the effective-honest-challenger assumption fails. Our calculation remains10+2+1=13.
5. No. A guessed or different batch is not the authenticated input of the assertion. The observer needs matching data and exact binding, not merely an output it believes plausible.
6. No. The relevant L history and finality conditions still need to be established, alongside any separate exit requirements.
Back to contents · Next section
15. Frequently asked questions
Must a challenge period always be seven days?
No universal duration is used here. The toy period is specified in heights. For a named deployment, inspect its actual game, clocks, configuration and any additional delays.
Does one honest person anywhere guarantee safety?
That slogan omits prerequisites. The relevant participant must have the required information, permissions, resources and ability to complete the protocol actions in time, with correct verification and the other stated assumptions.
Does a successful challenge automatically install the challenger’s preferred state?
Only if the protocol specifies that effect. Our toy rule rejects the bad assertion; a replacement must follow its own specified path. Do not invent a state update from the winner’s identity alone.
Back to contents · Next section
Sources and next reading
Primary sources checked on 12 October 2026, Singapore time:
- Ethereum optimistic rollups: the relationship among offchain execution, published data and challenges. Universal timing, performance and unconditional-security generalisations are not used.
- OP Stack dispute-game interface: named game types, claims and distinct resolution statuses. This moving specification is not a deployment attestation.
- OP Stack Fault Dispute Game: trace commitments, step evaluation, clocks and resolution as protocol-specific machinery. The classroom rule is not an implementation of this game.
- OP Stack fault-proofs explainer: proposal/challenge roles and additional safeguards that must be checked for the relevant deployment.
The previous attached-system worksheet asks where assurances come from. This lesson isolates the honest observer’s timed intervention. Next, compare that route with verifying a validity proof, while keeping proof acceptance, state reconstruction and usable exit evidence separate.