# Fluent Bridge and Rollup Verification: A Multi-Stage Security Architecture


## Abstract

Fluent is an L2 rollup that targets *blended execution*: a single economic and settlement domain that can host multiple execution environments over time. In practice, this means users can interact with heterogeneous virtual machine ecosystems while retaining one shared state and one settlement path to Ethereum. The core challenge is therefore not only throughput, but how to preserve strict state-transition integrity under heterogeneous execution assumptions.

This article explains Fluent’s verification pipeline as implemented in the smart-contract architecture: batch commitments, blob data availability, trusted-execution preconfirmation, and challenge-driven zero-knowledge (ZK) adjudication. The design is neither a pure optimistic rollup nor a pure validity rollup; it is a staged model where fast-path trust minimization and slow-path cryptographic fault resolution coexist.

## 1. Architectural Premise: Shared State, Multi-Execution Roadmap

Fluent’s rollup contracts encode the system as a sequential batch machine whose state is represented by explicit lifecycle records. The `BatchRecord` model stores a batch root, expected blob count, number of blocks, continuity hash (`toBlockHash`), and snapshot timing windows for each verification phase. This is critical: verification parameters are frozen per batch at commit time, preventing retroactive governance edits from changing the security conditions of in-flight batches.

At protocol level, this enables an execution-agnostic settlement surface. Fluent’s execution roadmap explicitly targets EVM and WASM, with SVM support planned later. Even as execution environments evolve, the rollup verifies *commitments over block headers and data roots* rather than VM-specific traces at commitment time. VM heterogeneity is therefore absorbed into the block/header format and proof interfaces, while settlement finality remains uniform.

## 2. Rollup Verification Families in Context

### 2.1 Optimistic Rollup (canonical model)

In a classical optimistic rollup, state transitions are accepted optimistically and become final unless challenged within a dispute window. Security is social-cryptoeconomic: anyone with standing can challenge, and a challenger/prover game determines correctness. Latency is dominated by challenge windows.

In Fluent, this model appears in the challenge lifecycle and delayed finalization path:
- batches enter challengeable states (`Submitted`, `Preconfirmed`, then potentially `Challenged`),
- challengers lock deposits to open disputes,
- provers resolve disputes,
- unresolved disputes can move the system into a corruption halt condition.

### 2.2 Full ZK Rollup (canonical model)

A full validity rollup requires a succinct proof for each state transition unit before acceptance/finality. Security is purely cryptographic at the transition level, with weaker reliance on economic dispute games. The trade-off is proving cost/latency and prover decentralization requirements.

Fluent does not require immediate full-batch validity proof at submission time; however, it does embed SP1-based proof verification for challenge resolution and supports proof-gated finalization routes where block commitments must be cryptographically proven.

### 2.3 Optimistic-ZK Hybrid (Fluent model)

Fluent’s implemented path is best described as *optimistic execution with ZK adjudication*:
1. fast commitment and DA publication,
2. fast TEE preconfirmation for operational responsiveness,
3. permissionless challenge initiation with economic bonding,
4. SP1-backed proof resolution for disputed claims,
5. finalization either after delay or with full proof coverage.

This structure decouples user-perceived latency from worst-case cryptographic latency while preserving a cryptographic court of final appeal.

## 3. Multi-Stage Verification Pipeline


## 3.1 Stage A — Batch Commitment

The sequencer commits a batch via `commitBatch` with:
- batch root,
- block-span continuity (`fromBlockHash` → `toBlockHash`),
- declared block count,
- expected blob count,
- deposit-consumption metadata.

The contract enforces continuity across batches through previous `toBlockHash` linkage, records `acceptedAtBlock`, snapshots all timing windows, and anchors the bridge sent-message cursor (`sentMessageCursorStart`) for deterministic rewind on emergency revert. This makes commitment not only a data promise, but a deterministic rollback boundary.

## 3.2 Stage B — Blob Publication and DA Binding

`submitBlobs` records EIP-4844 versioned blob hashes using transaction blobhash opcodes. Blobs can be posted incrementally, but total submitted hashes must equal the committed `expectedBlobs` value; only then does the batch transition from `Committed` to `Submitted`.

This creates a strong DA binding: the eventual preconfirmation/proof logic is parameterized by the exact blob hash vector stored on-chain. In other words, execution claims are not accepted in isolation; they are tied to the data-availability commitment set. Even though compression/serialization happens off-chain, on-chain adjudication is keyed to immutable blob hashes.

## 3.3 Stage C — TEE Preconfirmation

Preconfirmation is executed through `preconfirmBatch`, where a whitelisted Nitro verifier validates a signature over `(chain id, verifier contract, batch root, blob hash list)`. The corresponding Nitro verifier contract introduces a two-phase trust filter:

1. **Attestation phase**: SP1 proof verification of enclave-attestation public outputs (including enclave-derived pubkey and attestation timestamp), with a bounded freshness window.
2. **Batch-signature phase**: only attested pubkeys can authorize batch signatures.

Operationally, this means Fluent does not accept an arbitrary attester key. A key must first pass attestation verification and be registered as valid, and can later be revoked by governance. This creates a measurable and rotatable trust surface for TEE-assisted liveness.

## 3.3.1 PCR0-Bound Key Verification via SP1

A critical detail is how the enclave signing key is bound to an expected enclave image measurement (PCR0). In Fluent’s model, the attestation pipeline does not simply trust a submitted signer address. Instead, the attestation proof path verifies a statement whose public outputs include the enclave-derived pubkey and attestation timestamp, and the resulting key is admitted only after SP1 proof verification against the configured attestation program key.

Conceptually, this acts as a handshake:
- an enclave session generates or presents a signing identity,
- attestation evidence binds that identity to the expected enclave measurement context,
- SP1 verification validates the attestation statement on-chain,
- only then is the pubkey accepted for batch-signature checks.

If the enclave image is modified outside the expected measurement assumptions, the attestation proof path should fail to validate under the configured verification key, and the corresponding signer should not be admitted. This is the protocol-level mechanism that grounds preconfirmation signatures in a measured enclave context rather than in an arbitrary off-chain key registration.

## 3.4 Stage D — Challenge and ZK Resolution

Fluent exposes two dispute objects:
- **batch-root challenge** (`challengeBatchRoot`), and
- **block challenge** (`challengeBlock`).

Both require exact challenger deposits and enforce challenge-window deadlines derived from per-batch snapshots. A challenged batch transitions to `Challenged`. For block-level disputes, commitments are verified against the committed batch Merkle root; for batch-root disputes, linkage to the previous batch tail block is validated.

At the present stage, challenge initiation is role-gated (trusted operational participation), not fully permissionless. This should be interpreted as a temporary trust configuration. The target end-state is trustless challenge access where any qualified participant can trigger dispute resolution under the same proof rules.

Resolution uses proof-backed validation:
- `resolveBlockChallenge` verifies the SP1 proof against the challenged block/header and batch blob hash context,
- `resolveBatchRootChallenge` verifies block-header chain consistency and recomputed batch root agreement.

Economic flows are explicit: challenger deposits are transferred to successful provers upon resolution; in emergency revert paths, challengers can be refunded with configured incentive fees.

## 3.5 Stage E — Finalization Modes

Fluent supports two finalization routes:

1. **Delay-based finalization** (`finalizeBatches`): batches finalize sequentially after preconfirmation and elapsed `finalizationDelay`.
2. **Proof-gated acceleration** (`finalizeWithProofs`): a batch may finalize when all block commitments in the batch have already been proven.

This bifurcation is the essence of optimistic-ZK composition: normal operation is throughput-oriented, while adversarial operation is proof-oriented.

## 4. Corruption Detection and Safety Halt

A notable mechanism in Fluent is computed corruption state (`_rollupCorrupted`) as a first-class safety gate. The rollup halts state-changing progress if either:
- bridge deposit liveness indicates oldest unconsumed message expiration, or
- the oldest non-finalized batch exceeds its relevant phase deadline (blob submission, preconfirmation, or challenge resolution).

When corrupted, privileged emergency flow can revert non-finalized batches (`revertBatches`), rewind bridge consumption cursor, clean challenge/proof state, and re-open safe progress from a deterministic index. This design favors safety over liveness under uncertainty.

## 5. Trust, Decentralization, and the “No Single Override” Claim

The practical claim “no centralized override over STF” should be interpreted with precision.

Fluent reduces unilateral override risk by combining:
- immutable batch/data commitments,
- challenge windows with bonded adversarial participation,
- cryptographic proof verification for disputed transitions,
- explicit role separation (`SEQUENCER`, `PRECONFIRMATION`, `CHALLENGER`, `PROVER`, `EMERGENCY`, admin).

However, as in all production rollups, there remains governance and role-based trust in upgrader/admin controls and operational actors. The correct framing is not “zero trust,” but *structured, compartmentalized trust with cryptographic fault containment*.

## 6. Economic Implications

The pipeline is designed to exploit low-cost DA (EIP-4844 blobs) while preserving dispute-grade verification. In steady state, this drives low marginal transaction cost because expensive proof generation is shifted to adversarial or accelerated paths rather than required for every block upfront.

From a systems perspective, Fluent aims for a Pareto surface:
- optimistic throughput and UX latency in normal operation,
- cryptographic recoverability and challenge enforceability under fault,
- deterministic rollback guarantees when safety invariants break.

## Conclusion

Fluent’s verification architecture is best understood as a staged security protocol rather than a monolithic rollup category. Batch commitments and blob hashes establish data and ordering commitments; Nitro-based preconfirmation provides rapid execution attestations; SP1-backed challenge resolution enforces correctness in disputed states; and dual finalization paths allow the protocol to trade latency for assurance as conditions demand.

For users, the result is a bridge-and-rollup system that behaves fast under honest operation and remains auditable under adversarial operation. For protocol engineers, the system provides a concrete template for composing TEE liveness with ZK correctness without collapsing into either pure trust or pure proving bottlenecks.