CKB Dev Log 2025-03-05

[jjyr]

Updates

Features

CKB

• Released CKB 0.200.0 https://github.com/nervosnetwork/ckb/releases with Meepo hardfork time scheduled
• Released ckb-debugger: https://github.com/nervosnetwork/ckb-standalone-debugger/releases/tag/v0.200.0-rc1
• Released TypeScript-based ckb-testtool for unit testing: feat: add package ckb-testtool ckb-js-vm#55
• Launched an experimental JavaScript-based CKB script testing framework using CCC: Add unittest package ckb-devrel/ccc#164
  • An example project for contract development and testing entirely in JavaScript: https://github.com/libraries/ccc-unittest-example
• Experimental quantum-resistant lock overhaul: https://github.com/xxuejie/quantum-resistant-lock-script/tree/overhaul

Fiber

• Released Fiber v0.4.0 & mainnet deployment https://github.com/nervosnetwork/fiber/releases/tag/v0.4.0
• Added WebSocket interfaces for Fiber nodes to subscribe to invoice/payment state changes: Persist cch state and make cch a standalone service fiber#522
• Introduced Fiber Autopilot, an experimental project for continuous network analysis and peer recommendation: https://github.com/nervosnetwork/fiber-autopilot

Improvements & Fixes

CKB

• Developed a CKB message propagation simulator to test Erlay’s effects: https://github.com/Officeyutong/ckb-message-transport-simulator
  • Upgraded multiaddr to support Onion protocol in the hardfork version: chore: upgrade multiaddr #4810
• Refactored ckb-probe: feat: support hardfork cryptape/ckb-discovery#5
• Network code refactoring: revert: revert unnecessary operations #4812
• Minor updates to ckb-script: chore(script): make DataLocation public #4815

Fiber

• Addressed a pending offered TLC amount calculation issue in CCH: Confirmed failed tlc should not in check limit and build settlement outputs fiber#528
• Fixed node restart issues during critical operations: Add ui test for send payment middle hops restarting fiber#512 Fix shutdown issues fiber#516
• Added extra fields for channel RPC: Add extra fields for channel RPC fiber#514
• Refactoring watchtower: Refactor watchtower fiber#524
• Implementing incremental funding tx construction: feat: ensure funding tx is built incrementally fiber#517
• Refactoring Funding Tracing Refactor Funding Tracing fiber#519
• Updating live cells to exclude those used by ongoing funding tx Exclude live cells used by ongoing funding tx fiber#521

In Pipeline

Fiber

• Expand channel and router RPC capabilities
• Conduct Fiber autopilot simulation and testing

[bentrnr21]

Thanks for sharing these updates! The upcoming Meepo hardfork and the enhancements in CKB 0.200.0 look promising, especially the introduction of ckb-debugger and the TypeScript-based ckb-testtool. These tools should significantly improve the development and testing experience.

I’m particularly interested in the experimental JavaScript-based script testing framework using CCC—do you see this evolving into a standard approach for smart contract testing on CKB?

Also, the quantum-resistant lock update is intriguing. Are there any benchmarks or comparisons available on its performance and security relative to existing cryptographic locks?

Thanks again to the team for continuously improving the Nervos ecosystem!

[xxuejie]

Some basic cycle consumption(in CKB's term, this refer to the performance) of the updated quantum resistant lock can be found here. Our current script is based on NIST approved FIPS 205 standard, which 12 different parameter sets are defined by NIST. While I absolutely recommende consulting to NIST's standard for precise definitions, I can provide some personal, subjective and not-very-accurate feelings:

• Bit length(128, 192, 256) refers to the, well, bit-length security you want to have for your secret keys.
• The s or f suffix at the end of bit lengths provide tradeoffs: the s variants spend more time for generating a signature, but are fast in verification; while the f varants are fast in signature generation, but are a bit slower in verification. I expect most usages in the blockchain world would favor the s variants.
• sha2 and shake are just 2 cryptographic hash functions utilized by SPHINCS+.

Assuming both hash functions are secure, I personally expect that most of us would use sha2-128s or sha2-256s parameter sets now. Looking at the numbers here, a lock script using sha2-128s takes 11.5 million cycles to verify a signature with the fastest implementation, while a lock script using sha2-256s takes about 25.7 million cycles.

For comparison, verifying a secp256k1 signature as implemented by the lock script in CKB's genesis block, takes roughly 1.7 million cycles. The quantum resistant lock surely takes more cycles to run(one can say the secp256k1 algorithm has higher performance), but I think we should be fine with 11.5 million - 25.7 million cycles for now.

In addition, cycles are only one metric of the whole story, one potential hurdle with SPHINCS+ based quantum resistant algorithm, is that signatures can be quite big: sha2-128s's signature is 7856 bytes long, while sha2-256s's signature is 29792 bytes long. This means we will hit the block size limit of CKB much sooner than we hit the cycle limits.

We do want to mention that SPHINCS+ based quantum resistant algorithms are really just the first to come out, there will be newer implementations and optimizations in the future, which might consume much less cycles and smaller signatures. We will keep an eye in this space, and keep bringing new solutions with better performance that can enable bigger adoption than SPHINCS+ does now.

Security-wise, it really depends on your view on quantum computers: do you believe quantum computers are already there(just in stealth mode)? Do you believe it will come in 10 years, or do you believe it will be quite some time before we can see mature quantum computers? The answer here, determines whether secp256k1, or other elliptic curve based signature algorithms is still usable. Some might fear the coming of quantum computers, and they want to employ quantum resistant algorithms as soon as they can, others might feel more optimistic, and we can still use secp256k1 and others. Different views and opinions might generate different results. There might never be a one-size-for-all solutions. Luckily, in CKB we can embrace many different solutions for different needs, so everyone will have a happy solution that suits their needs.

[XuJiandong]

I'm particularly interested in the experimental JavaScript-based script testing framework using CCC—do you see this evolving into a standard approach for smart contract testing on CKB?

The JS version ckb-testtool is part of ckb-js-vm.
The ckb-js-vm project enables developers to write on-chain scripts ALL in JavaScript/TypeScript. This means you can also write unit tests for on-chain scripts in JavaScript/TypeScript, providing a consistent development experience.
The ckb-js-vm project is currently under active development (especially documentation). Stay tuned for updates.