Grant Idea - Zcash Blockchain Infrastructure (zBI)

I’ve worked with distributed systems for the past decade, and I’d like to ask some questions from that perspective:

  1. Cloning exactly the same deployment has security and reliability risks. What will zBI do to mitigate those risks?

In particular, every zBI node will have very similar security vulnerabilities. And if the zBI nodes are set to auto-update, one mistake can bring down all the nodes.

So we wouldn’t want any clone to be more than about 1/3 of the network, unless there was some node diversity (different cloud providers, different node software, etc.)

  1. One way to introduce diversity is using different node implementations. Will the zBI support Zebra as well as zcashd?

  2. Another way to introduce diversity is using different node versions. Will zBI nodes automatically update? Can users stay on older node versions? What will the defaults be?


There is no particular reason for this to be hidden. I agree it would be a good idea for the repos and documentation to be available from the beginning.

In container-orchestration systems, the concept of a control-plane is a piece of software with responsibility for managing the constituent components in the system. This concept is being extended (or borrowed) for this project. Basically, the control-plane (typically a REST API interface) will provide the functionality for launching and managing the nodes that are available. The project will include a web-enabled GUI.

I don’t understand this question. What deployment code are you referring to?

The documentation will include information of industry-standard patterns for security-related issues. Please, note that Kubernetes comes with standard patterns for such issues. We plan to demonstrate these patterns by running zBI on AWS Cloud in the testnet environment.

1 Like

The best way to view zBI is a platform/framework for automating the infrastructure required for running Zcash components. In our view, infrastructure constitues the containers in which the Zcash software will execute and the storage attached to them. The process of “starting” a node will include defining which zcash software to execute, but it is up to the system implementors to define the allowed source of such components. Deployments will be represented similarly, but each node will be isolated in it’s own container and only accessible to other nodes through a specified service interface. There will be no concept of cloning deployments. Perhaps, the only type of cloning that may occur is the possibility of establishing the data volume for a new node with the blockchain data from a previous backup snapshot.

As an open-source project, developers in the community will have the opportunity to define which software components and versions will be used in their environment. In the platform we will make available in AWS cloud, we will provide a curated list of software components (for security purposes) and we are certainly open to accommodating interests from the community.

Our implementation will include a CI/CD pipeline that will be used to roll out updated versions based on our curated list. Users will be able to identify which version they wish to use.

Please, note that we are working on a detailed architecture for the project in which all supported features will be outlined.


I’m sorry, “cloning” was a confusing word to use.

I was asking if all zBI nodes will use exactly the same cloud provider, deployment infrastructure, container-orchestration system, firewall settings, OS, node software, and software version.

In a distributed system, having a lot of identical nodes is very risky, because a common vulnerability can result in network-wide downtime or exploits.

What steps will zBI take to encourage users to vary node deployments?
Will you support multiple cloud providers, container-orchestration systems, or OSes?

(It’s ok if the answer is “no” - but we’d want to limit identical zBI nodes to a small fraction of the network.)

How will you test zBI?
Will it be tested with both Zebra and zcashd?

Will you recommend a default node software version or implementation?
What steps will zBI take to encourage users to vary node software?

I’m thrilled to announce that ZOMG has voted to approve of this grant! The Zcash Foundation will be following up with next steps.


Hello All,

I am happy to announce that Alphega Solutions has requested and received the payout for the first milestone of this project. We will commence with the initial phase of the project. We also plan to start a blog series to report on the progress.


Project Updates

  1. Domains
    a. Website - Site design and implementation in progress
    b. App Domain -
  2. GitHub Repo - Zcash Blockchain Infrastructure · GitHub
  3. AWS account
    a. Development account created
    b. AWS Infrastructure Purchase - in progress
  4. App Development - in Progress

Hi John, I am interested to know if ZBI when released will allow users to operate without a light-walletd? Or is the lightwalletd necessary? Thanks

Yes. The idea is for users to operate their node of choice. However, I should point out that operating a light-walletd will require a backing zcash node.

Project Updates

  1. Control Plane:
    Coding: 80% Complete
    Unit & Integration Testing: 80% Complete
  2. Dashboard
    Coding: 70% Complete
    Unit & Integration Testing: 70% Complete
  3. Perfomance Testing
    Planning in Progress
    Expected Start Date: Late October

Hey @john_akinyele ! I just moved almost all of free2z to k8s and I was thinking about moving my zcashd there as well and I remembered your project. Glad to see it’s progressing. Can you share any resources that might help me run zcashd on k8s? Thanks!