Pre-v1 Readiness Debt
This page tracks the remaining release-readiness checks for a v1 launch. It is not a list of missing features. Completed engineering work is called out so the remaining entries stay focused on sign-off, measurement, and operator rehearsal.
State-Root Engine
Status: implemented. Nervos is the main SMT implementation for new chains.
Current path:
- New chains default to
nervos-smt-v2. - The Nervos sidecar under
external/state-root-sidecar-nervoscomputes consensus state roots. - TypeScript remains the deterministic NOOSChain state machine: it produces ordered state mutations, verifies block/state-root metadata, drives replay, and owns snapshots.
- Existing
iden3-v1histories remain supported for replay and migration tests. They must cross an explicit activation boundary before moving to Nervos because the root schemes differ.
Implemented / covered:
- Use State-Root V1 Readiness as the release checklist for the state-root engine.
- Nervos sidecar readiness is mandatory in
noos state-root preflightandnoos production preflight. - Nervos sidecar restart/backoff, checkpoint recovery, corrupt-checkpoint rejection, wrong-version rejection, and timeout/degraded handling are covered by state-root sidecar tests.
- Noosraft and HashiCorp-Go hardness/soak paths cover Nervos activation, sidecar restart under load, snapshot export/import after activation, and observer catch-up after activation.
- State-proof generation/verification is covered by the Nervos proof test, HTTP API, CLI commands, and CLI/API docs.
- The V1 readiness benchmark matrix includes block execution, state-root engine comparison, snapshot archive import/export, sync catch-up, payload backfill, and persistent sidecar checkpoint/restart checks.
Remaining release sign-off:
- Review and sign off V1 Performance Targets for the intended production workload.
- Run
benchmark:v1-readinessandbenchmark:v1-readiness:checkon production-like hardware and archive the reports with the release candidate. - Treat any budget failure as a release blocker until the budget is revised with rationale or the implementation is optimized.
How to choose the production budgets:
- Define the v1 workload envelope: expected validators/observers, average and peak submitted transactions per second, expected transaction mix, average public-index fanout, payload sizes, and largest expected catch-up window.
- Choose an operator-visible block cadence target. For example, decide whether a committed block should normally land within 1 second, 2 seconds, or 5 seconds under peak-but-normal load.
- Set p95 and p99 budgets from that cadence. A practical v1 starting point is p95 below the desired cadence and p99 below twice the cadence, with failed deterministic transactions included in the mix.
- Define recovery budgets separately from steady-state commit latency: replay time for a known chain height, snapshot export/import time for expected data sizes, observer catch-up time after downtime, and payload backfill time for authorized ciphertext.
- Run the benchmark matrix on the intended production hardware and database class, not only on developer machines.
- Add headroom. Treat any benchmark that already uses more than about 60-70% of the budget as a pre-v1 optimization or capacity issue.
- Record the chosen numbers in V1 Performance Targets and make benchmark reports and release notes point to the same targets.
Sync And Backfill Recovery
Status: implemented and benchmarked locally. Still requires release-scale measurement.
Implemented / covered:
- Sync manager filters active trusted peers through peer scoring and avoids scoring-blocked peers.
- Eligible peers are ordered by score/status, while payload backfill can recover from a different peer than block sync.
- Sync catch-up benchmarks cover fresh observer, snapshot bootstrap, observer restart recovery, policy/permission changes, missing payloads, and multi-peer failover.
- Payload backfill benchmarks cover the local payload store path and cached payload-store byte/count stats.
- Multi-producer Phase 3 soaks cover peer-scoring penalties, manual quarantine/ban, gossip restoration, and membership changes under load.
- Multi-producer Phase 4 soaks cover large payload/block profiles plus packaged snapshot export/verify/import/replay round trips.
- Cached storage/payload observability counters have realtime diagnostic endpoints and parity tests.
- Admin auto-refresh is disabled by default and expensive storage/payload views have explicit safeguards.
Remaining release sign-off:
- Run sync catch-up and payload backfill portions of
benchmark:v1-readinesson production-like hardware with realistic chain height and payload volume. - Include the Phase 3 and Phase 4 soak variants in the overnight evidence bundle. Baseline soak alone is not enough: Phase 3 is the coverage for scoring penalties and membership changes under load, while Phase 4 is the coverage for large payload/block pressure and packaged snapshot round trips.
Consensus Operations
Status: implemented. HashiCorp-Go Raft is the production Raft path; Noosraft remains useful for deterministic tests and development.
Implemented / covered:
- Runtime membership changes are explicit and operator-approved.
- Governance validator set, runtime Raft membership, and trusted peers are reconciled through operator tooling rather than silent mutation.
- HashiCorp-Go runtime membership changes use the sidecar membership APIs.
- TLS/mTLS production preflight is mandatory for TypeScript HTTP, HashiCorp sidecar HTTP, and HashiCorp Raft TCP transport.
- Chaos/stability coverage exists for sidecar death, unresponsive sidecars, quorum loss, leader failover, restart persistence, and membership changes.
Remaining release sign-off:
- Run the HashiCorp-Go and Noosraft multi-validator hardness suites for the release candidate and archive reports.
- Run the overnight soak variants long enough to include leader failover, sidecar restart, observer catch-up, gossip/TLS where applicable, and operator-approved membership reconciliation. Use the Phase 3 soak variants for membership/scoring/gossip coverage and Phase 4 variants for large payload/block plus snapshot archive coverage.
Operator Experience
Status: implemented. CLI and Admin GUI exist; launch workflows still need a clean-workstation rehearsal.
Implemented / covered:
- Operator CLI loads the current folder
.env, hasdoctor, production preflight, monitor report, backup drill, state-root preflight, membership reconciliation, snapshot import/export, and transaction-building commands. - Admin GUI is read-mostly, uses operator token auth, hides raw JSON behind inspectors, disables auto-refresh by default, and guards dangerous actions.
- Snapshot export/import is CLI-local and archive-first; HTTP/Admin GUI export is disabled for large-file safety.
- Production preflight catches missing TLS, missing sidecars, wrong sidecar versions, unsafe production defaults, and database/migration incompatibility.
Remaining release sign-off:
- Run the CLI recipes for initialization, bucket setup, identity registration transactions, membership reconciliation, snapshot export/import, and incident response from a clean operator workstation.
- Confirm a new operator can follow the runbooks without project-internal context.
- Confirm the release artifact layout matches the documented commands on Windows and Linux.
Documentation And Release Sign-Off
Status: implemented as living documentation. Release sign-off still needs a final doc review.
Implemented / covered:
docs:buildbuilds the generated TypeDoc reference and VitePress site..env.exampleis grouped by context and documents known configuration keys.- Command taxonomy tracks current script names and command purpose.
- Runbooks exist for Nervos sidecar operations and recovery, HashiCorp-Go Raft deployment, TLS/mTLS, snapshot export/import, incident response, validator governance, runtime membership reconciliation, and production readiness.
Remaining release sign-off:
- Keep
docs:buildgreen and review the generated site navigation. - Review the generated docs from a clean checkout before release.
- Archive the final release evidence bundle:
benchmark:v1-readinessreport;benchmark:v1-readiness:checkreport;- Noosraft and HashiCorp-Go hardness reports;
- overnight soak reports;
- production preflight and state-root preflight reports;
- backup drill report;
- exact TypeScript node, HashiCorp sidecar, Nervos sidecar, migration, and docs versions.