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

Roadmap

audience: contributors

This roadmap is scoped to the topology, not to any specific organism’s own v2 list. Each organism crate, when it lands, ships its own internal roadmap; the zipnet crate’s Roadmap to v2 is the template.

Items below are ordered by how visibly they affect the external behaviour of a lattice. Items are not engineering-ordered; pick what to implement based on what the first production lattice forces.

v0.1 — Proposal (this document)

Specification complete. No crates shipped. Audience: contributors who want to challenge the shape before implementation starts.

v0.2 — Walking skeleton

Goal: one lattice stands up end-to-end in a single-host integration test and commits one slot across all six organisms.

Minimum content:

  • Crate layout. One crate per organism (builder-zipnet, …, builder-tally) plus a builder meta-crate that owns LatticeConfig, UNIVERSE, and re-exports. Each organism crate follows the zipnet layered shape: proto/ + role-specific logic/ + node/ + lib.rs facade + optional main.rs operator binary.
  • State machines. One StateMachine impl per organism, with just enough commands to commit the per-organism facts in Organisms. Implementations are minimum-viable; the threshold-decrypt math in unseal, the auction math in offer, the block-assembly logic in atelier are all placeholders that write well-typed facts without doing the real cryptography.
  • Integration test. tests/e2e.rs that stands up six in- process Groups, submits one envelope through zipnet, watches it drop out the other end as a Refunds entry in tally. Modeled on zipnet’s one_round_end_to_end.
  • Book pages for each organism’s own contributor doc set.

Non-goals for v0.2:

  • Real cryptography in unseal and offer. The real threshold crypto lands in v0.3.
  • TDX admission in atelier. Mock attestation is fine for v0.2.
  • L2 specialization. L1 PBS only.

v0.3 — Real crypto and TDX admission

Goal: every organism whose security assumption depends on cryptography actually runs that cryptography.

  • unseal runs a real distributed key generation + threshold- decryption scheme (BLS12-381 threshold BLS is the candidate; CRYPTOGRAPHY will pin one).
  • offer’s sealed-bid auction is encrypted to the offer committee’s threshold key, decrypted in apply at auction close.
  • atelier committee admission requires valid TDX quotes via .require_ticket(Tdx::new().require_mrtd(atelier_mrtd)), same pattern zipnet’s v2 enables.
  • tally attestations are real ECDSA signatures verifiable by an on-chain settlement contract.

v0.4 — L2 specialization and the first sequencer lattice

Goal: stand up a lattice whose relay targets an L2 sequencer endpoint.

  • relay::Config grows a proposer_endpoint_policy parameter selecting { L1 validator set, L2 single sequencer, L2 leader rotation }.
  • Reference deployment: a unichain.testnet lattice wired to a testnet sequencer. This is the pattern described in Cross-lattice coordination — L1 / L2 / rollup specialization.
  • tally grows a chain-watcher backend per chain type.

v0.5 — Multi-operator atelier (Phase 2)

Goal: the first lattice where atelier committee members span more than one operator.

  • Operator-onboarding runbook for adding a co-builder. Same pattern BuilderNet uses: MR_TD pin, public roster, cut-over ceremony.
  • atelier::Config grows a committee_admission_policy parameter that lists the admission tickets instead of implying a single-operator default.
  • tally’s refund attribution carries a per-co-builder share.

v1.0 — First production lattice

Goal: one lattice runs on mainnet continuously for a month with no protocol-level incidents.

  • Rolling upgrades. Until this point, “stop the lattice, upgrade every binary, restart” is an acceptable release strategy; at v1.0 it is not.
  • Snapshot + state-sync for every organism’s state machine. No mosaik Group is allowed to need a full log replay after a restart in production.
  • Full operator runbooks under operators/, graded by severity and audited externally.
  • Stable LatticeConfig serialization format. Config::from_hex is safe to use as the handshake after v1.0.

Longer-term items (no version assigned)

Cross-lattice atomicity

The bridge-organism path described in cross-chain.md — Shape 3. Research-complete, engineering-deferred. The concrete candidate is a cross-chain intent router whose state machine implements HTLC- style atomic commit semantics. Needs a specific use case to force the design.

Byzantine liveness for committee organisms

Mosaik’s Raft variant is crash-fault tolerant. The Roadmap — Liveness resilience item in zipnet applies to every committee organism in the lattice. If mosaik eventually ships a BFT variant, every organism inherits it for free; until then, a deliberately compromised committee member can DoS liveness in its own organism.

Post-quantum unseal

Threshold BLS is not post-quantum. A lattice whose anonymity matters into the post-quantum era replaces unseal’s primitive with a lattice-based threshold scheme. The organism surface does not change; only the crypto inside UnsealMachine does. Research-complete for several schemes in the literature; engineering-deferred.

Globally parallel building

Phase 3 in the Flashbots decentralization writeup. The lattice already supports many lattices on one universe; going to “a lattice per region, dynamically joined” is an ops story (peer rotation, dynamic committee rebalance) more than a protocol change. Picked up when the first production lattice wants it.

Optional lattice directory

Not a core feature, same argument as zipnet. A shared Map<LatticeName, LatticeCard> listing known lattices may ship as a devops convenience. If built, it must:

  • be documented as a convenience, not a binding path;
  • be independently bindable — the organism crates never consult it;
  • not become load-bearing for ACL or attestation.

Flag in-source as // CONVENIENCE: if it lands.

Versioning

Carrying the zipnet policy into the multi-organism world with one adjustment.

  • Per organism: lockstep. Operators and integrators cut releases against matching organism crate versions. Organism StateMachine::signature() bumps are uncommon in steady state and coordinated.
  • Per lattice: version-in-name for the lattice identity. A lattice retirement is an operator-level decision and produces a new instance name (ethereum.mainnet-v2). Individual organisms inside a stable lattice name can still upgrade lockstep without retiring the lattice.

Neither policy is load-bearing for v0.2 / v0.3. The first v1.0 release forces the call.

What this roadmap does not include

  • Specific crate-versioning schedules. Each organism crate owns its own version cadence.
  • Cryptographic parameter choices beyond naming candidates. Those are the crate authors’ calls, made visible via cryptography.md.
  • Operator-onboarding contractual detail. Lattice operators run different organisations under different legal regimes; the book does not try to standardise that.
  • Marketing. The book’s job is to specify and document; the adoption path is the operators’.