Nervos CKB: A Proof-of-Work Layer 1 That Puts Verification First

The Problem: Layer 1 Should Verify, Not Compute

Most blockchains try to do everything on layer 1, which leads to a trade-off between throughput and decentralization. Nervos CKB takes a different stance. It is a public permissionless layer 1 that focuses on verification, leaving computation to layer 2 and higher protocols. The README calls it a Universal Verification Layer. This is for developers who want a base layer that is secure and decentralized, but who are willing to move heavy computation off-chain. The target user is someone building a blockchain application that needs a robust settlement layer, not someone looking for a high-throughput smart contract platform.

How CKB Works: The Cell Model and CKB-VM

CKB uses a cell model instead of the account-based model used by Ethereum. Cells are similar to UTXOs but can hold arbitrary data, not just token balances. This design supports the verification-first philosophy: state is stored in cells, and CKB-VM executes scripts on-chain to validate transactions; applications can also perform work off-chain. The CKB-VM is a virtual machine based on RISC-V; confirm the supported ISA and runtime constraints for the deployed version. That means you can write scripts in any language that compiles to RISC-V, not just a custom language. The README states that CKB supports scripting in any programming language with CKB-VM. This is a significant difference from platforms that lock you into Solidity or a similar language. The consensus is an improved Nakamoto consensus, which the README links to an article about breaking the throughput limit of Nakamoto consensus. The goal is to maximize performance on average hardware and network bandwidth without sacrificing decentralization and security.

Getting a Node Running: Commands and Config

To join the mainnet, the README says to use the latest release and run `ckb init --chain mainnet`. For the testnet, run `ckb init --chain testnet`. The testnet is named Pudge and has been active since epoch 3113. The mainnet is named Mirana and has been active since epoch 5414. There is also a migration guide for upgrading from the older Lina chain, which is a hard fork. The configuration file is central to node setup. The README mentions a `dsn` option that controls whether stack traces are sent to Sentry on Rust panics. This is enabled by default before mainnet launch, and you can opt out by setting `dsn` to empty in the config file. That is a concrete, project-specific detail that shows the developers were thinking about privacy and operational control. For a developer chain, there is a separate doc on how to test a miner on a dev chain, which is useful for local development.

Mining with Eaglesong

CKB uses a custom mining algorithm called Eaglesong. The README links to an RFC for the algorithm. Eaglesong is a PoW hash function designed specifically for CKB. Using a custom algorithm means that CKB is not mineable with ASICs designed for Bitcoin or Ethereum, at least not directly. Eaglesong-specific ASIC miners are available and dominate practical mining; CPU or GPU mining is technically possible but is generally inefficient compared with ASICs, according to the project's mining guide. The README does not provide performance benchmarks, so I cannot confirm how efficient Eaglesong is compared to other PoW algorithms. But the choice of a custom algorithm is a clear signal that the project values decentralization over compatibility.

Development Process and Branch Stability

The repository has two main branches: `master` and `develop`. The README states that `master` is regularly built and tested and is considered production ready. The `develop` branch is the working branch for new features and is not stable. This is a clear warning to anyone who wants to run a production node: use the `master` branch or the latest release, not `develop`. The default branch on GitHub is `develop`, which is unusual. This means that if you clone the repository without specifying a branch, you will get an unstable version. The README explicitly tells you to switch to `master` for mainnet or testnet docs. This is a potential footgun for new users who are not familiar with the project. The development process also includes a CHANGELOG in the Releases section and in the `master` branch. The recent releases are v0.209.0, v0.208.0, and v0.207.0, with the latest pushing on 2026-07-29. This shows active maintenance, but the release cadence is not specified.

Limitations and When CKB Is the Wrong Tool

CKB is not a general-purpose high-throughput blockchain. The README is explicit that it focuses on verification and leaves computation to layer 2. If you need to run complex smart contracts with high transaction throughput on layer 1, CKB is the wrong choice. The cell model is also different from the account model, so developers familiar with Ethereum will need to learn a new paradigm. The CKB-VM is RISC-V compatible, which is powerful, but it also means that tooling and libraries are less mature than those for EVM. Another limitation is the platform support. The README mentions that support is organized into three tiers, each with different guarantees. This means that not all platforms are equally supported, and you need to check the platform-support doc to see if your target environment is covered. The `dsn` option for Sentry is another consideration: if you do not want to send stack traces to Sentry, you must remember to change the config. This is a privacy consideration that is easy to overlook.

Alternative: Comparing to EVM-Based Layer 1s

The most direct alternative to CKB is an EVM-based layer 1 like Ethereum or a compatible chain. The difference is fundamental. EVM chains use an account model and a virtual machine that executes Solidity bytecode. CKB uses a cell model and a RISC-V VM that can run any language. EVM chains are designed to support complex smart contracts and high throughput, often through layer 2 solutions. CKB is designed to be a verification layer, so it offloads computation more aggressively. If you need to deploy existing Solidity contracts, CKB is not a drop-in replacement. You would need to write new scripts in a language that compiles to RISC-V, such as C or Rust, and then implement the verification logic. This is a significant difference in developer experience. The choice between CKB and an EVM chain depends on whether you value flexibility in scripting language or compatibility with the existing Ethereum ecosystem.

Maintenance and License Implications

CKB is released under the MIT license, which is permissive and allows commercial use, modification, and distribution. The README points to the COPYING file for details. This is a low-license-risk project for most companies. The maintenance cost is that you need to keep up with releases and potential hard forks. The README mentions a migration guide for upgrading from Lina to Mirana, which is a hard fork. This means that running a node requires attention to release notes and migration guides. The `develop` branch is unstable, so you cannot rely on it for production. The project is actively maintained, with recent releases in 2026, but the release cadence is not documented. The CI workflows for unit and integration tests are visible in the README, but there are no test results or coverage numbers. You should run your own tests before deploying a node. The configuration file is central to managing the node, and the `dsn` option is a specific thing to check. Overall, the maintenance cost is moderate: you need to monitor releases and be ready for hard forks, but the MIT license reduces legal overhead.

Editorial conclusion

Adopt Nervos CKB if you need a permissionless layer 1 that prioritizes verification and security over raw throughput, and you are comfortable with Rust and a RISC-V-based scripting model. Do not adopt it if you expect EVM compatibility or high transaction throughput on layer 1; those are not the goals. Before committing, verify the current release notes for any hard fork requirements, and check the platform support tiers to ensure your deployment hardware is supported. The project is MIT licensed and actively maintained, but the develop branch is unstable, so stick to master for production.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes