Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Running a zipnet committee

audience: operators

Zipnet is the submission organism. The lattice consumes the existing zipnet operator book unchanged; this page is a pointer plus the lattice-specific overrides.

Read the zipnet operator book first

Every procedure in the zipnet book — running a committee server, running an aggregator, running a client, rotations, incident response, security posture — applies to the zipnet organism inside a lattice. Treat it as authoritative for operations on this organism.

What this page covers is only the places the lattice wraps zipnet in a different envelope.

What changes in a lattice context

Three things:

  1. Instance name. Zipnet’s ZIPNET_INSTANCE is derived from the lattice’s own LATTICE_INSTANCE rather than chosen independently. The reference systemd unit passes ZIPNET_INSTANCE="${LATTICE_INSTANCE}" verbatim; the zipnet config derivation lives inside the lattice’s LatticeConfig.
  2. Committee secret. ZIPNET_COMMITTEE_SECRET is one of the six organism secrets you generated in Quickstart — Step 2. Same semantics as documented in the zipnet book; only the provenance changes.
  3. Shared universe. Zipnet is already designed to run on zipnet::UNIVERSE = unique_id!("mosaik.universe"), which is identical to builder::UNIVERSE. You do not override ZIPNET_UNIVERSE; the lattice expects zipnet on the shared universe.

systemd unit example

# /etc/builder/zipnet-server.env
LATTICE_INSTANCE=acme.ethereum.mainnet
LATTICE_CHAIN_ID=1

# The same LATTICE_CONFIG_HEX the other organisms consume.
LATTICE_CONFIG_HEX=7f3a9b1c...

# Plus the zipnet-specific admission secret.
ZIPNET_COMMITTEE_SECRET_FILE=/etc/builder/secrets/acme.ethereum.mainnet.zipnet.secret

# Stable peer identity for the server; rotate only on incident.
ZIPNET_SECRET_FILE=/etc/builder/secrets/acme.ethereum.mainnet.zipnet.server-01.peer

The binary reads LATTICE_CONFIG_HEX, decodes the zipnet::Config fragment, and boots under the derived GroupId / StreamIds. The zipnet book’s env var reference describes ZIPNET_* knobs (round period, fold deadline, etc.) that are now fixed by the lattice Config — operators who want non-default windows change the LatticeConfig and rebuild, not the env.

Running the aggregator

No changes from the zipnet book. Run one zipnet aggregator process per lattice on a well-connected host and point it at the same LATTICE_CONFIG_HEX.

TDX-gated zipnet

If your LatticeConfig’s zipnet config has a pinned committee MR_TD (the zipnet v2 TDX posture), build the zipnet image with --features tee-tdx,tdx-builder-ubuntu and boot the server processes from the resulting image. Procedure identical to the zipnet TDX operator example.

What you do not do here

  • Do not manage the lattice’s other organisms in the same unit. One systemd unit per (organism, role).
  • Do not rotate ZIPNET_COMMITTEE_SECRET without the lattice operator’s coordinated rotation plan (see Rotations and upgrades).
  • Do not host the zipnet committee on hosts shared with unrelated tenants. Same hygiene as the zipnet book requires.

Observing

Zipnet’s Prometheus metrics are emitted under the zipnet crate’s namespace and labelled with the instance = LATTICE_INSTANCE. See Metrics reference for which zipnet metrics the lattice operator watches (committee size, round commit latency, agg dropouts).