As an engineer, the first time I was interested in Zcash, I looked for something similar to this. A script to get me started running zcash on local machines. All deps and configs taken care of, so that I can immediately experiment with available apis.
Zcashd can be run from the command line with an empty config file. Not sure I understand what script someone needs to run a node locally.
Zcashd with all the experimental features + lightwalletd and all the connection setup?
That’s still command line arguments, isn’t it?
The main pain is having to wait for blockchain download and sync. This proposal would help in that aspect AFAICT.
Thats how I read the proposal and agree it’s worthy of developing. The proposed solution is modern/up-to-date as far as I can tell.
I suggest given the security implications and given we’d only have 1 software eng and 1 devops eng on the project it might be nice to have another set of eyes over the code/solution. Not sure if someone at ECC or ZF can be lined up to assist but I’m also aware finding a security expert in both software and devops internally might be tricky. But maybe we’re not worried and the repo can just be flagged as “not-production-ready: no security audit/review”?
I’d like to hear from developers at ECC and ZF first to confirm nothing is/has been developed internally. Also I’d hope ECC/ZF are end users of this so we should hear from them to confirm they would indeed deploy/use this.
no idea about price but I’d be leaning positively
everything but this
Hi @john_akinyele it has come to our attention that your proposal is still in “draft” mode on the Grants platform.
Please fully submit it on the platform as soon as possible.
ZOMG member here:
I love the idea of zBI. I worked for years as the devops co-lead at the Ethereum Foundation where I saw the progression from people having to run their own node to robust automation of nodes. I also saw in the Ethereum ecosystem the need, that happened gradually, then all at once, for many nodes for users and businesses, to be automated with failovers, etc. for things like OpenSea and DeFi dapps.
I like that the approach isn’t overly engineered and follows what I consider best practices. If it’s open source that will be very helpful on people iterating on this.
I have some questions for the team:
- I would love for the git repos and documentation to be released as it is happening and not at the end (unless there is a reason I am missing why it should be hidden). Helps ZOMG track progress and encourages community participation. In your outline it appears to only be released after the whole thing is done.
- I’d like more information on the Control Plane (I wasn’t sure if Control Plane was an AWS thing or just a way to say control panel). Is it GUI? How granular to zcashd does it go as far as selecting commands?
- Has the zBI team talked to ECC/ZF about this to see if they already have deployment code?
- To what extent will the documentation include things relating to the safety of running certain node commands/features (RPC related security, DDoS protection, etc.)
In general something like this is very necessary for Zcash when it starts to gain traction with the possibility of ZSAs and programmability and in general I am in favor personally of this grant.
I approve the grant! (Although I have no power over ZOMG).
What’s next is offering Zcash full node as a service. Very few companies offer Zcash node services.
Even if that’s not the case, ZBI will help wallets, exchanges, hedge funds, custody providers easily run their own Zcash nodes as more investors/users onboard to Zcash.
Bonus points: As Zcash moves towards PoS in next few years, ZBI will help individuals spin up their own validators.
Please make it open-source as this is community funded.
It’d be interesting to know how much capacity we are getting for the price. How many zcashd nodes, how many lightwalletd.
Is it going to be like Infura? With them you get your own instance for your project.
+1 to Zifura
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
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’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.
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.