Spark Program | NNCBN - Nervos Network Community Boot Nodes

(Spark v2) Request for Financial Support

  1. Spark Program | NNCBN - Nervos Network Community Boot Nodes

  2. 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

  1. 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

  1. 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.

  1. 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.

  1. 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
  1. 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.

  1. 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.

  1. 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.

  1. 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)

4 Likes

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:

  1. 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.

  2. 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.

  3. 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.

  4. 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

2 Likes

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.

1 Like

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:

  1. 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.

  2. 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.

  1. 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.
  2. 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

4 Likes

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.

1 Like

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

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

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

2 Likes

您好 @NNCBN

已确认你的GitHub仓库。

第一笔款项(252,965 CKB,20%)已拨付:

请确认收款。

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

此致
xingtian
代表 Spark Program 委员会

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

2 Likes

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.

1 Like