> ## Documentation Index
> Fetch the complete documentation index at: https://ckb.danielasaboro.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Verifying and Rolling Out a CKB Release

> Week 19 turns CKB v0.210.0 release metadata into artifact, chain-compatibility, canary, and rollback evidence gates.

# 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](https://github.com/nervosnetwork/ckb/releases/tag/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](https://github.com/nervosnetwork/ckb/blob/develop/docs/integrity-check.md). 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:

| Gate           | Question                                                             |
| -------------- | -------------------------------------------------------------------- |
| Primary source | Did the metadata come from the official tagged release?              |
| Artifact       | Do filename, platform, digest, and version agree?                    |
| Signature      | Was the manifest authenticated by a trusted release identity?        |
| Chain binding  | Do compatibility and checkpoint evidence belong to this network?     |
| Fresh canary   | Is the deployed binary healthy now, not merely at some earlier time? |
| Rollback       | Has the actual restore path been verified?                           |

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

| Claim                                                                               | Classification                  |
| ----------------------------------------------------------------------------------- | ------------------------------- |
| v0.210.0 tag, compatibility table, assume-valid hashes, artifacts, and `.asc` files | Official released CKB metadata  |
| The observed node chain, tip, lag, peers, and RPC errors                            | Operator/runtime evidence       |
| HMAC signatures, health thresholds, rollout cohorts, and JSON manifest              | Simplified local teaching model |
| Future health after fleet expansion                                                 | Unknown until freshly observed  |

The [CKB transaction model](https://docs.nervos.org/docs/getting-started/how-ckb-works) 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](https://www.nervos.org/knowledge-base) provides wider architectural context, [CKB Quest](https://ckb-quest.vercel.app/) inspires the assertion-driven checkpoints, and [Nervos Nation](https://nervosnation.com/) remains optional ecosystem reading.

## Run the exercises

```bash theme={null}
cd week19/ckb-release-integrity-rollout
npm test
```

* `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.