[lukeiannucci]

Espresso 4: e2e tests

Ports the Espresso end-to-end test suite into the monorepo as espresso/environment and runs it in CI on free GitHub runners. The tests exercise the full integration — batcher, streamer, derivation pipeline, BatchAuthenticator contract — against an in-memory mock Espresso dev node, so no docker or external espresso-dev-node is needed in CI or locally. Builds on #459 (TEE batcher).

What's included

• espresso/environment — the e2e suite: soft-confirmation integrity, forced transactions, batcher fallback/switching, L1 reorgs, batch-inbox authentication, stateless batcher, pipeline enhancement, the EspressoTime enforcement hardfork, dispute game.
• espresso/mock_client.go — in-memory mock Espresso client shared by the batcher and the tests, injected via the new WithEspressoClientOverride option (the only op-batcher change here; the streamer-v2 batcher itself lives in Espresso 3b: TEE batcher (re-hosted) #459).
• .github/workflows/espresso-e2e-tests.yaml — runs the suite as five parallel matrix groups (core, integrity, fallback, forced-reorg, dispute) with a forge-artifacts cache; contracts only, no cannon prestates needed. Triggers on espresso/**, op-batcher/**, op-challenger/**, op-e2e/**, op-node/**, packages/contracts-bedrock/**.
• op-deployer / op-chain-ops / op-e2e — Espresso deploy pipeline (BatchAuthenticator + mock TEE verifiers) and e2esys support for Espresso systems (fallback batcher on the SystemConfig batcher key, espresso batcher on a dedicated key at HD index 6).
• flake.nix — dev shell for running the suite locally.
• README_ESPRESSO.md + just go-tests-espresso-e2e — how to run the suite locally. The recipe mirrors the CI invocation (all three packages, -p 1, 45m timeout), takes an optional -run regexp, fails fast if contracts aren't built, and honours GOTESTSUM_FORMAT=standard-verbose (stream full output) and OP_TESTLOG_FILE_LOGGER_OUTDIR (one log file per test; the recipe creates the directory, which testlog itself does not).

What runs in CI

25 tests, all in espresso/environment, split across the five groups (as of a92fa2d):

core (8) — TestE2eDevnetWithEspressoSimpleTransactions, TestE2eDevnetWithEspressoAndAltDaSimpleTransactions, TestE2eDevnetWithoutEspressoSimpleTransaction, TestE2eDevnetWithoutAuthenticatingBatches, TestStatelessBatcher, TestAnsiEscapeCodeLineReader, TestEspressoDevNodeLogEntry, TestEspressoDeployedContractLogEntryReader

integrity (5) — TestSequencerFeedConsistency, TestSequencerFeedConsistencyWithAttackOnEspresso, TestDeterministicDerivationExecutionStateWithInvalidTransaction, TestValidEspressoTransactionCreation, TestConfirmationIntegrityWithReorgs

fallback (4) — TestBatcherSwitching, TestFallbackMechanismIntegrationTestChannelNotClosed, TestEspressoEnforcementHardfork, TestE2eDevnetWithEspressoDegradedLiveness

forced-reorg (7) — TestForcedTransactionWithEspressoLargeWindow, TestForcedTransactionWithEspressoSmallWindow, TestForcedTransactionWithoutEspressoLargeWindow, TestForcedTransactionWithoutEspressoSmallWindow, TestBatcherWaitForFinality, TestE2eDevnetWithL1Reorg, TestPipelineEnhancement

dispute (1) — TestOutputAlphabetGameWithEspresso_ChallengerWins. An output alphabet game: the trace comes from the in-process challenger, so it needs no cannon prestate and runs in ~90s.

Every filter matches a test and every test is matched by a filter (checked mechanically), so nothing is silently absent from CI.

Skipped tests (11)

Everything not runnable yet ships as a t.Skip stub with a TODO describing what unblocks it, so gaps show up as SKIP in CI:

• TestE2eDevnetWithInvalidAttestation, TestE2eDevnetWithUnattestedBatcherKey — need the SP1 attestation-verifier service, which the mock doesn't emulate. Not blocked on TEE hardware: the verifier is a plain Docker container (ghcr.io/espressosystems/attestation-verifier-zk, public), or can be faked in-process. The suite exercises the TEE auth flow (EIP-712 commitment, authenticateBatchInfo, event-based derivation auth) but not attestation verification itself — that's covered by the BatchAuthenticator.t.sol unit tests and the vendored espresso-tee-contracts repo.
• espresso/devnet-tests (8) and espresso/enclave-tests (1) — the reference repo's heavier devnet/real-TEE tier, stubbed so the eventual port is a drop-in. Its workflows (espresso-devnet-tests.yaml, espresso-devnet-tests-tee.yaml, ec2-devnet-test.yaml) are checked in but workflow_dispatch-only. The standard compose profile needs the devnet harness (devnet_tools.go, compose files) ported and a larger runner; only the TEE profile and the enclave test need Nitro-enclave EC2 runners and AWS secrets (each workflow's TODO header lists it). Until then, real-TEE coverage continues to run in the reference repo.

The test inventory was diffed function-by-function against the reference repo (celo-integration-rebase-17). Dropped without stubs: the Caff-node tests (the Caff node is no longer supported), TestEnforceMajorityRule (MajorityRule was deprecated in favor of SingleNode) and TestEspressoDockerDevNodeSmokeTest (the dockerized dev-node launcher was replaced by the in-memory mock).

Notes for reviewers

• The espresso batcher submits every frame as an ordered auth+batch pair via TxManager.SendPairAsync; test doubles that wrap txmgr.TxManager must override that method too (see TxManagerIntercept).
• During the enforcement grace window (EspressoTime → + BatchAuthEnforcementDelaySecs) the verifier authorizes batches by L1 sender only, so handing the chain to the TEE batcher inside that window requires rotating SystemConfig.batcherHash to its address (exercised by the hardfork test).
• StopBatchSubmitting force-kills only when the passed context expires, so tests that wedge the batcher on purpose stop it with a short-lived context.
• StartE2eDevnet closes the system when the caller's context is cancelled; that goroutine is tied to t.Cleanup so System.Close (which logs via t.Log) can never run after the test has returned — doing so panics the whole test binary, not one test.

🤖 Generated with Claude Code

[philippecamacho]

Great! Can we start adding the E2E tests?

[lukeiannucci]

Great! Can we start adding the E2E tests?

@philippecamacho

The code is in here, I need to ask celo about potentially running it in their CI. Not sure the cost / runners they have.

Update i am trying some of them on what should be free runners.

[philippecamacho]

Rebased on #459