@aztec/sequencer-client 0.0.0-test.1 → 0.0.1-commit.017a351

package/src/sequencer/README.md

@@ -0,0 +1,243 @@
+# Sequencer Timing Model
+
+This document covers how the sequencer schedules its work within a slot. See the [package README](../../README.md) for the high-level architecture; this one focuses on the timing math and the state-machine deadlines.
+
+The model described here is for **proposer pipelining**, the only mode the production sequencer runs in (the proposer always builds for `slot + 1`). The deterministic single-sequencer `AutomineSequencer` used in some e2e tests publishes synchronously in-slot and does not use this timing model.
+
+## Overview
+
+Block production runs on three nested clocks:
+
+- A **slot** is a fixed window (e.g. 72 s) during which one elected proposer is allowed to build.
+- A slot contains several equal-length **sub-slots** (e.g. 8 s). Each sub-slot owns the budget for one L2 block and has a deadline fixed relative to the slot start.
+- All blocks built within one slot make up one **checkpoint**, which is what eventually goes on L1.
+
+Under pipelining, the proposer for slot `N` does its building inside slot `N - 1` ("build slot"). Slot `N` ("target slot") is only used to mine the L1 transaction. This shifts work like this:
+
+| Phase                          | When           |
+| ------------------------------ | -------------- |
+| Initialization                 | slot `N - 1`   |
+| Block building                 | slot `N - 1`   |
+| Checkpoint proposal broadcast  | slot `N - 1`   |
+| Last-block re-execution        | slot `N - 1`   |
+| Attestation collection         | slot `N - 1`   |
+| L1 submission                  | slot `N`       |
+
+The wall-clock slot the sequencer is reasoning about ("build slot") and the slot the checkpoint commits to ("target slot") are always `N - 1` and `N` respectively.
+
+## Sub-slots
+
+Each sub-slot has a fixed start time and a fixed deadline, both relative to the slot start:
+
+```
+subSlotStart[k]    = initializationOffset + (k - 1) * blockDuration
+subSlotDeadline[k] = initializationOffset + k * blockDuration
+```
+
+with `k = 1, 2, ..., maxNumberOfBlocks`. Deadlines do **not** shift based on when the previous block finished. If a block finishes early, the sequencer waits for the next sub-slot to begin (so validators see a regular cadence). If it finishes late, the next block has correspondingly less time.
+
+`canStartNextBlock(secondsIntoSlot)` walks the sub-slot list and returns the first one with at least `minExecutionTime` left before its deadline. Sub-slots that no longer have enough headroom are skipped entirely.
+
+### Number of sub-slots
+
+The maximum number of buildable blocks per slot is:
+
+```
+timeReservedAtEnd      = checkpointAssembleTime
+                       + 2 * p2pPropagationTime    // proposal out + attestations back
+                       + blockDuration             // last-block re-execution
+
+timeAvailableForBlocks = aztecSlotDuration
+                       - checkpointInitializationTime
+                       - timeReservedAtEnd
+
+maxNumberOfBlocks      = floor(timeAvailableForBlocks / blockDuration)
+```
+
+The reservation at the end of the slot is sized so that, on the happy path, attestations are in hand by the time the target slot starts. The enforced `COLLECTING_ATTESTATIONS` and `PUBLISHING_CHECKPOINT` deadlines are softer (see the deadline table below) and let a late attestation spill into the target slot. L1 publishing is **not** included in `timeReservedAtEnd` — that is paid for by the target slot.
+
+### Cooldown after the last sub-slot
+
+All `maxNumberOfBlocks` sub-slots build a block. The cooldown lives in the `timeReservedAtEnd` window that follows the last sub-slot:
+
+- 1 × `checkpointAssembleTime` to assemble and sign the checkpoint,
+- 1 × `p2pPropagationTime` for the `CheckpointProposal` to reach the committee,
+- 1 × `blockDuration` for the committee to re-execute the last block,
+- 1 × `p2pPropagationTime` for attestations to come back.
+
+These four windows total `checkpointAssembleTime + blockDuration + 2 * p2pPropagationTime`, exactly the `timeReservedAtEnd` formula above. The block built in the last sub-slot is *not* broadcast as a regular `BlockProposal`; the proposer holds it as `blockPendingBroadcast` so it travels bundled inside the `CheckpointProposal`.
+
+## Timing constants
+
+These constants come from `@aztec/stdlib/timetable` (see `stdlib/src/timetable/index.ts`). Some are fixed across the network, some are inputs from configuration.
+
+| Constant                          | Source                                  | Typical value | Purpose                                              |
+| --------------------------------- | --------------------------------------- | ------------- | ---------------------------------------------------- |
+| `aztecSlotDuration`               | L1 rollup contract                      | 72 s          | Length of one Aztec slot.                            |
+| `ethereumSlotDuration`            | L1 rollup contract                      | 12 s          | Length of one Ethereum slot.                         |
+| `blockDuration`                   | `blockDurationMs` config                | 6–8 s         | Sub-slot length.                                     |
+| `checkpointInitializationTime`    | constant (`CHECKPOINT_INITIALIZATION_TIME`) | 1 s       | Estimated sync + proposer check time.                |
+| `checkpointAssembleTime`          | constant (`CHECKPOINT_ASSEMBLE_TIME`)   | 1 s           | Time to assemble and sign the checkpoint after the last block. |
+| `p2pPropagationTime`              | `attestationPropagationTime` config     | 2 s           | One-way p2p estimate (proposals, attestations).      |
+| `l1PublishingTime`                | `l1PublishingTime` config               | 12 s          | Time reserved for the L1 tx to land. Used by the target slot, not the build slot. |
+| `minExecutionTime`                | constant (`MIN_EXECUTION_TIME`)         | 2 s           | Minimum headroom to start a block.                   |
+| `initializationOffset`            | `=checkpointInitializationTime`         | 1 s           | Where sub-slot 1 starts.                             |
+
+## Deadlines
+
+`SequencerTimetable.getMaxAllowedTime(state)` returns the latest second-into-slot a given state is allowed to be entered. `assertTimeLeft()` throws `SequencerTooSlowError` if the slot has already advanced past that deadline. Sub-slot scheduling is measured against the build slot (`slotNow`); state assertions, however, are measured against whichever slot `setState` was called with — for the publishing path that is the target slot, which is why the publishing deadline is allowed to exceed `aztecSlotDuration`.
+
+| State                       | Max allowed time (seconds into build slot)                                  |
+| --------------------------- | --------------------------------------------------------------------------- |
+| `PROPOSER_CHECK`            | `initializeDeadline = aztecSlotDuration - (checkpointInitializationTime + 2*minExecutionTime)` |
+| `INITIALIZING_CHECKPOINT`   | same as `PROPOSER_CHECK`                                                    |
+| `WAITING_FOR_TXS`           | `initializeDeadline + checkpointInitializationTime`                         |
+| `CREATING_BLOCK`            | same as `WAITING_FOR_TXS`                                                   |
+| `WAITING_UNTIL_NEXT_BLOCK`  | same as `WAITING_FOR_TXS`                                                   |
+| `ASSEMBLING_CHECKPOINT`     | `aztecSlotDuration + pipeliningAttestationGracePeriod`                      |
+| `COLLECTING_ATTESTATIONS`   | same as `ASSEMBLING_CHECKPOINT`                                             |
+| `PUBLISHING_CHECKPOINT`     | `2 * aztecSlotDuration - ethereumSlotDuration` (extends into the target slot) |
+
+In production-like timing, `pipeliningAttestationGracePeriod` is zero, so `ASSEMBLING_CHECKPOINT` and
+`COLLECTING_ATTESTATIONS` must be *entered* before the build-slot boundary. Local networks with
+`l1PublishingTime < ethereumSlotDuration` can use the target-slot attestation window as grace while preserving the
+L1-geometry publishing cutoff. Once entered, attestation collection itself has its own
+`checkpointAttestationDeadline = 2 * aztecSlotDuration - ethereumSlotDuration`, so a late attestation arriving after
+the boundary is still accepted. The publishing deadline extends into the target slot because that is when the L1 tx is
+actually submitted.
+
+## Example: 72 s slot, 8 s sub-slots
+
+With typical pipelining values:
+
+```
+checkpointInitializationTime = 1s
+blockDuration               = 8s
+checkpointAssembleTime      = 1s
+p2pPropagationTime          = 2s
+l1PublishingTime            = 12s
+
+timeReservedAtEnd      = 1 + 2*2 + 8       = 13s
+timeAvailableForBlocks = 72 - 1 - 13       = 58s
+maxNumberOfBlocks      = floor(58 / 8)     = 7
+```
+
+Seven sub-slots, all of which build a block:
+
+```
+Sub-slot 1: starts 1s,  deadline 9s    (Block 1)
+Sub-slot 2: starts 9s,  deadline 17s   (Block 2)
+Sub-slot 3: starts 17s, deadline 25s   (Block 3)
+Sub-slot 4: starts 25s, deadline 33s   (Block 4)
+Sub-slot 5: starts 33s, deadline 41s   (Block 5)
+Sub-slot 6: starts 41s, deadline 49s   (Block 6)
+Sub-slot 7: starts 49s, deadline 57s   (Block 7 — held for the checkpoint proposal)
+
+57s:  Block 7 done, ASSEMBLING_CHECKPOINT (1s)
+58s:  CheckpointProposal broadcast
+60s:  Committee receives proposal (+2s p2p)
+60-68s: Committee re-executes Block 7
+68s:  Committee sends attestations
+70s:  Proposer has the quorum (+2s p2p)
+
+70-72s: Slack
+72s:  Build slot ends → L1 submission starts (target slot begins)
+84s:  L1 tx mined inside the target slot (+12s)
+```
+
+## Parallel execution: proposer vs committee
+
+While the proposer builds block `k+1`, the committee is re-executing block `k`. The pipeline keeps both sides busy except for the cooldown sub-slot.
+
+```
+Time | Proposer                     | Committee
+-----|------------------------------|--------------------------------------
+1s   | Start Block 1                | (idle)
+9s   | Finish Block 1, broadcast    |
+9s   | Start Block 2                |
+11s  |                              | Receive Block 1 (9s + 2s)
+     |                              | Re-execute Block 1
+17s  | Finish Block 2, broadcast    |
+17s  | Start Block 3                |
+19s  |                              | Finish Block 1 (11s + 8s)
+     |                              | Receive Block 2 (17s + 2s)
+     |                              | Re-execute Block 2
+...
+49s  | Finish Block 6, broadcast    |
+49s  | Start Block 7 (last)         |
+51s  |                              | Receive Block 6 (49s + 2s)
+     |                              | Re-execute Block 6
+57s  | Finish Block 7 (held)        |
+     | ASSEMBLING_CHECKPOINT (1s)   |
+58s  | Broadcast CheckpointProposal |
+59s  |                              | Finish Block 6 (51s + 8s)
+60s  |                              | Receive Block 7 + Checkpoint (58s + 2s)
+     |                              | Re-execute Block 7
+68s  |                              | Send attestations (60s + 8s)
+70s  | Receive attestations         |
+70-72s| Slack                       |
+72s  | L1 tx submitted              |
+84s  | L1 tx mined                  |
+```
+
+**Observations**:
+
+- Validators always lag the proposer by ~2 s (one p2p hop).
+- For the last block there is no `k+1` to build alongside; once the proposer broadcasts the `CheckpointProposal`, it just waits while the committee re-executes.
+- L1 publishing happens entirely inside the next slot and does not steal time from block building.
+
+## Handling timing variations
+
+### Fast initialization (0.5 s instead of 1 s)
+
+Sub-slot 1's deadline is still 9 s, so Block 1 gets a 0.5 s bonus before hitting its deadline. No structural change.
+
+### Slow initialization (2 s instead of 1 s)
+
+Block 1 has 7 s of build time instead of 8 s. Still well above `minExecutionTime`, so the block still gets built. No sub-slots are skipped.
+
+### Very slow initialization (8 s)
+
+Sub-slot 1's deadline (9 s) is closer than `minExecutionTime` (2 s), so it is skipped entirely. The first attempted block runs in sub-slot 2 with the usual budget. The checkpoint will have one fewer block.
+
+### Block takes longer than its budget
+
+`CheckpointBuilder` enforces the deadline by stopping public-tx execution; in practice a block can only overrun by the time it takes to finalize the block (typically < 1 s). The next sub-slot starts as scheduled but with proportionally less headroom. If that headroom drops below `minExecutionTime`, the next sub-slot is skipped.
+
+### Block finishes early
+
+The sequencer transitions to `WAITING_UNTIL_NEXT_BLOCK` and sleeps until the next sub-slot start. This keeps the cadence regular and gives validators predictable arrival times for re-execution.
+
+### Block proposal returns insufficient txs
+
+The current sub-slot is dropped without committing anything. The loop retries on the next sub-slot. If `buildCheckpointIfEmpty` is true, the last sub-slot is forced through with whatever is available, including zero txs.
+
+### Build slot ends before attestations arrive
+
+`assertTimeLeft` will reject `PUBLISHING_CHECKPOINT` if the attestation deadline has passed; the slot is abandoned, and
+`checkpoint-publish-failed` is emitted. The `PUBLISHING_CHECKPOINT` deadline allows spillover into the target slot
+(`2 * aztecSlotDuration - ethereumSlotDuration`) precisely to absorb a small overrun.
+
+### Pipelined parent fails on L1
+
+Before submitting, the job calls `waitForValidParentCheckpointOnL1`. If the parent we built on top of did not land cleanly (wrong archive, missing attestations, etc.) the job discards its checkpoint, emits `pipelined-checkpoint-discarded`, and enqueues an invalidation for the parent so the next proposer doesn't get stuck on the same bad ancestor.
+
+## Configuration constraints
+
+`initializeDeadline` must be positive, so `aztecSlotDuration > checkpointInitializationTime + 2 * minExecutionTime`. With defaults that lower bound is 5 s, far below any realistic slot length.
+
+For multi-block production to make sense, `maxNumberOfBlocks ≥ 2`:
+
+```
+aztecSlotDuration ≥ checkpointInitializationTime
+                  + 2 * blockDuration                // two blocks
+                  + checkpointAssembleTime
+                  + 2 * p2pPropagationTime
+                  + blockDuration                    // last-block re-execution window
+```
+
+Block duration should be ≥ `minExecutionTime` (otherwise no sub-slot ever has enough headroom). `p2pPropagationTime` should be measured against the deployment's actual p2p latency: it directly determines how much of each slot is spent on the cooldown.
+
+`l1PublishingTime` should fit inside the Ethereum slot the target slot maps to. The default of 12 s lines up with one
+Ethereum slot; fast local networks may reduce it to use the target-slot attestation window as assembly and attestation
+grace.

package/src/sequencer/automine/README.md

@@ -0,0 +1,46 @@
+# AutomineSequencer
+
+A minimal, deterministic, queue-driven sequencer for e2e tests that do not exercise block-building or consensus mechanics (e.g. `e2e_token`, `e2e_amm`, `e2e_authwit`).
+
+## When to use it
+
+Use `AutomineSequencer` (via `AUTOMINE_E2E_OPTS`) for single-sequencer tests that care about contract logic, not about proposer selection, attestations, pipelining, or multi-validator coordination. It bypasses all of that machinery.
+
+Use the production `Sequencer` (via `PIPELINING_SETUP_OPTS` or the default) for tests that explicitly exercise consensus, validator rotation, P2P gossip, slashing, or multi-node behavior.
+
+**Requirement**: the deployed rollup must have `aztecTargetCommitteeSize == 0`. This causes `Rollup.verifyProposer` / `verifyAttestations` on L1 to short-circuit and accept an empty `CommitteeAttestationsAndSigners`, which is what `AutomineSequencer` always sends.
+
+## What it omits
+
+Compared to the production `Sequencer`:
+
+- No proposer-turn check (single sequencer, always proposes).
+- No sync check, no pipelining, no timetable enforcement.
+- No validator orchestration, attestation collection, or P2P proposal gossip.
+- No slashing, no governance votes, no `SequencerEvents`.
+
+Consumers (archiver, world-state, `EpochTestSettler`) observe L1 and the archiver tip directly rather than listening for sequencer events.
+
+## Serial-queue invariant
+
+Every operation — mempool-driven block builds, explicit empty-block builds, time warps, and reorgs — is serialized through a single `SerialQueue`. They never interleave.
+
+Public entry points:
+
+| Method | Description |
+| --- | --- |
+| `buildIfPending()` | Enqueues a mempool-driven build. Coalesces bursts into one job. |
+| `buildEmptyBlock()` | Enqueues a forced empty-block build. |
+| `warpTo(ts)` / `warpBy(delta)` | Advances L1 time to a slot boundary. |
+| `revertToCheckpoint(n)` | Rolls L1 back to the block that published checkpoint `n`, then resets archiver, world-state, and P2P pool. |
+| `syncPoint()` | Awaits the queue reaching idle. |
+
+## Entry points
+
+**Factory** — `createAutomineSequencer` in `automine_factory.ts` wires up all dependencies (publisher manager, keystore, cheat codes, etc.), starts the `PublisherManager`, and returns an unstarted `AutomineSequencer`. The caller (`AztecNodeService.createAndSync` in `aztec-node/src/aztec-node/server.ts`) invokes `AutomineSequencer.start()` separately. It is called by the full node when `aztecTargetCommitteeSize == 0`.
+
+**Test fixture** — `AUTOMINE_E2E_OPTS` in `end-to-end/src/fixtures/fixtures.ts` is the test-side entry point. Pass it to `setup()` to get a node + `AutomineSequencer` instead of the production sequencer stack.
+
+## Epoch proving caveat
+
+Epoch proving remains manual under `AUTOMINE_E2E_OPTS`. The e2e `setup()` fixture does NOT wire an `EpochTestSettler` — that observer is only attached in `local-network.ts`. Tests that cross epoch boundaries must therefore advance the proven anchor explicitly via `cheatCodes.rollup.markAsProven(...)`. See `e2e_lending_contract.test.ts` (which calls `progressSlots` in `simulators/lending_simulator.ts`) and `e2e_pruned_blocks.test.ts` for real examples.

package/src/sequencer/automine/automine_factory.ts

@@ -0,0 +1,145 @@
+import type { Archiver } from '@aztec/archiver';
+import type { BlobClientInterface } from '@aztec/blob-client/client';
+import type { EpochCache } from '@aztec/epoch-cache';
+import { GovernanceProposerContract, type RollupContract } from '@aztec/ethereum/contracts';
+import type { L1TxUtils } from '@aztec/ethereum/l1-tx-utils';
+import { PublisherManager } from '@aztec/ethereum/publisher-manager';
+import { EthCheatCodes } from '@aztec/ethereum/test';
+import type { ViemPublicClient } from '@aztec/ethereum/types';
+import type { Logger } from '@aztec/foundation/log';
+import type { DateProvider } from '@aztec/foundation/timer';
+import type { KeystoreManager } from '@aztec/node-keystore';
+import type { P2PClient as ConcreteP2PClient, P2P } from '@aztec/p2p';
+import type { L2BlockSource } from '@aztec/stdlib/block';
+import type { ChainConfig } from '@aztec/stdlib/config';
+import type { WorldStateSynchronizer } from '@aztec/stdlib/interfaces/server';
+import type { L1ToL2MessageSource } from '@aztec/stdlib/messaging';
+import type { TelemetryClient } from '@aztec/telemetry-client';
+import { type FullNodeCheckpointsBuilder, NodeKeystoreAdapter, type ValidatorClient } from '@aztec/validator-client';
+
+import { type SequencerClientConfig, getPublisherConfigFromSequencerConfig } from '../../config.js';
+import type { GlobalVariableBuilder } from '../../global_variable_builder/global_builder.js';
+import { SequencerPublisherFactory } from '../../publisher/sequencer-publisher-factory.js';
+import { AutomineSequencer } from './automine_sequencer.js';
+
+/** Arguments for {@link createAutomineSequencer}. */
+export type CreateAutomineSequencerArgs = {
+  config: SequencerClientConfig & Pick<ChainConfig, 'l1ChainId' | 'rollupAddress'>;
+  l1TxUtils: L1TxUtils[];
+  funderL1TxUtils: L1TxUtils | undefined;
+  publicClient: ViemPublicClient;
+  rollupContract: RollupContract;
+  epochCache: EpochCache;
+  blobClient: BlobClientInterface | undefined;
+  telemetry: TelemetryClient;
+  dateProvider: DateProvider;
+  keyStoreManager: KeystoreManager;
+  validatorClient: ValidatorClient;
+  checkpointsBuilder: FullNodeCheckpointsBuilder;
+  globalVariableBuilder: GlobalVariableBuilder;
+  worldStateSynchronizer: WorldStateSynchronizer;
+  archiver: L2BlockSource &
+    L1ToL2MessageSource &
+    Pick<Archiver, 'rollbackTo' | 'addBlock' | 'addProposedCheckpoint' | 'syncImmediate'>;
+  p2pClient: P2P & Pick<ConcreteP2PClient, 'sync'>;
+  l1Constants: { l1GenesisTime: bigint; slotDuration: number; ethereumSlotDuration: number; rollupManaLimit: number };
+  log: Logger;
+};
+
+/**
+ * Builds an {@link AutomineSequencer} for use in single-sequencer e2e tests.
+ *
+ * Constructs the PublisherManager, GovernanceProposerContract, SequencerPublisherFactory,
+ * looks up the attestor/coinbase/feeRecipient from the keystore, wires EthCheatCodes,
+ * and starts the publisher manager before returning.
+ */
+export async function createAutomineSequencer({
+  config,
+  l1TxUtils,
+  funderL1TxUtils,
+  publicClient,
+  rollupContract,
+  epochCache,
+  blobClient,
+  telemetry,
+  dateProvider,
+  keyStoreManager,
+  validatorClient,
+  checkpointsBuilder,
+  globalVariableBuilder,
+  worldStateSynchronizer,
+  archiver,
+  p2pClient,
+  l1Constants,
+  log,
+}: CreateAutomineSequencerArgs): Promise<AutomineSequencer> {
+  const publisherManager = new PublisherManager(l1TxUtils, getPublisherConfigFromSequencerConfig(config), {
+    bindings: log.getBindings(),
+    funder: funderL1TxUtils,
+  });
+  const governanceProposerContract = new GovernanceProposerContract(
+    publicClient,
+    config.governanceProposerAddress.toString(),
+  );
+  const publisherFactory = new SequencerPublisherFactory(config, {
+    telemetry,
+    blobClient: blobClient!,
+    epochCache,
+    governanceProposerContract,
+    rollupContract,
+    dateProvider,
+    publisherManager,
+    nodeKeyStore: NodeKeystoreAdapter.fromKeyStoreManager(keyStoreManager),
+    logger: log,
+  });
+  const attestorAddresses = NodeKeystoreAdapter.fromKeyStoreManager(keyStoreManager).getAttesterAddresses();
+  const attestor = attestorAddresses[0];
+  if (!attestor) {
+    throw new Error('AutomineSequencer requires at least one attestor address in the keystore');
+  }
+  const coinbase = validatorClient.getCoinbaseForAttestor(attestor);
+  const feeRecipient = validatorClient.getFeeRecipientForAttestor(attestor);
+  const ethCheatCodes = new EthCheatCodes(config.l1RpcUrls, dateProvider, log.createChild('eth-cheat-codes'));
+
+  // Include the funder's L1TxUtils in the reorg reset list so funding-tx nonces don't
+  // go stale after L1 rollbacks. Dedupe by sender address in case the funder reuses a
+  // publisher's signer.
+  const reorgResetL1TxUtils = (() => {
+    if (!funderL1TxUtils) {
+      return l1TxUtils;
+    }
+    const funderAddress = funderL1TxUtils.getSenderAddress().toString();
+    const alreadyIncluded = l1TxUtils.some(utils => utils.getSenderAddress().toString() === funderAddress);
+    return alreadyIncluded ? l1TxUtils : [...l1TxUtils, funderL1TxUtils];
+  })();
+
+  const automineSequencer = new AutomineSequencer({
+    publisherFactory,
+    checkpointsBuilder,
+    globalsBuilder: globalVariableBuilder,
+    worldState: worldStateSynchronizer,
+    l2BlockSource: archiver,
+    l1ToL2MessageSource: archiver,
+    p2pClient,
+    ethCheatCodes,
+    dateProvider: dateProvider as any, // TestDateProvider; verified at construction in fixture
+    l1Constants: {
+      l1GenesisTime: l1Constants.l1GenesisTime,
+      slotDuration: l1Constants.slotDuration,
+      ethereumSlotDuration: l1Constants.ethereumSlotDuration,
+      rollupManaLimit: l1Constants.rollupManaLimit,
+      epochDuration: config.aztecEpochDuration,
+    },
+    coinbase,
+    feeRecipient,
+    signatureContext: { chainId: config.l1ChainId, rollupAddress: config.rollupAddress },
+    config,
+    archiver,
+    l1TxUtils: reorgResetL1TxUtils,
+    stopExtras: () => publisherManager.stop(),
+    log: log.createChild('automine-sequencer'),
+  });
+
+  await publisherManager.start();
+  return automineSequencer;
+}