Espresso 3b: TEE batcher (re-hosted)

[QuentinI]

Based on #448

Pulls in the Espresso/TEE batcher .

• In op-node: adds EspressoBatch type and marshaling logic for it. This is the datastructure that ends up posted to Espresso.
• In espresso package: adds the CLI flags and interfaces for the streamer.
• In the batcher: adds NSM helper in op-batcher/enclave/attestation.go and modifies the driver to add an Espresso path. Bulk of the changes is in espresso_-prefixed files.

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

[QuentinI]

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

Original transcript:

---

@chatgpt-codex-connector — 2026-05-26:

Guard ChainSigner initialization behind Espresso mode

initTxManager now always calls initChainSigner, but bs.TxManager is created as *txmgr.SimpleTxManager, which does not implement opcrypto.ChainSigner; this makes service startup fail with "tx manager does not implement ChainSigner" even when --espresso.enabled=false. Because this path runs during normal batcher boot, it becomes a universal startup regression rather than an Espresso-only failure.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

To use Codex here, create a Codex account and connect to github.

[QuentinI]

Mirrored from #447 (unresolved review thread) to keep tracking it here after the re-host. Original location: espresso/cli.go:200.

Original transcript:

---

@chatgpt-codex-connector — 2026-05-26:

Validate fallback-auth lead time outside Espresso-enabled block

FallbackAuthLeadTime is validated only when c.Enabled is true, but fallback mode (--espresso.enabled=false) still uses this field in isFallbackAuthRequired; a negative duration therefore bypasses validation and is later cast to uint64, producing a huge lead that can force premature/always-on fallback auth gating. This creates hard-to-diagnose behavior for fallback batchers with a mis-set duration flag.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

To use Codex here, create a Codex account and connect to github.

[QuentinI]

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

Original transcript:

---

@chatgpt-codex-connector — 2026-05-26:

Check configured signer address in active-batcher decision

isBatcherActive determines activity solely from activeIsEspresso vs EspressoEnabled, without verifying that this node’s Txmgr.From() matches the currently authorized batcher address for that mode. In fallback mode, a node with the wrong sender key will still consider itself active and keep attempting publishes that revert at BatchAuthenticator, causing avoidable failure loops and no progress if this is the only running batcher.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

To use Codex here, create a Codex account and connect to github.

[QuentinI]

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

Original transcript:

---

@jcortejoso — 2026-05-29:

Would be possible to include here daType and tx size?:

type txRef struct {
    id       txID
    isCancel bool
    isBlob   bool
    daType   DaType
    size     int
}

[piersy]

Hey @QuentinI, this appears to be unused

[lukeiannucci]

It should be used now in this commit
fbbcd18

I think its not needed, but without the gate we could burn funds and would be just getting reverts from the contract.

[piersy]

I think this breaks batcher startup entirely. initTxManager (op-batcher/batcher/service.go:389) always calls initChainSigner, which asserts bs.TxManager to opcrypto.ChainSigner. But bs.TxManager is always a *txmgr.SimpleTxManager, which has neither Sign nor SignTransaction, so the assertion always fails and every batcher start — espresso or not — errors with "tx manager does not implement ChainSigner". The driver tests miss it because they build BatchSubmitter directly and skip service init.

The only ChainSigner implementations here (clientSigner, privateKeySigner in op-service/crypto/espresso.go) aren't wired into production — their only caller is a test.

Fix: build a real ChainSigner instead of casting the tx manager, or at least gate initChainSigner behind cfg.Espresso.Enabled so non-espresso batchers still start.

[lukeiannucci]

i just added a flag for non espresso mode
700f549

[piersy]

throttlingLoop starts by default (LowerThreshold defaults to 3,200,000) and just ranges over unsafeBytesUpdated with no context select. The non-espresso path sends on that channel and closes it on exit, but the espresso loops never touch it.

Two consequences: DA throttling silently does nothing in TEE mode, and on shutdown throttlingLoop blocks forever on the never-closed channel, so the wg.Wait in StopBatchSubmitting (op-batcher/batcher/driver.go:298) never returns — admin_stopBatcher or SIGTERM hangs until SIGKILL.

Fix: feed and close unsafeBytesUpdated from the espresso path like the non-espresso one

[lukeiannucci]

This i may need you to take a close look:
abb7ee1

After every block loaded from the streamer I send it to the throttling loop now to check if it should throttle.

[piersy]

This looks like a data race on the streamer. reset runs in the queueing loop and calls clearState, which resets the streamer via resetEspressoStreamer (writes readPos). Meanwhile the loading loop calls Peek/Update/Next on the same streamer without holding channelMgrMutex, and BufferedEspressoStreamer has no internal locking. So the two goroutines touch readPos and the batches slice concurrently — -race will flag it.

Beyond the race, a reset landing mid-iteration rewinds readPos, so the loading loop re-peeks already-consumed batches, re-adds a duplicate block, and AddL2Block returns ErrReorg — which triggers another clearState, churning in a loop.

Fix: serialize streamer access. Either don't reset the streamer from the queueing loop (signal the loading loop to do it), or guard every streamer call in both loops with one mutex.

[lukeiannucci]

014f88d

I made the espressoBatchQueueingLoop requests the clearState as suggested.

[piersy]

The throttling loop is started here, before startEspressoLoops runs its fallible setup (registerBatcher, resolveTEEVerifierAddress). If startEspressoLoops returns an error, StartBatchSubmitting returns without unwinding, so this goroutine is left on the waitgroup. running also stays true, so admin_startBatcher won't restart, and StopBatchSubmitting's wg.Wait blocks on this leaked loop (it ranges over unsafeBytesUpdated, which the espresso path never closes — see the other comment), so stop deadlocks too. The batcher is wedged until a process restart.

The earlier error returns (waitForL2Genesis, waitNodeSync) don't have this problem because they happen before any goroutine is started, so StopBatchSubmitting's wg.Wait returns immediately and recovers cleanly.

Fix: start the throttling loop after the espresso/non-espresso loops instead of before them. The send to it is non-blocking (select with a default in sendToThrottlingLoop), so it doesn't need to be running first. Then an error return from startEspressoLoops leaves no goroutine on the waitgroup, matching the earlier returns and keeping the failure recoverable.

[lukeiannucci]

let me know:
62e97b8

[piersy]

ToBlock doesn't validate the batch, and that turns a malformed-but-signed batch into a livelock for every TEE batcher on the namespace.

The encode side (BlockToEspressoBatch) checks that the first tx is an L1-info deposit, but the decode side never re-checks it: UnmarshalEspressoTransaction only recovers the signer and RLP-decodes, and ToBlock just re-inserts b.L1InfoDeposit as txs[0] without checking IsDepositTx() or that the header matches the batch body. An authorized signer — which includes the non-TEE fallback batcher key, a hot key on an ordinary host — can post a batch that is validly signed but semantically malformed (first tx not a deposit, or L1-info that doesn't parse). It passes the signature check and the header-only peek.

In the loading loop this hits the wrong error path. When ToBlock fails, the loop calls Next() and continues — it skips the bad batch. When AddL2Block fails, it calls clearState + streamer Reset and breaks — it rewinds. Because ToBlock does no validation it succeeds on the malformed batch, so the failure only surfaces one step later in AddL2Block (via BlockToSingularBatch rejecting the non-deposit tx), which takes the reset path. Reset rewinds to the safe head without advancing past the batch, so the next tick re-peeks the same batch, ToBlock succeeds again, AddL2Block fails again, reset again — forever. The safe head never advances, and since the namespace is shared every TEE batcher consuming it is stuck the same way until someone intervenes.

This is exactly what the NOTE here already asks for — ToBlock should fail only on invalid batches, so a bad batch takes the skip path rather than the reset path. The implementation just doesn't do the checking.

Fix: validate in ToBlock (or UnmarshalEspressoTransaction) — reject the batch when !b.L1InfoDeposit.IsDepositTx(), when the L1-info data fails to parse, or when BatchHeader is inconsistent with the decoded SingularBatch (parent hash, number, timestamp). Then a malformed-but-signed batch fails in ToBlock and the loop steps over it instead of resetting onto it.

[lukeiannucci]

let me know what you think about this fix + tests
b531ec9