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 an unseal committee

audience: operators

Unseal is the threshold-decryption organism that unwraps zipnet::Broadcasts into UnsealedPool for the downstream organisms. It is TDX-gated in every production deployment and is the organism whose threshold t-of-n parameter anchors the lattice’s anonymity budget.

Role in the lattice

Unseal watches zipnet::Broadcasts and commits one UnsealedRound per zipnet-finalized slot once t of n committee members contribute their threshold share. See unseal organism spec for the cryptographic details.

Committee sizing

The t-of-n threshold pinned in the LatticeConfig’s unseal::Config is the hard parameter. Recommended sizes:

ntAnonymity posture
32Minimum. One committee member going rogue is enough to preserve anonymity. Liveness brittle.
53Sensible dev / testnet shape.
75Recommended production posture.
97For lattices where anonymity matters most; pay the latency overhead.

Changing t-of-n after deployment changes the unseal fingerprint, which changes the GroupId, which means no bond. Treat sizing as a deployment-time decision; retirements and replacements instead of in-place changes.

Hardware

  • TDX-enabled hosts. Reference build: Ubuntu 24.04 on Intel TDX. See mosaik TDX subsystem.
  • Moderate RAM. 4 GiB default memory size in the TDX image build is enough; the organism’s state machine is small.
  • Stable peer identity. Like zipnet committee servers, unseal members need stable PeerIds across restarts. Each member’s secret key is pinned in the operator’s secret store.

systemd unit example

# /etc/builder/unseal-member.env
LATTICE_INSTANCE=acme.ethereum.mainnet
LATTICE_CHAIN_ID=1
LATTICE_CONFIG_HEX=7f3a9b1c...

UNSEAL_COMMITTEE_SECRET_FILE=/etc/builder/secrets/acme.ethereum.mainnet.unseal.secret

# Each member owns a distinct DKG share secret.
UNSEAL_SHARE_SECRET_FILE=/etc/builder/secrets/acme.ethereum.mainnet.unseal.member-03.share

# Stable peer identity.
UNSEAL_SECRET_FILE=/etc/builder/secrets/acme.ethereum.mainnet.unseal.member-03.peer

Distributed key generation

At lattice bring-up time the n committee members run a DKG ceremony. The resulting aggregate public key is what integrators seal their payloads against (see integrators/submitting.md).

The ceremony is a one-off: once complete, each member holds a share and the aggregate public key is pinned into the unseal::Config and shipped in the lattice’s LatticeConfig. Lose a share and you lose a committee member until the lattice retires and redeploys.

A DKG rerun happens:

  • At a scheduled rotation (see Rotations and upgrades).
  • When a committee member’s TDX image is compromised.
  • When the lattice operator retires the lattice identity.

What this organism does not do

  • It does not decide what is in a block. atelier does.
  • It does not auction. offer does.
  • It does not attest to any single committee member’s identity beyond the TDX quote on their PeerEntry.

Observing

Metrics to watch per member:

  • unseal_shares_submitted_total{slot=...} — rate of share contributions.
  • unseal_decrypt_latency_seconds — time from zipnet::Broadcasts append to UnsealedPool commit.
  • unseal_committee_size — how many committee members are bonded to this member.

If any member’s share rate drops to zero, that member is contributing nothing; rotate or investigate before the lattice’s anonymity posture weakens.