Cryptography overview

audience: contributors

This chapter names the cryptographic primitives each organism relies on, names the specific schemes the reference implementation will use, and points at the literature. It does not re-derive any of them.

The reader is assumed to be comfortable with threshold cryptography, authenticated encryption, elliptic-curve DH, and zero-knowledge proofs at a practitioner level.

Shared primitives

The lattice inherits mosaik’s baseline and layers per-organism schemes on top.

• Peer identity. Ed25519 (iroh) for peer-to-peer TLS cert signing and bond authentication. Out of scope here — see the mosaik book.
• Hashing for identifier derivation. blake3 for every UniqueId, GroupId, StreamId, StoreId fingerprint. Same discipline zipnet uses; see topology-intro — Within-lattice derivation.
• Serialisation for state-machine commits. postcard (mosaik default). Stable, deterministic, fits in-flight sizing.

zipnet

Inherits zipnet v1 exactly. Summary:

• Pad derivation. Pairwise X25519 ECDH + HKDF-SHA256 + AES- 128-CTR, per server per client per round.
• Falsification tag. Keyed blake3 over plaintext + slot.
• Client attestation (v2 TDX path). Intel TDX quote verified via mosaik::tee::tdx.

See the zipnet cryptography chapter for the full derivation.

unseal (threshold decryption)

Candidate scheme. Threshold BLS12-381 encryption.

• DKG. Each committee member runs a Pedersen-style distributed key generation at deployment time. The resulting public key is published in UnsealConfig and folds into the organism’s fingerprint.
• Encryption. Zipnet’s client-side seal layer — applied on top of the DC-net payload — encrypts to the unseal committee’s public key. Ciphertext is constant-size, same discipline zipnet maintains on wire.
• Share generation. Each committee member computes its share on incoming zipnet::Broadcasts, gossips it on the unseal private network, and commits it to UnsealMachine once it has seen t-1 peer shares too (to avoid committing a share that can never be completed on the other side).
• Combine. UnsealMachine::apply(SubmitShare) runs the threshold combine when the t-th share lands; the cleartext is appended to UnsealedPool and the shares are discarded.

Why BLS12-381. Widely available, small shares, combine is pairing-free on the committee side, standard cryptographic libraries have audited implementations.

Why not post-quantum. Out of scope for v0.3; see Roadmap — Post-quantum unseal.

Literature.

• Shoup, “Practical Threshold Signatures” (EUROCRYPT 2000).
• Boneh, Lynn, Shacham, “Short Signatures from the Weil Pairing” (ASIACRYPT 2001) — for the signing variant that tally borrows.

offer (sealed-bid auction)

Candidate scheme. Same threshold encryption primitive as unseal, parameterised with an auction-specific DKG.

• Sealed bid. Searcher encrypts to the offer committee’s threshold public key before submitting. The public key is part of OfferConfig.
• Auction close. OfferMachine::apply(CloseAuction) triggers a round of share exchange identical to unseal’s; the winning bid is recovered inside apply, no committee member ever sees the losing bids in the clear.
• Fairness. Because bids are threshold-encrypted, a minority of compromised committee members cannot learn losing bids. A majority still can; see threat-model.md — offer.

Why not a commit-reveal scheme. Commit-reveal leaks a linkable commitment on the wire, which a colluding adversary could correlate with an on-chain bid identity. Threshold encryption collapses the reveal step into the committee’s state-machine apply, preserving the anonymity set through the full auction.

atelier (co-building)

Candidate scheme. TDX attestation + BLS aggregate signature.

• Admission. Every committee member’s PeerEntry carries a TDX quote (Intel DCAP). Admission tickets validate the quote’s MR_TD against the pinned expected value in AtelierConfig.
• Collective signature on Candidates. Each committee member signs the candidate block body with their BLS public key after the block passes the state machine’s validation; the aggregated signature is stored alongside the body in Candidates. Proposers can verify this signature to confirm that the lattice committee attested to the block.
• Bundle simulation integrity. Simulations run inside the TDX enclave; committee members compare simulation outputs via SubmitHint commits. Divergent simulations are visible in the commit log and trigger alerts.

Why TDX and not SGX / other. Operational availability. TDX is the hardware mosaik already supports; SGX support lives in a hypothetical mosaik extension. A future switch to another TEE changes which require_ticket(...) validator is used, not the organism’s public surface.

relay (PBS fanout)

Cryptography. Minimal.

• Proposer-side authentication. MEV-Boost-compatible TLS (L1 PBS) or the sequencer’s native auth (L2).
• Member-to-member integrity on Ship<Header>. Standard mosaik ticket-gated stream.

No bespoke cryptography. Relay’s integrity claim rides on the atelier aggregate signature; the proposer verifies that signature directly.

tally (refund attribution)

Candidate scheme. ECDSA over secp256k1 (the curve Ethereum settlement contracts expect).

• Committee key management. Each tally member holds an ECDSA keypair whose public key is published in TallyConfig.
• Attestation. Each Refunds[S] commit triggers each committee member to sign the commit; the collection of signatures (or a t-of-n aggregate — tbd at v0.3) is the Attestations[S] entry.
• On-chain verification. Settlement contracts verify the attestation signature set against the published committee public keys. A minority of compromised members cannot forge an attestation; a majority can, but the contract can pin a higher threshold than a simple majority if needed.

Why secp256k1 and not BLS. Settlement contracts on EVM chains have native ecrecover support; BLS verification is possible via precompiles (BLS12-381) but more expensive. For cross-chain settlement to L2s without BLS precompiles, secp256k1 is the safer default. A future tally may ship a BLS variant parametric in the settlement contract’s verification primitive.

Summary table

Deferred items

• Post-quantum unseal. See Roadmap.
• Re-randomisable bids in offer (so that a searcher cannot prove after-the-fact which bid was theirs to an external party). Research-open; not blocking v1.
• Zero-knowledge proof of block validity in atelier. Would remove the need for relay to carry the collective signature to the proposer; would add a ZK proving cost per slot. Deferred to post-v1 once proving systems are cheaper.

Cross-references

• Threat model — what each scheme protects against and what it does not.
• Organisms — each organism’s public surface that these primitives live behind.
• Roadmap — where the deferred schemes are scheduled.