CKB Dev Log 2026-09-16

[chenyukang]

Updates

This cycle (August 19 – September 15, 2026) focused on node and light-client hardening, CKB-VM maintenance, and continued work on the next tx-pool, storage, and networking architecture.

Key milestones include:

• CKB-VM v0.24.15 was released, followed by additional runtime correctness work.
• CKB light client landed another round of proof, header, and checkpoint validation hardening.
• CKB core continued reliability and security work across networking, tx-pool, sync, and rich-indexer paths.
• Larger efforts around transaction-pool architecture, RocksDB schema migration, and QUIC networking remain under review.
• DAO treasury and voting work advanced at the design/spec stage and remains research/PoC rather than a confirmed protocol change.

Releases & Features

CKB-VM v0.24.15

CKB-VM v0.24.15 was released on September 3, 2026, with maintenance updates around ASM machine structure and fuzzing stability.

CKB also updated its CKB-VM dependency to the new release line.

• CKB-VM v0.24.15
• Update ckb-vm to v0.24.15

Improvements & Fixes

CKB node reliability and security hardening

CKB landed targeted fixes across rich-indexer rollback, networking edge cases, dependency security, and legacy network-alert cleanup.

• Skip empty spent-cell resets during rich-indexer rollback
• Prevent timestamp underflow in hole punching
• Bump h2 to 0.4.17 for RUSTSEC-2026-0258
• Remove the network alert module

Light-client verification hardening

The light client added stricter validation for verifiable headers, legacy proof contents, and peer checkpoint comparison.

A follow-up matched-block retry path remains under review, and no new ckb-light-client release has shipped yet.

• Validate verifiable headers before processing last-state proof
• Reject legacy proofs whose headers commit to uncles or extensions
• Normalize peer checkpoints before quorum check
• Retry from a different peer when matched block hash is missing

CKB-VM runtime maintenance

Following the v0.24.15 release, we added a configurable safe mode remains in review.

• Add a configurable safe mode

Tooling and developer experience

Contract tooling documentation improved with new guidance for ckb-std and Rust script templates.

• Add ckb-std developer guide
• Add AGENTS.md for Rust script templates

In Pipeline

CKB release readiness and open hardening work

No new CKB node release shipped during this cycle; the latest public node release remains CKB v0.209.0.

Open reviews continue across tx-pool bounds, sync and network rate limits, block-relay isolation, overflow validation, and related reliability work.

• Bound verify queue transaction count
• Prevent relay backpressure from blocking block verification
• Bound pending sync response tasks and memory
• Validate GetHeaders locator length before allocation
• Enforce transaction and address isolation for block-relay-only peers
• Rate-limit SendHeaders processing by header count
• Rate-limit transaction fetches by hash count
• Prevent overflow in various calculations and add validation

Transaction-pool architecture

The transaction-pool redesign remains under review. The current direction models pool mutations as transactional state changes so admission, replacement, eviction, chain reconciliation, indexes, accounting, and notifications can be validated and committed together.

• Make tx-pool state changes transactional

RocksDB schema refactor

The RocksDB schema refactor remains under review. The proposal introduces a breaking database layout change intended to improve height-ordered locality and reduce read/write amplification, with an offline SST rebuild migration path.

• Refactor RocksDB schema to reduce Read/Write Amplification

QUIC networking integration

CKB’s initial QUIC integration remains under review. Related Tentacle work continued around identify timeout behavior, receive-buffer bounds, and inbound handshake limits.

• Initial CKB QUIC integration
• Fix identify timeout behavior
• Bound yamux receive-buffer chunk count and make window accounting O(1)
• Enforce connection limits before spawning inbound handshakes

DAO treasury and voting design

DAO treasury and voting work advanced through design/spec updates and cleanup of the previous solution.

The work remains at the research/PoC stage; production parameters, consensus rules, and integration are still open.

• Remove old solution
• Add design and spec documents
• Document the deployed DAO header index limit