Optimistic Re-execution Protocol

• 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 Optimistic TEE-Rollups (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):

$\xrightarrow{\text{fraud\_proof}}$4

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 $\xrightarrow{\text{start\_timer}(T_\text{chal})}$0, location of divergence $\xrightarrow{\text{start\_timer}(T_\text{chal})}$1, and proof fragment.
• Challenge window: After provisional finality, $\xrightarrow{\text{start\_timer}(T_\text{chal})}$2.
• 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 $\xrightarrow{\text{start\_timer}(T_\text{chal})}$3.

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 $\xrightarrow{\text{start\_timer}(T_\text{chal})}$4, and issues a hardware-signed DCAP quote $\xrightarrow{\text{start\_timer}(T_\text{chal})}$5 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 $\xrightarrow{\text{start\_timer}(T_\text{chal})}$6 is cryptographically valid,
  • thereby guaranteeing execution trace–hardware integrity (output $\xrightarrow{\text{start\_timer}(T_\text{chal})}$7 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 $\xrightarrow{\text{start\_timer}(T_\text{chal})}$8 (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 ($\xrightarrow{\text{start\_timer}(T_\text{chal})}$9).
• Pseudocode fragment:

$\xrightarrow{\text{fraud\_proof}}$5

• Amortized cost: $$\,\wedge\,\text{no\_challenge}\,\wedge\,\text{timer\_expires} \rightarrow$$0
• Detection probability: $$\,\wedge\,\text{no\_challenge}\,\wedge\,\text{timer\_expires} \rightarrow$$1

5. Performance, Robustness, and Security Analysis

• Throughput/cost: For $$\,\wedge\,\text{no\_challenge}\,\wedge\,\text{timer\_expires} \rightarrow$$2 queries, $$\,\wedge\,\text{no\_challenge}\,\wedge\,\text{timer\_expires} \rightarrow$$3 (where $$\,\wedge\,\text{no\_challenge}\,\wedge\,\text{timer\_expires} \rightarrow$$4 is linear in model size and calibrated by hardware).
• Latency:
  • Provisional finality: $$\,\wedge\,\text{no\_challenge}\,\wedge\,\text{timer\_expires} \rightarrow$$5
  • Hard finality: Challenge window, tunable; e.g., $$\,\wedge\,\text{no\_challenge}\,\wedge\,\text{timer\_expires} \rightarrow$$6 day
  • Amortized: $$\,\wedge\,\text{no\_challenge}\,\wedge\,\text{timer\_expires} \rightarrow$$7
• Byzantine-rational security: Adversary's expected profit is strictly negative as long as $$\,\wedge\,\text{no\_challenge}\,\wedge\,\text{timer\_expires} \rightarrow$$8 is close to one (either via $$\,\wedge\,\text{no\_challenge}\,\wedge\,\text{timer\_expires} \rightarrow$$9 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 $\xrightarrow{\text{fraud\_proof}}$0 after $\xrightarrow{\text{fraud\_proof}}$1. 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 $\xrightarrow{\text{fraud\_proof}}$2 throughput of centralized baselines, $\xrightarrow{\text{fraud\_proof}}$30.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.