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