Skip to main content

​
Verifying and Rolling Out a CKB Release

The previous weeks asked whether application and channel state could be trusted after crashes and force-closes. Week 19 moves down one layer: can the node binary producing that evidence be trusted, and can an operator introduce it without turning a valid release into an unsafe deployment? CKB v0.210.0 was published September 17, 2026 as a regular minor release. Its release page supplies signed downloadable artifacts, platform variants, a compatibility table, and chain-specific default assume-valid targets. Those facts do not by themselves prove that the file on an operator’s disk is correct or that a rollout is healthy. They supply the inputs to an evidence process.

​
Verify identity before execution

An artifact decision binds all of these fields together:
  • release version and tag;
  • exact filename;
  • operating system and architecture;
  • portable versus native build;
  • cryptographic digest of downloaded bytes;
  • signature from a trusted release key.
Checking only a filename permits lookalikes. Checking only a digest copied from the same untrusted download location proves consistency, not provenance. Checking a valid signature while deploying the wrong architecture proves authenticity of the wrong artifact. Exercise 73 uses a deterministic HMAC signature solely to make the binding executable without external keys. Real CKB downloads use the release page’s .asc PGP signatures and the official integrity-check procedure. The exercise rejects changed bytes, modified signed metadata, untrusted signers, and a valid artifact aimed at the wrong platform.

​
Bind compatibility to the chain actually running

The v0.210.0 compatibility table records ckb2023 activation and minimum supported node versions per network. The release also publishes different default assume-valid block hashes for mainnet and testnet. An operator must not copy a mainnet checkpoint into a testnet deployment or infer compatibility from a version string alone. The local node observation must agree on: chain identity + consensus version + activation epoch + minimum node version + confirmed checkpoint hash Exercise 74 verifies that tuple. A below-minimum binary, wrong network, wrong checkpoint, or unconfirmed checkpoint blocks admission. The exercise’s version comparator and fixture epochs are a teaching model; the authoritative values remain the release metadata and active chain configuration. An assume-valid target is not a replacement for consensus. It is a chain-specific optimization boundary selected by the release. The node still follows CKB consensus beyond that checkpoint.

​
Roll out one failure domain at a time

Artifact integrity answers “what binary is this?” It does not answer “is this deployment healthy?” Week 19 uses a staged sequence: Canary -> RPC cohort -> validating/mining cohort -> Complete Each transition requires a fresh observation from the correct version and chain: bounded sync lag, sufficient peer connectivity, no sampled RPC errors, and a valid consensus tip. A stale green result cannot authorize the next stage. One healthy canary cannot jump directly to full fleet deployment. Exercise 75 stops on wrong-chain data, stale health, excess lag, missing peers, or RPC errors. Its rollback gate separately requires a verified backup, verified previous binary, reversible storage path, and completed restore drill. When a migration is not reversible, replacing the executable alone is not a rollback plan.

​
Preserve the decision as evidence

Exercise 76 combines independent evidence classes into one manifest: Every gate is conjunctive. A successful signature cannot replace health evidence; a green canary cannot replace artifact provenance; a backup file that has never restored cannot replace a rollback drill.

​
Evidence boundaries

The CKB transaction model remains the conceptual base. The release gate does not change consensus; it protects the software supply and operational path through which an operator participates in it. The Nervos Knowledge Base provides wider architectural context, CKB Quest inspires the assertion-driven checkpoints, and Nervos Nation remains optional ecosystem reading.

​
Run the exercises

  • 73-signed-artifact-verification.ts binds bytes, digest, signature, filename, version, and platform.
  • 74-chain-compatibility-and-checkpoint.ts rejects cross-chain, below-minimum, mismatched, and unconfirmed compatibility evidence.
  • 75-staged-node-rollout.ts advances one healthy cohort at a time and requires a real rollback path.
  • 76-release-evidence-manifest.ts prints the final conjunctive approval decision and every missing gate.
Week 19’s lesson is operationally simple: “official release” is a source fact; “safe on this node fleet” is a conclusion that must be earned from several independent proofs.