Optimistic Re-execution Protocol

Updated 4 February 2026

Optimistic re-execution protocols are distributed mechanisms that execute operations speculatively and allow rollback or fraud-proof resolution in case of disputes.
They implement state-machine transitions with TEE attestation and interactive bisection to ensure liveness, safety, and adversarial robustness.
These protocols are applied in blockchain rollups, high-performance databases, and geo-replicated storage to achieve near-centralized throughput with minimal cost overhead.

An optimistic re-execution protocol is a class of distributed verification and concurrency control mechanism in which an untrusted party is permitted to execute operations or transactions speculatively (optimistically), under the assumption of correctness, but with a facility for subsequent challenge, fraud-proof, or rollback and repair in case of invalid behavior or disputes. This paradigm underpins major scalability architectures in blockchains (e.g., optimistic rollups with fraud-proof games), high-performance database concurrency, and geo-replicated storage, providing a tunable balance between throughput, latency, and integrity. In the state-of-the-art, such as the @@@@1@@@@ (OTR), optimistic re-execution protocols are formalized by state machines, explicit transition and finality logic, cryptographic attestations, and bisection-based dispute resolution mechanisms, and are analyzed for liveness, safety, and adversarial robustness (Chan et al., 23 Dec 2025).

1. Formal Workflow: State Machine, Transitions, and Protocol Logic

The optimistic re-execution protocol in OTR is specified as a state machine with the following states and transitions:

SUBMITTED: User request is encrypted and submitted, awaiting attestation.
PROVISIONAL: Trusted Execution Environment (TEE) provides an attestation, establishing provisional finality.
CHALLENGE: A dispute window opens for potential fraud proofs.
REEXECUTE: On fraud proof submission, a re-execution is triggered, typically realized via an on-chain or reference TEE.
FINALIZED: The result is finalized, either through no dispute or after dispute resolution.

Transitions:

SUBMITTED $\xrightarrow{\text{TEE\_ATTEST(q)}}$ PROVISIONAL
PROVISIONAL $\xrightarrow{\text{start\_timer}(T_\text{chal})}$ CHALLENGE
CHALLENGE $\,\wedge\,\text{no\_challenge}\,\wedge\,\text{timer\_expires} \rightarrow$ FINALIZED
CHALLENGE $\xrightarrow{\text{fraud\_proof}}$ REEXECUTE
REEXECUTE $\xrightarrow{\text{resolve\_bisection}}$ FINALIZED

Pseudocode (excerpt):

function submitQuery(q):
    τID ← newQueryID()
    publish (τID, encrypt_TEE(q))
    setState(τID, SUBMITTED)
    return τID

upon event TEE_Attest(τID, r, σ_TEE, MRENCLAVE):
    require state(τID) == SUBMITTED
    require Verify_Sig(σ_TEE, MRENCLAVE, H(q)∥H(r))
    setState(τID, PROVISIONAL)
    emit ProvisionalFinality(τID, r, σ_TEE)
    startTimer(τID, T_chal)

upon event FraudProofSubmitted(τID, proof):
    if state(τID) in {PROVISIONAL, CHALLENGE}:
        setState(τID, REEXECUTE)
        doInteractiveBisection(τID, proof)

Timing parameters:

$T_{\text{submission}}$ = submission time
$\Delta_{\text{challenge}}$ = dispute window
$T_{\text{finality}} = T_{\text{submission}} + \Delta_{\text{challenge}}$

2. Fraud-Proof and Dispute Resolution Mechanisms

The protocol incorporates an explicit fraud-proof workflow to provide computational integrity:

A FraudProof object includes the query id, input $q$ , claimed result $r_\text{claimed}$ , execution trace $D_\text{trace}$ , location of divergence $i_\text{divergent}$ , and proof fragment.
Challenge window: After provisional finality, $T_{\text{finality}} = T_{\text{submission}} + \Delta_{\text{challenge}}$ .
Upon dispute, interactive bisection is triggered to localize the precise divergent step.
On-chain cost per dispute is dominated by the TEE signature verification (approx. 40k gas) and the logarithmic cost of bisection $O(\log |D_\text{trace}|)$ .

3. Trusted Hardware Attestation and Proof of Efficient Attribution (PoEA)

OTR leverages NVIDIA H100 Confidential Computing TEEs to bind computation unforgeably to physical hardware via attestation:

Attestation flow: User encrypts request to TEE public key; TEE decrypts, computes result $r \leftarrow F_\theta(q)$ , and issues a hardware-signed DCAP quote $\sigma_\text{TEE}$ over the concatenated hashes of the input and output.
PoEA mechanism: The smart contract validates that
- The attestation quotes are from a valid MRENCLAVE for the given model, and
- The signature $\sigma_\text{TEE}$ is cryptographically valid,
- thereby guaranteeing execution trace–hardware integrity (output $r$ is bound to specific and authentic model weights and code).

4. Randomized Zero-Knowledge Spot-Checks

To counteract TEE side-channel and hardware-level attacks, OTR implements stochastic zero-knowledge spot-checks:

System parameter $\rho$ (e.g., 0.01) determines probabilistic sampling rate.
For each response batch, a VRF is used to pseudorandomly select elements for on-demand zero-knowledge proof verification ( $\pi_\text{zk}$ ).
Pseudocode fragment:

if r_check < ρ:
    i ← uniformRandomIndex(1…n)
    request π_zk for τ_i
    if VerifyZK(τ_i, π_zk) == false:
        Slash(S)
else:
    allow optimistic path, open T_chal

Amortized cost: $\text{Cost}_\text{TEE} + \rho \cdot \text{Cost}_\text{ZK}$
Detection probability: $P_\text{detect} = 1 - (1 - \rho)(1 - P_\text{fish})$

5. Performance, Robustness, and Security Analysis

Throughput/cost: For $n$ queries, $C_\text{query}(n) = C_\text{base} + \alpha n$ (where $\alpha$ is linear in model size and calibrated by hardware).
Latency:
- Provisional finality: $T_\text{TEE} + T_\text{sig} \lesssim 1s$
- Hard finality: Challenge window, tunable; e.g., $\lesssim 1$ day
- Amortized: $L_\text{avg} = T_\text{TEE} + \rho T_\text{ZK}$
Byzantine-rational security: Adversary's expected profit is strictly negative as long as $P_\text{detect}$ is close to one (either via $\rho$ or via active external "Fishermen" detection).

6. Liveness, Safety, and Correctness Guarantees

Safety theorem: No two conflicting “Finality” events can be issued for the same $\tau_\text{ID}$ after $T_{\text{submission}} + \Delta_{\text{challenge}}$ . This is enforced by hardware non-malleable signatures, deterministic bisection, and smart-contract single-finalization rules.
Liveness lemma: Every valid request from an honest user always reaches FINALIZED state by the configured finality deadline, regardless of challenge activity.
Proofs rely on the deterministic progression and resolution of state transitions and on the cryptographic binding of all outputs to TEE attestation traces.

7. Sequence Diagrams and Protocol Visualization

The protocol execution is captured by the following ASCII sequence charts:

Optimistic (happy-path):

U Sequencer/Host TEE DA Layer Verifier |--submit(q)----->| | | | |--load q-->| | | |--compute r-->| | | |--σ_TEE------>| |<--provisional r-| | | | |--publish τ|--data avail->|notify watch | | | | |<--no fraud--|timer expires | |<--final---| | |

Dispute-path (fraud-proof):

U Sequencer DA Layer Fisherman On-chain |--submit(q)---->| | | | | |--publish τ--| | | | |--detect------>| | | |--submit proof->| | | |<-start bisection-| | | |--stepwise op-->| | | |<--on-chain exec-| | |<--slash if bad---------------| | | |--finalize fork->|

These charts clarify the speculative-first, revert-on-dispute workflow and explicit slashing/incentive mechanisms.

8. Context and Significance

The optimistic re-execution protocol unifies the benefits of fast provisional processing, TEE hardware guarantees, and accountability through on-demand, data-minimal fraud proofs. The OTR realization achieves $\sim 99\%$ throughput of centralized baselines, $<$ 0.07 USD per query cost overhead, strict Byzantine fault tolerance, and robust operation even with active hardware vulnerabilities, making it directly applicable to decentralized AI inference markets where traditional cryptographic proofs (e.g., ZKML) are infeasible for billion-parameter models (Chan et al., 23 Dec 2025).

The architectural pattern is generalizable to other contexts—optimistic state-machine replication (Marandi et al., 2014), blockchain concurrency control (Pang et al., 2019), and database transaction scheduling (Dashti et al., 2016)—but OTR augments classical rollback/fraud-proof models with TEE attestation and zero-knowledge escalation to balance latency, cost, and integrity in adversarial decentralized settings.