MIMD-0024: Challenge Mechanism

[GabrielePicco]

MIMD: Dynamic Fraud Proof Challenge Mechanism

Status

Draft proposal/specification.

Goal

Define the permissionless challenge and finalization mechanism for an Ephemeral
Rollup operator commitment.

A state commitment can finalize only if:

1. it is posted as a pending commitment in the Delegation Program;
2. the challenge window has elapsed;
3. enough randomly selected active verifier nodes have co-signed the
   commitment;
4. no unresolved challenge blocks finalization.

This proposal is part of the Dynamic Fraud Proof design described in
Dynamic Fraud Proof.

The mechanism is split into three phases:

1. posting a state commitment and opening the challenge window;
2. collecting approvals from randomly selected active verifiers, or receiving a
   challenge;
3. resolving the challenge and assigning fault if a challenge is raised.

This document focuses on the challenge path and defines a simple initial
resolution path. Future versions are expected to replace the social resolution
path with objective replay on a zkSVM.

Non-goals

State divergence detection is out of scope for this mechanism. Divergence is
detected by magicblock-validator instances running in replica mode and
monitoring operator output.

Multi-account challenges are also out of scope for the first version. A
challenge targets exactly one account at one commit id. Multi-account disputes
must be submitted as independent single-account challenges.

Operator selection and provisioning are out of scope. This document assumes an
operator has already been selected for the delegated account or ER session.

Actors

• Operator or Validator: the node running the Ephemeral Rollup session and
  posting account state commitments to the Delegation Program.
• Verifier or Active challenger: a bonded network participant eligible to be
  randomly selected to verify and co-sign a pending commitment.
• Challenger: any participant with the required minimum stake who raises a
  challenge during the challenge window.
• Delegation Program: the base-layer program that stores pending commitments,
  opens challenge windows, verifies co-signatures, blocks challenged
  commitments, and finalizes resolved state.
• Security council: a separate stake-weighted resolver used only for the
  initial dispute-resolution implementation.

The security council is not the happy-path finalization committee. Happy-path
finalization depends on randomly selected active verifiers.

Commitment scope

A pending commitment is bound to:

• one operator identity;
• one account public key;
• one commit id, also referred to as a nonce in the current implementation;
• one delegation record;
• one Data Availability record pointer;
• one committed account state hash;
• one challenge window;
• one verifier selection context;
• one required verifier signature threshold.

The protocol commitment key is the account plus commit id. The ephemeral slot
that produced the state may be included as metadata for observability and
debugging, but it is not the protocol key.

Operator participation must move from the current whitelisting model to a
permissionless operator bond model. The current validator fee vault is not
slashable stake and must not be treated as the operator bond.

Verifier participation must also be permissionless and bonded. A verifier
signature should only count toward finalization if the verifier was eligible and
selected for the commitment round.

State commitment

The operator commits to the account state it wants to finalize by posting a
pending state commitment.

The state commitment must be domain-separated and bound to the complete
commitment context:

state_commitment_hash = H(
  "magicblock.state_commitment.v1",
  operator_identity,
  account_pubkey,
  commit_id,
  delegation_record,
  da_pointer,
  lamports,
  owner,
  data_hash
)

The canonical account state for this version consists of:

• lamports;
• owner;
• data.

executable is excluded because executable accounts are not delegatable in this
design. The owner should be explicitly committed as part of the finalized state;
the current implementation stores owner information in the delegation record and
commits lamports plus data, but the challenge design should bind owner as well.

Full account data is supported. Large account data may be committed through a
hash and opened through buffered submission if the state is challenged.

The Data Availability pointer must reference the transaction data needed to
replay or verify the ER execution that produced the committed state.

The exact byte serialization, hash function, missing-account representation,
minimum stake amount, initial challenge window, window-extension schedule,
response timeout, and voting timeout are protocol parameters to be finalized
before implementation.

Verifier selection and co-signing

When the operator posts a pending commitment, the challenge window starts and a
set of active verifiers is randomly selected from the bonded verifier set.

Selection must be:

• unpredictable before the commitment round;
• verifiable by the Delegation Program;
• derived from a registered verifier set snapshot;
• independent from operator choice.

A selected verifier approves a commitment by signing the exact
state_commitment_hash and challenge-window context:

approval_signature = Sign(
  verifier_identity,
  state_commitment_hash,
  challenge_window_id
)

Before signing, the verifier is expected to check:

• the DA record is available;
• the delegated account and commit id are valid;
• the commitment extends the latest finalized account state;
• the ER execution can be replayed or otherwise verified;
• the resulting account state matches the submitted commitment;
• the delegation record permits the proposed finalization.

Non-selected verifier signatures do not count. Operator-supplied verifier lists
do not count unless they match the protocol-derived selection.

If the challenge window closes, no unresolved challenge exists, and the required
threshold of selected verifier signatures has been met, the commitment can be
finalized.

If the threshold is not met, the commitment must not finalize. The challenge
window is extended and the approval criteria are adjusted according to protocol
parameters.

If a challenge is raised, the commitment is blocked from finalization until the
challenge reaches a terminal outcome.

Challenge scope

A challenge targets an existing pending commitment. Pre-commit challenges are out
of scope for this version.

A challenge is bound to:

• one operator identity;
• one account public key;
• one commit id;
• one challenger identity;
• one pending state_commitment_hash;
• one salted challenge_hash.

The challenger must lock a fixed minimum stake when raising the challenge.

A challenge must be submitted during an active challenge window for the pending
commitment. Once accepted, the commitment cannot finalize until the challenge is
resolved or dismissed.

Challenger commitment

The challenger commits to the account state they believe is correct by
submitting a salted hash.

The hash must be domain-separated and bound to the complete challenge context:

challenge_hash = H(
  "magicblock.challenge.v1",
  state_commitment_hash,
  operator_identity,
  challenger_identity,
  account_pubkey,
  commit_id,
  lamports,
  owner,
  data_hash,
  salt
)

The revealed state uses the same canonical account state model as the operator
commitment:

• lamports;
• owner;
• data.

For large accounts, the revealed data may be provided through buffered
submission. The hash preimage must still bind to the full canonical data.

Lifecycle

flowchart TD
    A[Operator posts pending state commitment] --> B[Challenge window opens]
    B --> C[Random active verifiers are selected]
    C --> D[Selected verifiers check DA and execution]
    D --> E{Challenge raised?}
    E -->|No| F{Challenge window closed?}
    F -->|No| D
    F -->|Yes| G{Verifier signature threshold met?}
    G -->|Yes| H[Finalize committed state]
    G -->|No| I[Extend challenge window and adjust approval criteria]
    I --> C
    E -->|Yes| J[Block finalization and enter challenge path]
    J --> K[Operator opens or confirms full state]
    K --> L[Challenger reveals state and salt]
    L --> M{Challenge hash valid?}
    M -->|No| N[Challenger fully slashed]
    M -->|Yes| O{States match?}
    O -->|Yes| P[Challenge dismissed with challenger penalty]
    O -->|No| Q[Security council resolution]
    Q --> R{Who is correct?}
    R -->|Operator| S[Challenger fully slashed]
    R -->|Challenger| T[Operator fully slashed]
    T --> U[Challenger payout after 48h timelock]
    K --> V{Operator timeout?}
    V -->|Yes| Q

Loading

1. Post commitment

The operator posts a pending state commitment for one account at one commit id.

The transaction records:

• operator identity;
• challenged account public key;
• commit id;
• delegation record pointer;
• DA pointer;
• committed account state hash;
• challenge window parameters;
• verifier selection context;
• required verifier signature threshold.

The commitment is pending. It is not finalized at this point.

2. Verifier approval

Selected verifiers monitor pending commitments. If a selected verifier considers
the commitment valid, it signs the commitment.

A verifier signature means that the verifier approves the pending commitment and
is not raising a challenge for that commitment.

The Delegation Program counts only signatures from selected eligible verifiers.

3. Raise challenge

Any challenger with the required fixed minimum stake may raise a challenge
against a pending commitment for one account at one commit id.

The transaction records:

• operator identity;
• challenger identity;
• challenged account public key;
• challenged commit id;
• pending state_commitment_hash;
• salted challenge_hash;
• locked challenger stake.

The operation is permissionless, but economically protected by the required
stake and penalties defined below.

4. Operator response

If the pending commitment does not already expose the full account state onchain,
the operator must respond before the response timeout by opening or confirming
the full account state it claims is correct for the challenged account at the
challenged commit id.

Failure to respond before the timeout is treated as operator fault and moves the
challenge to resolution with operator non-response as evidence of fault.

5. Challenger reveal

After the operator response, the challenger reveals:

• the account state it originally committed to;
• the salt.

The program recomputes the challenge hash using the canonical challenge context.
If the recomputed hash does not match the original challenge_hash, the
challenger is at fault and is fully slashed.

If the hash matches, the revealed challenger state is compared with the
operator-submitted state.

6. Match path

If the revealed challenger state matches the operator-submitted state, the
challenge was unnecessary.

This is valid protocol behavior, but it is costly. The challenger is charged
20% of the locked challenge stake. The charged stake goes to the protocol.

The remaining challenger stake is unlocked. No operator stake is slashed, and no
account state is changed by the challenge.

The pending commitment may finalize only if the normal finalization conditions
are satisfied: challenge window closed, selected verifier threshold met, and no
other unresolved challenge exists.

7. Mismatch path

If the revealed challenger state does not match the operator-submitted state,
the challenge proves disagreement but does not by itself prove fault.

The challenge enters resolution. The account is not finalized to either state
until resolution completes.

Resolution

The first version uses a stake-weighted security council as a simple resolver.
This is the fallback path for challenged commitments only.

Council members vote on which state is correct:

• the operator-submitted state;
• the challenger-revealed state.

A resolution requires more than two thirds of council stake voting for one side,
subject to quorum and timeout parameters to be finalized before implementation.

This resolver is intentionally simple and social. It is acceptable only as an
initial implementation because the challenge mechanism is separated from the
resolution mechanism. Future versions should replace or augment this path with
objective replay on a zkSVM.

Outcomes

Outcome 1: happy path finalization

No challenge is raised, the challenge window closes, and enough randomly
selected active verifiers have signed the pending commitment.

Effects:

• the committed account state is finalized;
• no challenger stake is involved;
• no operator stake is slashed;
• verifier signatures are recorded as approval evidence.

Outcome 2: not enough verifier signatures

No challenge is raised, but the selected verifier threshold is not met before the
challenge window closes.

Effects:

• the account state is not finalized;
• the challenge window is extended;
• approval criteria are adjusted according to protocol parameters.

Outcome 3: state matches

The challenger commitment is valid, and the challenger-revealed state matches
the operator-submitted state.

Effects:

• challenger loses 20% of the locked challenge stake;
• charged stake goes to the protocol;
• remaining challenger stake is unlocked;
• operator is not slashed;
• account state is not changed by the challenge.

Outcome 4: state mismatches, operator is correct

The challenger commitment is valid, but the revealed state does not match the
operator-submitted state, and the security council resolves in favor of the
operator.

Effects:

• challenger is fully slashed;
• operator is not slashed;
• operator-submitted state becomes the resolved state for the challenged account
  and commit id.

Outcome 5: state mismatches, challenger is correct

The challenger commitment is valid, the revealed state does not match the
operator-submitted state, and the security council resolves in favor of the
challenger.

Effects:

• operator is fully slashed;
• challenger receives the operator's slashed stake;
• challenger payout is subject to a 48 hour timelock;
• challenger-revealed state becomes the resolved state for the challenged
  account and commit id.

The 48 hour timelock happens after council resolution. It is a payout delay, not
an appeal window.

Finalization

A challenge never finalizes account state at the point of reveal.

Account state is finalized only when one of the following is true:

• the happy path completes with a closed challenge window, enough selected
  verifier signatures, and no unresolved challenge;
• the match path completes and the normal finalization conditions are also met;
• council resolves in favor of the operator;
• council resolves in favor of the challenger;
• operator timeout is resolved.

This prevents a malicious challenger from forcing state finalization before
fault has been assigned.

The current CommitFinalize path can remain as an optimized path, but it must
be extended before being used in the challenge-enabled protocol. Specifically,
CommitFinalize must verify:

• the pending commitment exists for account_pubkey + commit_id;
• the challenge window has closed;
• there is no unresolved challenge;
• the selected verifier set was derived from protocol randomness;
• enough selected verifier signatures approve the exact commitment;
• the DA pointer and delegation record match the commitment context.

Security-council co-signing is not the happy-path Dynamic Fraud Proof condition
and should not be used as a substitute for randomly selected verifier approval.

Economic rules

• Posting a commitment requires a slashable operator bond.
• Raising a challenge requires locking a fixed minimum challenger stake.
• Verifier approvals count only from bonded, selected verifiers.
• An unnecessary but valid challenge charges 20% of the locked challenger stake
  to the protocol.
• Invalid reveals and incorrect challenges are fully slashed.
• Correct challengers receive the operator's slashed stake after a 48 hour
  timelock.
• If a verifier approves a commitment later resolved as invalid, verifier
  slashing should be supported before that verifier's approval is considered
  economically meaningful.

Security considerations

The state commitment hash and challenge hash must be domain-separated and bound
to the operator, challenger where applicable, account, commit id, DA pointer,
delegation record, and canonical state. Without this binding, commitments and
challenges could be replayed or reused across operators, accounts, or commits.

The protocol must define canonical serialization before implementation. Any
ambiguity in serialization can create slashable mismatches even when both sides
intended the same state.

Random verifier selection must be unpredictable before the commitment round and
verifiable during finalization. Operator-chosen signer sets are not sufficient.

Verifier signatures are only useful if the DA record is available and the
verifier can replay or verify the ER execution.

The initial council resolver is not objective consensus. Its security depends on
the council stake distribution and on council members independently running or
trusting validators capable of verifying the disputed state.

The challenge window should be bounded. Very old-slot challenges increase
archival and data-availability requirements.

Parameters to finalize

• fixed minimum challenger stake;
• fixed minimum operator bond;
• fixed minimum verifier bond;
• hash function;
• canonical byte serialization;
• missing-account representation;
• commit id and optional slot metadata encoding;
• DA pointer format;
• randomness source for verifier selection;
• verifier eligibility snapshot rules;
• initial challenge window;
• challenge-window extension schedule;
• selected verifier threshold;
• threshold adjustment schedule;
• maximum number of extensions;
• operator response timeout;
• challenger reveal timeout;
• council quorum;
• council voting timeout;
• exact handling of no-quorum council votes;
• verifier slashing conditions for incorrect approvals.

Open implementation work

The current implementation should evolve from admin whitelisting toward
permissionless bonded operator and verifier registration.

• introduce a slashable operator bond account;
• introduce a slashable verifier bond account;
• add pending commitment records keyed by account and commit id;
• include owner in the committed state model;
• store or derive verifier selection context per pending commitment;
• verify selected verifier signatures in CommitFinalize;
• implement challenge window extension when approval threshold is not met;
• add challenge records keyed by account and commit id;
• define DA pointer and replay inputs required for verification;
• extend finalization so it checks either happy-path verifier approval or
  completed dispute resolution before applying state.

[Dodecahedr0x]

A challenge is bound to:

• one validator identity;
• one account public key;
• one commit id, also referred to as a nonce in the current implementation;
• one challenger identity;
• one committed hash.

The hash is derived from these so it does not need to appear in this list right? Or is it a hash of the committed account's content?

---

The challenger commits to the account state they believe is correct by submitting a salted hash.

The purpose of the salt is not clear at this point: once a validator commits, there should never be multiple identical challenges.

---

A challenge may target either an existing validator commitment or a pre-commit
state assertion. In the existing-commit path, the challenge references the
pending commitment for account_pubkey + commit_id. In the pre-commit path, the
challenge references the expected account_pubkey + commit_id and forces the
validator to answer with the state it intends to commit or finalize.

Why would a challenger force a validator to answer with its state and take a 20% stake cut? I thought challenges were only between commits and finalization.

---

Failure to respond before the timeout is treated as a validator fault and moves
the challenge to resolution with validator non-response as evidence of fault.

There is no mention of potential parameters here. The whitepaper mentions a slot, which seems excessively short for a full slash.

---

The remaining challenger stake is unlocked. No validator stake is slashed, and
no account state is changed by the challenge.

Isn't the account auto-finalized in the match path?

---

Council members vote on which state is correct:

• the validator-submitted state;
• the challenger-revealed state.

Still unclear at this point what state this refers to, because hashes refer to the state of the account, but only the account state seems insufficient to properly resolve the conflict.

However, if the state here refers to a wider ledger state, passing it to the council would be expensive. Moreover, while sending an account can be done through mainnet, doing so for the ledger requires new methods, which introduce new constraints/vulnerabilities (e.g. NATS crypto integration, DA layers being slow, etc..)

---

The 48-hour time lock happens after council resolution. It is a payout delay,
not an appeal window.

What's the point of the delay? There is no appeal window, the council can take forever, so its decision should be final and the payout immediate.

---

Having a terminology section at the beginning could help clarify the different terms, some of which are a bit overloaded (e.g. state)

[GabrielePicco]

The hash is derived from these so it does not need to appear in this list right? Or is it a hash of the committed account's content?
It's a hash of the committed account's content?

The purpose of the salt is not clear at this point: once a validator commits, there should never be multiple identical challenges.

Prevents knowing upfront the data by grinding, as a commit-reveal schema

Why would a challenger force a validator to answer with its state and take a 20% stake cut? I thought challenges were only between commits and finalization.

It's better to catch a fraud as soon as possible. 20% is charged when the challenge is raised when it shouldn't, to prevent ddos

There is no mention of potential parameters here. The whitepaper mentions a slot, which seems excessively short for a full slash.

Agreed that 1 slot is excessive, we to run some experiments to find a good value

Isn't the account auto-finalized in the match path?

Correct, the challenge as no side effects

Still unclear at this point what state this refers to, because hashes refer to the state of the account, but only the account state seems insufficient to properly resolve the conflict.

However, if the state here refers to a wider ledger state, passing it to the council would be expensive. Moreover, while sending an account can be done through mainnet, doing so for the ledger requires new methods, which introduce new constraints/vulnerabilities (e.g. NATS crypto integration, DA layers being slow, etc..)

It should be possible to always restrict the conflict to one account on which parties disagree

What's the point of the delay? There is no appeal window, the council can take forever, so its decision should be final and the payout immediate.

Just safer in the first phase of the protocol, but agree that the payout could be immediate

[snawaz]

I tried to translate the MIMD into a concrete call flow to check whether I am interpreting the proposal
correctly. I am intentionally not repeating the full actor list, economic rules, or commitment format
from the proposal. This is only the extra structure I think is implied by the text, plus the places
where the proposal still seems ambiguous.

Note

Assumptions / Terms / Scopes

• Validator commitment: a DLP-visible hash/claim plus metadata. Creating it must not mutate the delegated account.
• Finalization: the later step that applies or accepts committed state after the challenge window, council
  condition, or dispute path allows it.
• Pre-commit challenges: challenges raised before a ValidatorCommitment exists. They are out of scope
  for V1; this LLD only covers challenges anchored to an existing DLP-visible ValidatorCommitment.
• Canonical account state: lamports + owner + data. executable is excluded because executable
  accounts are not delegatable. The missing-account representation is still undefined.
• SubmitValidatorCommitment is commitment-only. Current CommitFinalize-style behavior can run only
  after the commitment is no longer challengeable, or after a challenge resolves and approves the state.
• Existing CommitState / CommitStateFromBuffer are the closest current analogs for creating a pending
  commit artifact. Existing CommitFinalize is an optimized apply/finalize path, not SubmitValidatorCommitment.
• The challenge window starts when the delegation program stores the ValidatorCommitment. Normal
  finalization is blocked until that window expires without a challenge, or until any raised challenge
  reaches a terminal outcome.
• A challenge is anchored to a DLP-visible commitment artifact. Off-chain challenger detection is only
  evidence for deciding to challenge; it is not the protocol anchor.
• Resolver means the V1 security council mechanism. It is entered only when valid validator and challenger
  openings disagree, or when validator-fault handling routes the case there. The resolver's design is
  out of scope for this document.
• Keeper / anyone is a permissionless transaction submitter. It pings the delegation program to advance
  timeout or finalization transitions, and the delegation program verifies from on-chain state whether the
  transition is allowed.
• Low-level implementation details such as exact account types, PDA seeds, serialization layouts, and buffer
  formats are intentionally out of scope for this LLD unless they change the protocol flow.

Records I think are implied

• ValidatorBond: the slashable validator/operator stake, separate from the fee vault.
• ValidatorCommitment: one committed account update, keyed by validator, account, and commit id. Including
  the validator identity avoids ambiguity if more than one validator can commit state for the same account and
  commit id.
• ChallengeRecord: one active challenge against a validator commitment, including the challenge hash,
  locked stake, deadlines, and terminal outcome.
• StateBuffer: optional canonical buffer for large account data.
• ResolutionRecord: resolver state for mismatches or validator failures.

Important interpretation: validator response opens the original commitment

My read is that SubmitValidatorResponse should not be a new claim made after the challenge starts. It
should reveal the account state behind the original validator commitment, and the delegation program should verify:

H(validator_response_state) == stored_validator_commitment_hash

This avoids the case where a validator originally committed H(bad_state), then responds to the challenge
with correct_state, making the challenge look unnecessary.

Sequence as I understand it

sequenceDiagram
    autonumber
    participant V as Validator
    participant C as Challenger
    participant DP as Delegation program
    participant R as Resolver
    participant K as Keeper / anyone

    rect rgba(80, 160, 255, 0.12)
        V->>DP: SubmitValidatorCommitment<br/>validator, account, commit_id, validator_state_hash
        DP->>DP: Store commitment<br/>start challenge window
    end

    rect rgba(255, 190, 80, 0.16)
        C->>C: Detect divergence off-chain<br/>compute challenger state + salt<br/>compute challenge_hash
        C->>DP: RaiseChallenge<br/>validator, account, commit_id, challenge_hash, stake
        DP->>DP: Lock stake<br/>mark commitment disputed<br/>start validator response timeout
    end

    alt validator responds in time
        rect rgba(120, 220, 140, 0.14)
            V->>DP: SubmitValidatorResponse<br/>full state or canonical buffer reference
            DP->>DP: Verify response opens stored commitment hash
        end

        alt valid validator opening
            DP->>DP: Start challenger reveal timeout
            alt challenger reveals in time
                rect rgba(120, 220, 140, 0.14)
                    C->>DP: RevealChallengerState<br/>state, salt
                    DP->>DP: Verify reveal opens challenge_hash
                end

                alt invalid reveal
                    rect rgba(255, 90, 90, 0.16)
                        DP->>DP: Slash challenger
                    end
                else states match
                    rect rgba(120, 220, 140, 0.14)
                        DP->>DP: Charge 20% challenger stake to protocol<br/>clear dispute
                    end
                else states mismatch
                    rect rgba(255, 90, 90, 0.16)
                        DP->>DP: Create ResolutionRecord
                        R->>DP: Vote
                        K->>DP: FinalizeResolution
                        DP->>DP: Apply resolver outcome
                    end
                end
            else challenger reveal timeout
                rect rgba(255, 90, 90, 0.16)
                    K->>DP: ClaimChallengerRevealTimeout
                    DP->>DP: Penalize challenger<br/>release commitment if valid validator opening exists
                end
            end
        else invalid validator opening
            rect rgba(255, 90, 90, 0.16)
                DP->>DP: Validator-fault handling or resolver
            end
        end
    else validator timeout
        rect rgba(255, 90, 90, 0.16)
            K->>DP: ClaimValidatorResponseTimeout
            DP->>DP: Validator-fault handling or resolver
        end
    end

Loading

Commentary on the sequence

• Start from an account that is already delegated, has been modified on ER, and has a next commit_id / nonce
  for this account update.
• The validator first creates a DLP-visible commitment artifact. In this LLD, that artifact is called
  ValidatorCommitment and is bound to:

validator_identity + account_pubkey + commit_id

• A challenger does not challenge unanchored validator memory. The challenger independently computes the
  expected ER account state off-chain, then watches DLP program transactions or DLP-owned account changes for
  the validator's on-chain commitment for the same account and commit id.
• In the current implementation, the closest concrete artifacts are the commit_state_pda and
  commit_record_pda created by CommitState / CommitStateFromBuffer. The challenge-enabled protocol should
  either define a first-class ValidatorCommitment account or extend the commit record so it explicitly stores
  the committed hash and challenge/finality status.
• If the challenger disagrees with the validator commitment, it raises a challenge by locking stake and
  submitting challenge_hash, which is a salted commitment to the challenger state and full challenge context.
• The delegation program records the challenge, locks challenger stake, marks the validator commitment disputed,
  and blocks normal finalization for that commitment until the challenge reaches a terminal outcome.
• The validator response must reveal the state behind the original stored validator commitment. The delegation
  program must verify that the response opens the stored validator_state_hash; it must not accept a fresh state
  claim that differs from the original commitment.
• After a valid validator opening, the challenger reveals its state and salt. The delegation program recomputes
  challenge_hash. If the reveal does not open the original challenge hash, the challenger is fully slashed.
• If the challenger reveal is valid and both states match, the challenge was unnecessary but valid. The challenger
  loses 20% of the locked stake to the protocol, the remaining stake is unlocked, and the commitment is cleared
  for finalization.
• If the valid challenger state differs from the valid validator state, the protocol has proven disagreement but
  not fault. The delegation program creates a ResolutionRecord, and the resolver decides whether the validator
  state or challenger state is correct.
• Finalization is a later step. It can proceed only if no challenge exists, the challenge has been cleared, or the
  challenge has been resolved and the finalizing state matches the resolved state.

Messages I think are missing or need to be explicit

Message	Why it matters
RegisterValidator	Needed if validator participation moves to a permissionless slashable-bond model.
SubmitValidatorCommitment	Needed as the concrete object a challenge references.
SubmitValidatorResponse	Must explicitly open the original commitment, not submit a fresh answer.
ClaimValidatorResponseTimeout	Needed so validator non-response can be finalized by anyone.
ClaimChallengerRevealTimeout	Needed so challengers cannot lock commitments and disappear.
FinalizeResolution	Needed so council/resolver output actually transitions the challenge to terminal state.

Finalization rule I infer

CommitFinalize or any optimized finalization path should check:

• no unresolved challenge exists for the commitment;
• if disputed, the finalizing state matches the resolved state;
• required optimistic-finality or council co-signing conditions are satisfied.

The 20% penalty for a valid but unnecessary challenge goes to the protocol.

Questions / possible gaps

• If the validator misses the response timeout, does the delegation program immediately punish the validator,
  or does it send the case to the resolver first?
• What happens if the resolver does not get enough votes? The resolver design is out of scope here, but the LLD
  still needs to know whether the challenge remains blocked, times out, or reaches some fallback outcome.
• Can multiple challengers challenge the same validator commitment, or is only one active challenge allowed?
  This is out of scope for this LLD unless it changes the core challenge flow.

[Dodecahedr0x]

Note

Suggestion of a challenging mechanism

Raising a challenge

When a verifier detects invalid state (state divergence after replication, or invalid account data committed), it raises a challenge.
The goal of the challenge is not to determine who cheated, but whether the discrepancy really happened.
Fault attribution is managed by an external council.

We suppose both the verifier and the validator have the full ledger available locally. Their goal is to determine when in the ledger the discrepancy started, aka the first transaction when things started to diverge.
The pessimistic ledger window that is challenged is the one going from the latest approved (or first delegation) commit to the latest challenge.

Model

We can model the system as follows:

• All replicas are labeled $R_i$. By convention, the validator is $R_0$.
• Each replica $i$ maintains an ordered sequence $\mathbf{X_i} = { X_{i, j} }{j=1}^N$, where each $X{i, j} = \left( h_{i, j}, s_{i, j} \right )$. Here, $h_{i, j}$ is the hash of the $j$-th transaction in ledger $i$, and $s_{i, j}$ is the post-state hash computed after executing transaction $j$ on replica $i$. $X_{i,0}$ = (default hash, default hash).
• The challenge may be formulated as a function $C$ which, given two such sequences, returns the smallest index $k$ (or the corresponding transaction hash) where $s_{0, k} \ne s_{i, k}$, i.e., where the post-state hashes of the validator and the verifier first diverge. We can write the challenge function, when replica $i$ challenges the validator, as
  $
  C(\mathbf{X}0, \mathbf{X}i) = \min \left{ k \mid s{0, k} \ne s{i, k} \right}
  $

Practicality

To efficiently find the index $k$, the two replicas will engage in a dichotomic search over the ledger challenge window: they send their state hashes at $j = \frac{N}{2}$, if it matches, repeat for the upper interval, otherwise the lower one, until they find the exact index $j = k$. The complexity of this process is $O(d\log{N})$, with $N$ the largest number of items in a ledger and $d$ the Solana network delay.

State hash comparisons

For security reasons, this process should most likely happen directly on Solana. However, this drastically increases latency as both participants need to have their state hashes confirmed on mainnet before knowing which next interval to work on.

A way to speed up this process is to use the fact that multiple commitments can fit in a single solana transaction: the index $j$ fits in 8-bytes, plus 32 for the state hash, resulting in 20-30 commitments per transaction (increased with 4kb tx), noted $c$. By choosing a deterministic sampling, replicas can subdivide the ledger window in smaller windows, reducing the number of iterations needed.

Computing state hashes

Another issue is that computing the set $\mathbf{X_i}$ is needed to even start the challenging process but is expensive: replay the whole window and hash the state at each step.

Initiating the process

Thanks to the superblock architecture, replicas can use superblock boundaries as the bootstrapping elements that they will compare:

• If the window spans over at least $c$ superblocks, adjust the subdivisions to fall on $c - 1$ superblock boundaries before the fraud.
• If the window spans over less than $c$ superblocks, only post state hashes at each boundary.

In all cases, the challenger always include the transaction and state hashes that triggered the inconsistent state (which most likely contains the fraud).

The validator then has to compute the state hashes for every transaction in the current superblock, up to the challenge boundary.

This part is sequential (challenger sends, validator observes then responds).

An optimistic approach can be to precompute the state hashes for the latest superblock, which is likely where the fraud originated. This can be done in parallel to waiting for mainnet confirmation.

Iterating

After both participants sent their initial set of commitments, we can adopt a more parallel approach:

1. Based on the last posted commitments, iterate on the window that ends with lowest index state mismatch (subdivide that smaller window into $c$ and post each boundary state hash). Depending on the situation, the set of tx/state may already be available and the cost of computation can be skipped.
2. Replicas wait until they see the confirmed post for the current iteration before moving on to the next iteration.

Impact on the protocol

• Simple commitments (state of the ledger at a given index)
• Favors smaller superblocks to have more frequent state hash and reduce the amount of computation (upper bounded by the cost to run the computation on a full superblock)