Spark Program | NNCBN - Nervos Network Community Boot Nodes

NNCBN · August 23, 2026, 11:57am

(Spark v2) Request for Financial Support

Spark Program | NNCBN - Nervos Network Community Boot Nodes
Project Overview

Project Name:

NNCBN - Nervos Network Community Boot Nodes

One-Sentence Overview:

One Year of Network Node Operation: Improving Transaction Propagation, Network Diversity, and Redundancy While Establishing Community Bootnodes

Project Category:

Network technology, hardware operations, Community

Team Profile

Core Members:

@knmo , Entire Project -/Planning, Implementation, Further Development

Technical Background

Two-year vocational training program consisting of one year of theoretical IT study (application development and network technology), followed by a second year of practical training in systems electronics.
Contact Information:
@NNCBN - bootnode[ât]tutamail[dôt]com - Discord @NNCBN - github .com/NNCBN

Project Background

Background Description:

Bootnodes are required for the Nervos Network to operate. They maintain connections with other reachable nodes on the network. When a new node synchronizes for the first time, it needs bootnodes to discover full nodes from which it can obtain the blockchain data. These bootnodes are currently operated in data centers owned by large corporations. This arrangement lacks operator diversity and makes the network vulnerable to legal and economic pressures.

Ecosystem Relevance:

Widespread adoption of community bootnodes would mitigate the impact of potential problems affecting existing bootnodes. Interested individuals should have the opportunity to operate bootnodes themselves, provided they meet minimum requirements, particularly regarding long-term uninterrupted operation and performance.

Solution

Core Solution: How does the project address the above issues?

The project will create a new bootnode operated by an individual rather than a company and hosted outside a traditional data center. It will also support interested parties who wish to improve the decentralization of the Nervos Network by operating bootnodes themselves.

The first community bootnode is operated by me, the initiator of the Nervos Network Community Bootnode (NNCBN). Its geographic location will increase the diversity of the existing bootnodes and may significantly improve transaction propagation. It will operate on a West African island in the Atlantic, connected to an undersea cable linking Brazil and Portugal. Historically, connections between South America and Europe or Asia have often been routed through North America. This bootnode will provide a connection point in Africa between the heavily used Central European region and South America.

The project will also create and publish a curated list of selected bootnodes that will get tested through initial synchronization tests at randomly selected intervals. Bootnodes must remain continuously accessible so that new nodes can synchronize and establish connections through them. Preference will be given to bootnodes located in geographically underrepresented countries and operated on diverse operating-system platforms. Bootnodes hosted in data centers or operated through VPN providers are outside the scope of this project.

User Perspective: How do end users and developers use it? What are the results?

Transactions will be forwarded at high speed. Additionally, the first NNCBN network node serves than as an hub for connections from South America and West Africa. Pings to both South Africa and Central Europe show a latency of only ~80 ms, and ~200 ms to Australia and Brazil. Fast transaction routing between South America and Europe. Positive impact on transaction routing speed.

Differentiation: How does this differ from existing solutions?

The first NNCBN node represents a strategically positioned diversification of the full-node network. It provides an opportunity to improve network diversity without relying on major cloud providers such as Amazon and Google, as is currently the case for many bootnodes.

The provider-side routing over vast distances is notable: latency of approximately 80 ms to both Cape Town and Frankfurt provides a good example. Adverse conditions and outages at major cloud providers such as Amazon are rare, but they do occur, often with significant consequences.

Centralization is undesirable for several reasons, including dependence on the U.S. economy and jurisdiction, as well as hardware and software monocultures. A large proportion of the current infrastructure likely runs on Ubuntu or Debian. Diversity creates reliability through redundancy; less common alternatives, such as BSD or Qubes OS, should also be represented. Although this may not currently be necessary, system-wide vulnerabilities may arise that do not affect other operating systems.

I have chosen Qubes OS because it uses “qubes”—securely isolated compartments—and templates, providing both flexibility and security. Hardware has also been affected by vulnerabilities in the past. Prominent examples include the SRSO, “Inception,” and “Spectre” vulnerabilities, which were mitigated through software updates. A newer processor, beginning with the Zen 5 generation, will be used to operate the first NNCBN node. The latest BIOS update will be applied after the hardware is deployed and before the operating system is installed. Operating-system updates will be performed regularly, and weekly reports will provide details such as data usage and other optimization settings.

Technical Approach

Technology Stack:

AMD Zen5 processor, 16GB DDR5-RAM, 1024 GB SSD-HDD;

Architecture Overview: Core Modules and Their Relationships (Architecture Diagram or Flowchart May Be Included)

Qubes OS, template to run latest CKB linux-gnu (>=0.209.0). Installation without Docker. In future, there may also be other templates, such as those for system monitoring.

Key Technical Points: The Most Technically Challenging Aspects of the Project and Their Solutions

Hardware procurement, system installation, ongoing operation, software updates, and regular operational reporting—ideally on social media—to generate interest among others who may wish to operate an NNCBN. Relevant questions will also be answered through these channels.

Language: English

To-Do List

Break down by week: Week 1, Week 2, … (Recommended: 4–8 weeks, no more than 12 weeks)

Week 1: Procure the hardware, install the system, and document each step and practical experience for interested parties.

Week 2: Set up the contract with the internet service provider and synchronize the node.

Week 3: Create a social media account and share practical experiences from the installation and setup process. Share insights into network connections, data usage, and hardware utilization.

Weekly Goals: Specific tasks to be completed this week (not “continue development”)

Week 1: Hardware: check the configuration, apply the initial BIOS update, and install Qubes OS.

Week 2: Set up a contract with the internet service provider. Monthly prepaid payments are standard; if possible, set up automatic monthly payments.

Week 3: Share information about the hardware and software decisions made and their implementation.

Milestone Labels: Key milestones (e.g., MVP completion, start of testing, demo launch)

End of September: The operating system is installed and up to date.

Early October: The CKB node is installed and begins synchronizing. It connects primarily to a node in Santiago, South America (Google), and uses a node in Cape Town, Africa (Amazon) as a fallback.

Required Funding & Funding Breakdown
A. Funding Requirements

Total Amount Requested: Specific amount (USD)

1620$

ckb1qzda0cr08m85hc8jlnfp3zer7xulejywt49kt2rr0vthywaa50xwsqd0mhhll08axnhch63axryc4r36tde8k8qnkvckl

Single-Category Projects: (Purely technical development or purely user testing) If there is sufficient justification, you may apply for funding exceeding $1,000; however, the total cap for all project types remains at $2,000 and will not be adjusted. ** For applications exceeding $1,000, please provide a detailed explanation of why the project is structurally more complex than a standard single-category project and why the standard budget is insufficient to support delivery. The committee will evaluate each application on a case-by-case basis.

Hardware: one-time initial payment of $900 in September 2026.

I propose quarterly payments for electricity and internet: $10 per month for electricity plus $50 per month for internet, totaling $60 per month, or $180 per quarter, converted from CKB at the exchange rate in effect at the time.

The first quarterly payment, made in October 2026, will cover October, November, and December 2026. The second payment, made in January 2027, will cover January, February, and March 2027. The third payment, made in April 2027, will cover April, May, and June 2027. The fourth payment, made in July 2027, will cover July, August, and September 2027.

B. Funding Breakdown

Break it down item by item: List the use of funds by week or by category, clearly distinguishing between the technical and community components.

Hardware, One-time initial payment $900

Monthly Electricity $10

Monthly Internet $50

$60/month × 12 months = $720

Description of Use: What exactly is each fund used for?

Hardware: AMD Zen5 processor, 16GB DDR5-RAM, 1024 GB SSD-HDD;

Electricity consumption. Internet, Unlimited Data Usage.

Reasonableness: Aligned with the project scope and workload

The selected location for the first NNCBN provides exceptionally good intercontinental connectivity for the Nervos Network, enabling transactions to be routed quickly.

Internet and electricity prices are comparable to international rates.

The hardware is state-of-the-art and was selected to provide sufficient performance while maintaining low power consumption.

Deliverables + How to Verify
A. Deliverables

Deliverables List: List, item by item, the deliverables to be provided upon project completion

Hardware purchase

The internet connection has been established.

The hardware is running the latest BIOS version and Qubes OS. If unexpected complications arise with Qubes OS, a different operating system will be selected.

Node Software Settings, Become Discoverable by CKB Node Probe

Full Node Synchronization

A record of all settings for interested bootnode operators who wish to launch a similar system.

Acceptance Criteria: What are the “completion criteria” for each deliverable? (Reproducible and verifiable)

The network node is fully synchronized and continues to operate. Other nodes can discover this NNCBN among the available network connections and use it to synchronize newly configured nodes.

Format Guidelines: Code repositories, npm packages, documentation, demo URLs, videos, etc.

B. How to Verify

Acceptance Process: How can the committee/community independently verify each deliverable?

All steps will be documented, including instructions for future bootnode operators. This information will be made publicly available, and progress updates and details of actions taken will be shared on social media.

Non-code review verification: Can verification be completed without reviewing the code? (e.g., running tests, viewing demos, checking transaction hashes, reading documentation, etc.). This is a very critical point—if verification must rely on code review, it will be difficult for the committee, with its limited manpower, to cover everything.

The nodes.ckb.dev website lists permanently operational nodes. This node will appear as a dot in the Atlantic Ocean, west of Senegal. Its performance monitoring data will also be documented and published.

Expected Output: What results should be seen when the validation passes? (e.g., command output, page display, test report)

Fast transaction propagation between South America and Europe, while providing a point of connectivity for West Africa.

Environment Requirements: What environment is required? (e.g., operating system, dependencies, Node.js)

A less commonly used, security-focused Linux distribution was selected to promote greater diversity within the ecosystem.

Resource-Efficient Logging Settings: toml [logger] filter = “error”

Remove [rpc] modules like “Debug” and “Miner”

Cost Control: Is the cost of validation manageable? (The committee/community will not spend a significant amount of time on validation.)

Every node operator will be able to see this new community bootnode among their network connections.

Current State vs. Funded Work

I’m already on site and have researched the best hardware to purchase. Internet service will be set up in early October, with monthly fees. Electricity is billed monthly and is already available. If fiber-optic service becomes available, the connection will be upgraded. Anycast-DNS-Provider test Account registered.

(Spark v1 “Atlantic node” at talk.nervos .org/t/spark-program-atlantic-community-full-node)

xingtianchunyan · August 27, 2026, 1:45am

Hi @NNCBN ，

Thank you and @knmo for your continued interest in the Spark Program and for submitting the “NNCBN - Nervos Network Community Boot Nodes” proposal.

After review by the Spark Program committee, your proposal has been assigned a status of Pending. This is not a rejection, but an invitation to revise.

The committee recognizes the value of community-operated bootnodes for improving network diversity, redundancy, and transaction propagation. However, the current proposal needs to be adjusted to fit Spark’s scope and to clarify several operational details.

Main Revision Recommendations:

Scope and budget:
Spark does not provide long-term support, so a one-year operation plan is beyond Spark’s scope. The committee can offer up to 1080 USD, covering the hardware and the first quarter of operation. The committee believes that with the preliminary data, conclusions, and reports generated by the project in the first quarter, it not only meets Spark’s POC MVP requirements but also provides evidence for applying for longer-term funding in the future. Please revise the project scope to a Spark-compatible bootstrap phase. For continued operation after this phase, you may consider applying to other funding sources, such as the Community Fund DAO.
Deliverable definition:
Please clarify the concrete form of the deliverables. For example, will the deliverables be a live bootnode endpoint, a publicly maintained list of community bootnodes, operational documentation, monitoring reports, or a combination? Please define the acceptance criteria for each deliverable, specify which stage counts as successful delivery, and identify the point at which the project enters maintenance status. This will also determine the milestone at which the majority of funds can be released, with the remaining time funded as maintenance.
Hardware handling after the project ends:
Please specify what will happen to the hardware after the project ends, such as decommissioning, transfer to a community maintainer, or continued operation under another funding model. Note that hardware costs will be reimbursed only after review against strict and clear criteria; the committee will verify the relevant report before releasing hardware payments.
Payment schedule:
Per Spark practice, the payment will be structured as: 20% startup payment; after one month of operation, the committee will review the report and then pay the hardware cost plus the first month’s operation cost; after the second month concludes, the remaining balance will be paid. Please align your milestones and deliverable definitions with this schedule, and clarify how the first-quarter support period is covered by these payments.

Please revise and resubmit based on the feedback above. We will arrange a new round of review as soon as possible.

Best,
xingtian
On behalf of the Spark Program Committee

cc: @Hanssen @yixiu.ckbfans.bit @zz_tovarishch

NNCBN · August 30, 2026, 12:42pm

Thank you for your patience and for recognizing the value of this idea for improving decentralization at a key point in the network structure.

Scope and budget

Based on the feedback, I have revised the project to be a three-month, Spark-compatible bootstrap phase rather than a one-year operational plan.

Since the hardware cost will be reimbursed only after review, I propose defining the first month as a preparation and deployment-readiness phase. During this phase, I would complete the technical planning, hardware specification, configuration plan, documentation, and social media setup, including potential ideas for community incentives. I will also file a CKBA – Contributing Member Application as an infrastructure operator.

The description of Qubes OS, the operating system I intend to use, specifies a minimum of 16 GB of RAM and recommends 32 GB. After conducting more detailed initial research, I had to revise my original assumption that 16 GB would be sufficient. To ensure the network node’s intended long-term uptime, it will be equipped with 32 GB of RAM.

We are currently experiencing a period in which the number of network nodes visible on nodes.ckb.dev has decreased. At present, 599 nodes are still visible. Operating reliable and accessible network nodes requires hardware monitoring, software updates, and network monitoring. In particular, boot nodes—which serve as the first point of contact for newly installed network nodes—should always have sufficient performance reserves. Processing transactions on a daily basis, maintaining connections to other nodes, and reading from and writing to the blockchain should not overload the network nodes. During periods of high demand or increased requirements, there must still be sufficient room for growth in order to respond flexibly to fluctuating demands.

I understand if the committee is unable to approve a higher amount for the hardware purchase based on this justification. If it is able to do so, however, the second payment for the hardware should be increased from $744 to $944. This would bring the total amount to $1,280. Thank you very much.

Deliverable definition

Live boot node operation would begin once the required hardware has been funded and acquired. Live operation is conditional on hardware availability. The project’s first phase will focus on preparation and deployment readiness.

Milestone 1 – Preparation and deployment readiness

finalized hardware specification;
operational documentation plan;
CKBA – Contributing Member Application as an infrastructure operator;
creation of social media accounts;
draft ideas for community incentives.

The project then enters maintenance status while awaiting the release of the funding payment.

Milestone 2 – Live operation

hardware purchased;
configuration and security documentation completed;
synchronization completed;
ongoing social media activities;
monitoring activated;
boot node deployed and publicly reachable.

An investigation into which nodes already operating on the network are accessible under a single IP address in a region that is underrepresented among the total number of NervosNetwork nodes. It is possible that countries that make a significant contribution to the diversity of boot nodes are already represented. These are listed and used as a test for the initial synchronization of a node. Highly diverse boot nodes are identified as such and added to the list.

Milestone 3 – Maintenance and final reporting

continued operation during the remainder of the first quarter;
incident handling and routine maintenance;
final performance and monitoring report;
ongoing social media activities;
draft proposal for continued operation and community incentives under a DAO funding model.

3. Hardware handling after the project ends

continued operation, with the aim of establishing a DAO funding model;
continued use as a CKBA Contributing Member.

4. Payment schedule

Milestone 1 - October

$216 initial payment: 20% of $1,080

Milestone 2 - November

$744 for hardware

Milestone 3 - December

$120 for two months of operational costs: two payments of $60 for electricity and internet access.

xingtianchunyan · September 2, 2026, 5:04pm

Hi @NNCBN,

We are pleased to inform you that the Spark Program Committee has approved the NNCBN proposal, with a funding amount of 1280 USD (100% paid in CKB, 0.001012 USD/CKB, 1,264,822.13 CKB; $1280 * 100% @0.001012 = 1,264,822.13 CKB).

The committee recognizes the value of community-operated bootnodes for improving network diversity, redundancy, and transaction propagation, and appreciates your initiative to operate a node in a geographically underrepresented region.

Here are the next steps:

Complete the applicant information

According to the latest standards of the Spark Program, applicants must provide a link to a GitHub repository already created for the proposed project.
Funding & Payment Schedule

The total grant is 1280 USD (for the current cycle Spark grants are paid 100% in CKB). In light of the hardware cost increase, the committee has agreed to a phased disbursement to maintain incentive alignment and protect community expectations:
- First installment: 20% (256 USD) will be disbursed as soon as possible.
- Second installment: After the hardware platform is successfully set up, operated for one month, and approved by the committee, 50% of the hardware costs (based on actual expenses, capped at $550), plus the operating expenses for the following two months, will be reimbursed based on the actual amounts incurred.
- Final installment: The remaining hardware costs will be paid upon successful project completion.

Please confirm whether the CKB wallet address included in your proposal is the official address for receiving the funds.

Weekly Sync

We would like to establish a regular weekly synchronization mechanism, with two options:
- Text-based updates in this post, with progress updates at a fixed time each week and committee feedback in reply.
- Or a brief video call.
  Please let us know your preference and a convenient time.
Proposal Content Lock
- Once a proposal is approved, we will lock the current version of the proposal post as the reference baseline for subsequent delivery and acceptance. This is standard procedure for all approved Spark projects. If adjustments are needed during development, they can be discussed and documented during the weekly syncs.

Additionally, the committee suggests clearly documenting how this community bootnode complements the official nodes and public RPC infrastructure, as this will help the community understand its role and verify its impact.

Congratulations once again, and we look forward to your reply!

Best,
xingtian
On behalf of the Spark Program Committee

cc: @zz_tovarishch @yixiu.ckbfans.bit @Hanssen

NNCBN · September 4, 2026, 3:00pm

https:// github .com/NNCBN/

https:// github .com/NNCBN/NT-Spark

https:// github .com/NNCBN/Qubes

Text-based updates in this post, with progress updates at a fixed time each week.

This is more formal than video calls. It’s also more independent. I would set the official start date for the theoretical work as September 22, 2026—a little earlier than October. That way, I can post the first brief report here on the forum—which will be posted every Tuesday—on September 29, one week later. There may be some delays on my part in September and October, which I will communicate if they occur.

Thank you for your understanding and flexibility. This means the hardware could be up and running by around October 15, but may not yet have a stable, daily connection.

Yes, this is the correct address.

Thank you very much for this useful, specific tip. I don’t yet fully understand its significance, so I’ll need to look into this topic.

zz_tovarishch · September 8, 2026, 7:18am

Hi NNCBN, 你的Discord似乎不正确，无法添加好友

请告诉我能联系到你的DC，好邀请你加入DAO、Catalyst、Spark等项目开发者参与的Ecosystem Monthly Call，会议的邀请链接也会发送到你的邮箱

bootnode[ât]tutamail[dôt]com

xingtianchunyan · September 9, 2026, 5:58am

您好 @NNCBN ，

已确认你的GitHub仓库。

第一笔款项（252,965 CKB，20%）已拨付：

转账哈希：0x83046938e51022ee677a2aea78161330fde8f96d1ae33e2b0024711eed7520ca

请确认收款。

期待您的第一次进度更新。

此致
xingtian
代表 Spark Program 委员会

抄送：@zz_tovarishch @Hanssen @yixiu.ckbfans.bit

NNCBN · September 9, 2026, 5:55pm

The initial payment has been received.
Contact has been established on Discord.
The first steps toward procuring the hardware are already underway.

A meaningful Spark infrastructure grant and a launchpad for future DAO-funded operations in 2027.

xingtianchunyan · September 18, 2026, 2:37pm

Hello @NNCBN ,

We noticed that your first-week progress update has not yet been completed, so we are reaching out to learn about the latest developments with your project.

First of all, we hope that you and your team are doing well. Please be sure to take care of yourselves and maintain a healthy balance between work and rest.

From a project perspective, we would very much like to understand your current progress—whether hardware procurement and system installation are proceeding smoothly, whether you have encountered any obstacles, or what the overall status is at this point. Even a brief update would help keep the committee and community informed in a timely manner and allow us to provide support if needed.

Please share the latest progress as soon as convenient. If you encounter any difficulties that may affect the timeline, please let us know at any time—the committee is willing to provide any assistance needed.

We look forward to your response.

Sincerely,
Xingtian

NNCBN · September 19, 2026, 10:50am

The procurement process is taking longer than originally expected. I’m combining the hardware procurement with a trip abroad, since local suppliers don’t offer the specifications I’m looking for in this project. It will be a device with a Zen 5 Ryzen 9 370 HX processor and 32 GB of fast 8000 MHz RAM. This will serve as a network boot node with sufficient performance reserves for Qubes-OS. Unfortunately, delays can occur despite the originally generous timeline. The first report was scheduled for Tuesday, September 29.

NNCBN · September 29, 2026, 4:53pm

2026 September 29, First Weekly Report

The device has been ordered but has not yet been delivered. I am currently traveling abroad in Central Europe. It is possible to procure the appropriate hardware here. The device is a system with a newer-generation AMD CPU. Processors based on the Zen 5 architecture are equipped with native mitigations for known CPU vulnerabilities. This new Zen5 CPU is immune to attacks targeting known vulnerabilities. For older processors—which are still widely used today—current operating systems provide microcode to mitigate these vulnerabilities. Interestingly, tests have shown that disabling these software mitigations does not currently result in any performance gains.

It was important to me to use a next-generation processor for the boot node so that, in the event of any future exploits, we would have a node that is not affected. I refer to this as hardware diversification.

In addition, we aim to run an unconventional operating system, which can be viewed as software diversification. I still plan to install Qubes OS as soon as I have the hardware in hand. Perhaps there are already node operators who are implementing this kind of diversification for the network. I would appreciate any feedback or experience reports. However, cloud instances or affordable VPS providers are certainly the most common choices for running the network.I also chose a highly diverse location for the operation. A bare-metal device is being operated on an island in the Atlantic Ocean that is connected via the undersea cable between Portugal and Brazil. Low latency for very long-distance connections is already available here on the provider side. The “last mile”—that is, the connection from the provider to the end device—will be implemented via an end-user connection upon my return from my current trip.
Looking ahead, a higher-quality fiber-optic connection is planned. Locating the facility in a spot in close proximity to fiber-optic infrastructure would entail additional effort and costs, which I view as part of the DAO voting proposal for potential continued operation in 2027 and 2028. This expense cannot be considered part of this Spark program for the start of operations; rather, it is linked to long-term continued operation and the associated DAO coordination. I have already purchased a modem for use during the current Spark period—it is not a fiber-optic modem, but it will serve as a backup once fiber-optic service is established. This means the node can also have two Internet connections in case one of them fails.

Considerations regarding hardware procurement also took into account the specifications of the installed memory. There should be no shortage of RAM, as having sufficient RAM is important for the Qubes OS operating system, which is expected to run multiple templates. The decision was made to equip the system with 32 GB of LPDDR5X running at a fast 8,000 MT/s in dual-channel mode. The size and type of the storage drive are also important. A 1 TB TLC-NAND NVMe SSD with PCIe 4.0 was selected because SSDs should have at least 15–25% of free, unallocated space so that the SSD can manage its storage efficiently, which prevents unnecessary drops in write performance. TLC stores three bits per memory cell and offers a good balance of speed, durability, and price.

I’m currently using an old, underpowered device to temporarily synchronize a node so that I can quickly bootstrap it over the local network when the new hardware arrives. Initial attempts to log the node connections using Bash scripts are going well. A social media account was set up on X (formerly Twitter): Nervos Nodes (@NervosNodes) / X Unfortunately, the account I created there doesn’t have any followers yet, which apparently means that its reach is very limited. I’d love for CKB Nervos fans to follow my account, comment on my posts, and share them.

I have submitted my application for CKBA “Contributing Member” status. Node operators are an important part of the network. Looking ahead, it should be possible to implement incentives for node operators that promote network diversification. So if you’re in a country that currently has very few nodes, you can already synchronize your node and let it run to become part of the network. If incentives for operation become available, your node will already be ready to go. Here is a screenshot of the current situation as shown in the Nervos Explorer under “Nodes distribution by Country/Region.” If your region is part of a country where 0.17% of the network nodes are operated, you’re a good candidate to receive future incentives for operating a node. In this context, locations provided by VPN providers or VPS server providers are less important for diversification than bare-metal operators who host and maintain their own hardware on-site. An incentive system has not yet been specifically planned, developed, or implemented. It will most likely be part of the DAO vote on continued operations for 2027 and subsequent years.

In the next weekly report, I hope to be able to report on initial progress with hardware installation. As is already foreseeable, a report on on-site operations will be included in the weekly report on November 3, 2026, at the earliest.

NNCBN · October 6, 2026, 5:17pm

2026 October 06, Second Weekly Report

I received a response to my application to become a CKBA Contributing Member. The vote resulted in a decision against admission at this time. I will continue to work on the implementation so that a future decision will be more likely to be in favor of admission.

Plan for partitioning the 1TB hard drive: 80GB for the operating system, 360GB for blockchain storage, and 360GB for a backup of the blockchain storage. This results in 800GB divided into three partitions, plus 200GB of unpartitioned space to leave room for the SSD to operate.

Initial Description draft of Node Configuration

In the “ckb.toml” file, under “[network],” you’ll see the “listen_addresses” entry. It specifies the address of your Node computer and the port that should be forwarded between the router and the computer:

listen_addresses = ["/ip4/0.0.0.0/tcp/8115"]

The entry “0.0.0.0” is the standard address here; programs use it to access the computer on which they are running. This entry remains unchanged. Here you can also see the P2P port. A publicly accessible P2P port is important for running a boot node. Enter this P2P port in your router so that traffic is forwarded to the internal IP address of the CKB boot node computer. Also, check your operating system’s firewall: Make sure to allow incoming TCP connections on this port.

If you have a static public IP address, you can enter it there. Example:
public_addresses = [
"/ip4/47.110.15.57/tcp/8114/p2p/QmXS4Kbc9HEeykHUTJCm2tNmqghbvWyYpUp6BtE5b6VrAU"
]

To operate a boot node, it is important to enter a valid public address and specify the Nervos CKB node ID. If you have a fixed public address, enter it here. If the address or port is incorrect, other nodes will have difficulty connecting to your node.

With a dynamic IP address, a DNS name is more convenient:
[network]
public_addresses = ["/dns4/ckb.example.org/tcp/8115"]
To prevent routing issues, it’s best to assign a static IP address to your CKB bootnode computer in your router. ⁰

Be careful not to accidentally make the RPC service publicly accessible. Make sure not to configure the RPC port as a port forwarding rule in the router! If a publicly accessible RPC port is required, you should first set up a proxy to control the connections. This is not part of this description, so RPC requests are only possible locally on the CKB boot node computer, as is the case with the default settings.

You’ll need your unique “node_id” in the “public_addresses” line. (Here in the example QmXS4Kbc9HEeykHUTJCm2tNmqghbvWyYpUp6BtE5b6VrAU). To find your node_id, enter the following command in Linux:


curl -s \
  -H "content-type: application/json" \
  -d '{"id":1,"jsonrpc":"2.0","method":"local_node_info","params":[]}' \
  http://127.0.0.1:8114

The setting “bootnode_mode = false” should be changed to “bootnode_mode = true” for the long-term operation of a publicly accessible bootnode. This setting disconnects some of the connected peers after a random period of time to make room for new connections, since a bootnode should remain accessible to new nodes. If all available connection slots are permanently occupied by peers that are already connected, a new node may not be able to find a slot. When bootnode_mode is enabled, CKB monitors the number of connections. When the node approaches the configured max_peers limit, it randomly disconnects approximately half of the existing connections. This frees up slots for new incoming connections.

Twenty connections is a higher number than the default settings, but it should be adjusted based on the load on the existing connection.

xingtianchunyan · October 9, 2026, 1:32pm

Hi @NNCBN,

We have noted your sustained commitment to moving the project forward. After resolving the issues during the hardware preparation phase, you’ve delivered on time for two consecutive weeks and maintained a steady pace. Keep it up!

Best,
xingtian