Espresso 3a: Fallback batcher (re-hosted)

[QuentinI]

Relatively small change based on #445 - makes fallback batcher authenticate its transactions.

This is #448, re-hosted from an in-repo branch (now properly stacked).

[QuentinI]

Mirrored from #448 (unresolved review thread) to keep tracking it here after the re-host. Original location: op-batcher/flags/flags.go:172.

Original transcript:

---

@palango — 2026-06-02:

This is a nice idea, but we need to see how to set this value.

I think we either set this to something big and safe (1-2h) and accept that we're sending a couple of unused tx, or remove it at all and shutdown the batcher before the switch (causing more work for devops).

[QuentinI]

@palango technically it's not necessary at all. If the scenario it tries to prevent still happens, the batcher will just detect it here:

optimism/op-batcher/batcher/sync_actions.go

Line 159 in 9b2017e

m.Warn("sequencer did not make expected progress",

This will cause at most several minutes of delay before it re-submits, now through the authenticated path. So there shouldn't be any need to shut the batcher down in any case.

[QuentinI]

Mirrored from #448 (unresolved review thread) to keep tracking it here after the re-host. Original location: op-batcher/batcher/fallback_auth.go:42.

Original transcript:

---

@palango — 2026-06-02:

Reverted auth tx can be reported as success. sendTxWithFallbackAuth checks only err after l.Txmgr.Send and never checks verificationReceipt.Status in op-batcher/batcher/fallback_auth.go:85. txmgr.Send returns receipt, nil on receipt arrival in op-service/txmgr/txmgr.go:743, and derivation ignores failed auth receipts in op-node/rollup/derive/ batch_authenticator.go:85.

[QuentinI]

Fixed as part of the rework in 6f42f54

[QuentinI]

Mirrored from #448 (unresolved review thread) to keep tracking it here after the re-host. Original location: op-batcher/batcher/espresso_driver.go:67.

Original transcript:

---

@palango — 2026-06-02:

The normal batch submission path sends every batch tx through txQueue.Send:

op-batcher/batcher/driver.go:1061

That queue is created with MaxPendingTransactions:

op-batcher/batcher/driver.go:515

and txmgr.Queue.Send explicitly assigns nonces synchronously so transactions
confirm in the order they are sent. This is important for Holocene, where
frames for a channel must arrive in order.

The fallback-auth path bypasses that queue. Once fallback auth is required,
dispatchAuthenticatedSendTx starts a goroutine in authGroup:

op-batcher/batcher/espresso_driver.go:65

and that goroutine calls l.Txmgr.Send directly for both the auth tx and the
batch inbox tx:

op-batcher/batcher/fallback_auth.go:85
op-batcher/batcher/fallback_auth.go:95

Txmgr.Send is concurrency-safe, but it only preserves the order in which
callers actually reach nonce assignment. With up to fallbackAuthGroupLimit = 128 goroutines racing, that order is no longer the publishing loop’s frame
order. As a result, batch inbox txs from the same channel can receive nonces
in a different order than the channel manager emitted them, and L1 inclusion
order follows those nonces.

That can violate Holocene strict frame ordering and cause derivation to drop
later/non-contiguous frames.

This is also a regression from the default config, where max-pending-tx
defaults to 1; operators who configured one-at- a-time submission no longer
get that behavior for fallback-authenticated batches.

The fix should preserve the original batch order across the whole auth+inbox
pair. Simply queueing inbox txs after concurrent auth confirmation is not
sufficient, because auth confirmations can complete out of order. The
fallback-auth path should either be serialized, or use an ordered mechanism
that keeps the original frame order while still ensuring each inbox tx is
posted only after its matching auth tx succeeds.

[QuentinI]

This was a serious oversight.
Reworked in 6f42f54: queueing is serialized, the goroutine is spawned only to convert the authentication and batch submission receipt pair to a single receipt indicating transaction status. This should both respect the number of in-flight transactions allowed and preserve Holocene ordering.
Added some tests for this behaviour as well.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 49c4321cf1

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Serialize blob batches behind the auth transaction

When blob DA is used with --max-pending-tx set above the default 1 (or 0 for unlimited), this immediately submits a non-blob authenticateBatchInfo tx and then the blob batch tx from the same sender while the auth tx is still pending. The txmgr interface documents that callers mixing Blob and non-Blob transactions must handle ErrAlreadyReserved (op-service/txmgr/txmgr.go:81-83), so this path can repeatedly reject/requeue fallback-auth blob batches instead of posting them. The batch send should wait until the auth tx is mined, or otherwise avoid having both tx types pending from the same account.

Useful? React with 👍 / 👎.

[jcortejoso]

It seems to me that op-node loopback window includes differences of [0, loopbackWindow] blocks, while the batcher includes [0, loopbackWindow - 1] (so a block delta of exactly loopbackWindow would be true here). Is this expected?

[palango]

Inline findings M1–M4 from a multi-persona review of the fallback-auth path. All are MEDIUM (no externally exploitable issue found; the crypto binding is sound). Separately there is one HIGH (H1): the batcher never reads the contract's activeIsEspresso flag, so if the fallback batcher runs while it's still true (the default deploy state) every authenticateBatchInfo reverts → infinite retry → silent safe-head stall + gas bleed. Happy to expand on H1 and the test gaps in the PR thread.

[palango]

M1 — Lookback-window off-by-one (batcher is one block stricter than the verifier).

The verifier accepts an auth event at distance [0, 100] inclusive (101 blocks): CollectAuthenticatedBatches starts currentBlock := ref (distance 0), processes the block, then breaks on ref.Number - currentBlock.Number >= BatchAuthLookbackWindow — so the block at distance 100 is processed before the break (op-node/rollup/derive/batch_authenticator.go:176).

This check rejects distance >= 100, i.e. it re-queues at exactly distance 100 even though the verifier would accept it. The direction is safe (stricter → unnecessary resubmission, never a silent drop), but the two checks should agree. Either use distance.Cmp(lookbackWindow) > 0 to match the verifier, or document the deliberate 1-block safety margin. The op-node/rollup/derive/params.go:24-27 comment is also imprecise about the inclusive 101-block reality.

[palango]

M2 — max-pending-tx defaults to 1, and this cap-1 buffering is load-bearing.

With MaxPendingTransactions = 1 (the default, op-batcher/flags/flags.go:66), the second queue.Send (line 97) blocks in errgroup.Go until the auth tx mines — so batch submission stalls for a full auth-confirmation latency on every pair, and the batch tx isn't even crafted until the auth tx mines (~doubles per-batch latency).

It avoids deadlock only because these channels are buffered cap 1: the auth handler can write its receipt with no reader present (the watcher goroutine isn't started until after both Sends return, line 99). The comment should state that the buffering is what prevents the deadlock at the queue limit — switching these to unbuffered would hard-deadlock at the default config. Recommend documenting that MaxPendingTransactions >= 2 is required (or auto-bumping it) when fallback auth is active. This serialization is also untested — the fakeTxSender in the unit tests delivers receipts inline and doesn't model the blocking second Send.

[palango]

M3 — Nonce-gap hazard when the auth send fails asynchronously.

These two Sends craft consecutive nonces synchronously (auth = N, batch = N+1). If the auth tx is crafted but its async sendTx later fails, txmgr calls resetNonce() (op-service/txmgr/txmgr.go:372) while the batch tx at nonce N+1 is already in flight — leaving a permanent nonce gap that wedges the sender until the cancel/gap-fill path runs.

This is the same class as the upstream single-tx path, but amplified here because this path deliberately fires two ordered txs and a failure/revert on the first is now an expected case (e.g. the activeIsEspresso-still-true scenario). Worth a targeted integration test against the real txmgr.Queue; consider gating the batch Send on auth success rather than firing both unconditionally.

[palango]

M4 — FallbackAuthLeadTime is unvalidated; negative or zero is unsafe.

CLIConfig.Check() (op-batcher/batcher/config.go) never validates this flag. A negative duration makes uint64(... / time.Second) wrap to a huge value, so tip.Time + leadSec overflows and the gate misfires. A value of 0 removes the safety margin entirely and reintroduces the boundary-window silent drop the lead time exists to prevent: a tx decided pre-fork that lands in a post-fork block makes the verifier require a BatchInfoAuthenticated event the batcher never sent → batch silently dropped.

Recommend validating in Check(): reject negative, and reject (or at least warn) on 0; document that the lead time must exceed the worst-case L1 inclusion delay.