I’ve worked with distributed systems for the past decade, and I’d like to ask some questions from that perspective:
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.)
One way to introduce diversity is using different node implementations. Will the zBI support Zebra as well as zcashd?
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.
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 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 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.
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.
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!
@john_akinyele, ZCG has voted to terminate this grant due to inactivity and/or a lack of responsiveness. Your grant will be removed from the old grants platform immediately and you will need to submit any future ZCG grant requests via Submittable. You are also eligible to submit a request to the ZF Minor Grants Program.
I would first like to tender my apologies for how this project turned out thus far. Especially with the lack of communicating the challenges that have been encountered. Sincerely, it became obvious that there was additional effort required in the development effort than previously anticipated. I understand and respect the decision that the board has taken. Over the weekend, I will take the time the provide details on the status of the project as well as the challenges faced. Nevertheless, the work will continue and will be eventually released to the community. That will give us enough time and opportunity to evaluate and decide on the next steps. I sincerely appreciate the opportunity and support given to this project.
The basis of this project was to create a platform to automate and orchestrate blockchain infrastructure. At its core, the idea is simple enough because it basically requires representing the required resources (storage, memory, CPU, network, and binaries) as Kubernetes artifacts and relying on the Kubernetes server for the necessary orchestration of these resources. However, this requires significant knowledge of Kubernetes and its architecture. Therefore, the design for this project was to abstract the details and knowledge of Kubernetes from end-users so they can focus on their primary concern – the secure operation of a zcash instance.
The original development effort was estimated to be 3 – 4 months, but we discovered some issues along the way
Secure Multi-user environment: The design for a secure multi-user environment necessitated the implementation of a security abstraction for the project. The effort to create this abstraction was underestimated and has resulted in the need for additional development time and resources.
Monolithic Approach: Unintentionally, the initial development effort led to a monolithic system due to an attempt to simplify the deployment process. As we continued the testing effort, it was identified that the implementation created a bloated system that may be a bit unwieldy. Consequently, we decided to re-factor the code base to appropriately separate concerns.
Cost Estimation: The plan for this project was to evaluate by implementing the product on AWS cloud infrastructure. While executing some preliminary testing, we identified that some of the initial cost estimations did not account for design changes along the way. In addition, while cloud providers allow the scaling of infrastructure as needed, this may lead to unplanned costs. Consequently, we introduced features into the design to prevent this situation. We also identified the need to perform extending capacity planning testing efforts to determine the appropriate footprint of a single zcash instance in this environment and its cost.
While such issues typically affect projects, we failed to communicate these challenges to the community which led to the decision to terminate the grant. We understand that this lack of communication is the real failure of the project. We make no excuses, but we will take stock and learn from this. Nevertheless, we plan to continue efforts to complete the project and release it to the community with the necessary documentation and guidance to execute it. We will also make a sample environment available on AWS to demonstrate its utility. Afterward, we will evaluate if there is an appetite to execute this project on an enterprise level for the community.
Once again, I appreciate the opportunity and support given to this project.