A big part ZenCash is operating Secure Nodes. There is some work to be done to get this system running, and we are getting closer to that. Outlined below is the system and process we intend to follow to get this done.
Please read through, comment, add to, and discuss the high level specification outlined below.
The first step is to find someone to select as the software development project manager for the different Secure Node system below. Next would be for the project manager to get more specific software specifications written. After that, we can get proposals for development of the software application on ZenCash maintained servers.
Please DM me (BlockOps) if you are interested in providing a proposal for project management of development of the Secure Node system.
ZenCash Secure Node System Software Requirements Specification - Initial
Zen Nodes run the software that makes the ZenCash system work. Part of the ZenCash specification is to redirect 3.5% of the mining reward to the owners of ZenCash Secure Node which meet the requirements.
The purpose of funding secure nodes is not to reduce the amount of ZenCash available to the market with the intent of taking it out of circulation.
The purpose is to create a node network that is large enough and resilient enough to provide the foundation for a worldwide private communication and publishing system that is difficult to interrupt and gather data on.
The ideal would be 1000-5000 secure nodes, each running on a separate system, all over the world. The Zen Secure Node reward system has to be designed in a way that will prevent the operation of a large number of secure nodes on one server in one place.
The intent of this document is to create an overview specification for system that will enable Secure Node Tracking and Payment. The first level implementation is to get the basics of the system going so people can operate and be rewarded for running Secure Nodes. Over time the system can be improved to be more distributed, resilient, and automatic.
Each of the specific applications are intended to run on servers owned by the Zen Foundation, with operation. Each application will require a more specific software specification, as well as development.
Zen Secure Nodes require multiple applications running on different systems to operate. It involves the Zen nodes running software to monitor for and respond to a challenge. There are also applications running on systems that track the challenge, record it, and report. Furthermore, there are applications running on systems to authorize payment.
Zen team will contract for the development of the applications, which will be developed in an open-source manner with an MIT license.
List of System Applications:
A. Secure Node Challenge Publishing System (ChalPubSys)
B. Secure Node (SecNode)
C. Secure Node System Application (SecNodeApp)
D. Secure Node Response Tracking System (TrackSys)
E. Secure Node Response Reporting Server (ReportSys)
F. Secure Node Payout System (NodePaySys)
G. Secure Node Information System (NodeInfoSys)
H. Zen Block Explorer (BlockExplorer)
A - Secure Node Challenge Publishing System (ChalPubSys)
This is the system that generates the challenge. Anyone operating a secure node can monitor the challenge system and respond to it.
- Create and publish a challenge.
- Find a random transaction in the ZenCash blockchain
- Get the first address listed in the transaction
- Transaction number from above
- Due time 1 hour from when published
- Shielded address to send the response to
- Challenge sequence number
- Format of challenge publishing
- Publish in JSON format on specific port.
B - Secure Node (SecNode)
This is the actual secure node. It is a hardened server that runs the Zen node system software. It also needs to run the SecNodeApp software. It has to maintain a small amount of Zen on it to be able to send shielded transactions. It runs
1. Zen node software
2. SecNodeApp software, listed below
C - Secure Node System Application (SecNodeApp)
This is an application designed to operate on the same system as the Secure Node. It will check the ChalPubSys every minute. When a new challenge is published, it will take action and generate a Response, publish the Response, and send a Response Notification.
The action sequence would be:
- Detect a new Challenge has been published.
- Lookup the Response transaction and address required by the Challenge
- Create a text block with the following info in it:
- 12 byte hash of Response address
- Secure Node t_address
- Staking t_address
- Challenge Sequence number
- Encrypt the text block with SSL private key
- Publish in a JSON format on a specific port, including
- Encrypted text block
- public SSL certificate
Communicate the response published
- Send a shielded transaction (z_transaction) to the Response z_address containing URL of the Secure Node response in the memo field
D - Secure Node Response Tracking System (TrackSys)
This server receives the shielded transactions, analyzes them, and records them in a database.
Response documentation. Starts when challenge is posted, stops when response time limit is reached.
- Receive the shielded transaction, read memo field
- Get JSON information from the URL in the memo field
- Separate JSON data into elements, record elements into database
- If any of the elements are incorrect, put blanks in database.
After time that all responses have to be accepted, it stops looking at responses that come in until the next challenge is posted.
TrackSys validates the information in the database from the most recent challenge
Issues that this server needs to look for:
- Duplicate IP addresses - limit of 1 node per unique IP address per challenge
- Sequence number is old
- hash of response is wrong
- less than 42 zen in the staking t_address (use BlockExplorer to verify)
- If possible, verify the secure node shows up in the NodeInfoSys that it is using SSL to communicate with other nodes.
If a specific Staking t_address has a valid response for the time period, it updates a second database with the information
- Challenge number
- Staking t_address
- Node t_address
- Valid response
If a specific t_address has an invalid response for the time period, it updates a third database with the information.
- Challenge number
E - Secure Node Response Reporting Server (ReportSys)
This server will operate a web page that posts the information in the databases of the TrackSys. Pages:
- Information about each transaction as it comes in:
- Staking t_address
- Node t_address
- Response hash acceptable
- Information about the last challenge
- Number and List of secure nodes providing a valid response
- Number and List of secure nodes not providing a valid response
- Historical record of responses for each Node and Staking t_address since last payout period
F - Secure Node Payout System (NodePaySys)
This is the server that calculates the payment transactions to be made every payout period. Here’s how the payout is calculated
- Total number of valid responses in last week
- Total number of ZenCash blocks solved in last week.
- Payout per valid response = (Total Blocks) * (0.4375) / (Valid responses)
- t_address payout = (Valid responses in period) * (Payout per valid response)
Here’s how the payment can be done:
- Create a file with all the payment transactions in it.
- Provide a total amount needed to the Secure Node Payment address. Pay from a multisig address (2 of 5)
- Treasury person transfers ZenCash to Secure Node Payment address
- Paymaster 1 goes to payment web page and enters private key
- Paymaster 2 goes to payment web page and enters private key
- Payment transaction to Secure Nodes is done.
Web page is updated with information with list of Secure Node Payments for the period.
G - Secure Node Information System (NodeInfoSys)
This server maintains a count and identification of all the Zen nodes it can find. It figures out which ones are operating with a valid SSL certificate. Operates a web page providing information
1. Graph of Zen Nodes over time[m]
2. Graph of Zen Secure Nodes over time
3. Searchable list of all Secure nodes
H - Zen Block Explorer (BlockExplorer)
Server running a full Zen node with entire Zen blockchain. This is a block explorer that searches the block chain by:
2. Block Number
3. Transparent Address
There will be issues that arise as the system is tested, with both internal and external sources. Some of the ones already identified are:
1. Spamming the shielded response address with garbage
2. Spamming the shielded response address with fake answers that invalidate real answers
3. Operating fake nodes
4. Operating lazy nodes
5. Centralized repository of all nodes and their IP address in server
Method of Development and Deployment
This document will start new thread on ZenCash forum. Zen team will discuss Zen community, listen to recommended changes, then update specification.
After specification updated, Zen team will request proposal for Secure Node system development project manager to manage the development of the system.
The ideal project manager for this development will have:
1. Successful open source software project management experience
2. Proven software development history
3. Experience with cryptocurrency development and maintenance.
After project manager is selected, more detailed software specifications will be written for each of the system applications, and proposals requested for the development and support (1 year) of one or more of the system applications.
Payment will be in ZenCash. Pricing for proposals can be made in either ZenCash or USD equivalent to ZenCash at time of payment. Intended payment schedule
1. Award - 30% of total
2. Testnet version running - 30% of total
3. System deployed and operating - 40% of
Operating System Example
At the beginning, a Challenge will be published daily. This can be increased in frequency as the system scales.
- Challenge is published by ChalPubSys (JSON format)
- Challenge Sequence Number
- Transaction number from the ZenCash blockchain
- Shielded address (z_address) to send response to
- SecNodeApp is running on a Zen Secure Node. It checks for a new challenge every minute. When it sees a new Challenge, it
- Creates a Response
- Challenge Sequence Number
- Response address (looked up from the transaction number)
- Secure Node identifier (Secure node t_address)
- Secure Node ZenCash staking info (Staking t_address)
- Encrypts the response using SSL private key
- Publishes SSL public key and Response (JSON format)
- Creates a z_transaction with Response URL in memo field and sends it to the Challenge Shielded Address
- TrackSys checks ZenCash blockchain for new responses. When it sees one, it:
- Reads the memo field.
- Gets the JSON information from the URL in the memo field
- Verifies SecureNode SSL public cert is valid
- Decrypts the Response with the SSL public cert
- Validates the Response is correct for the challenge
- Records the valid response for both the Node t_address and Staking t_address.
- When the Challenge period is complete, it stops checking for new responses and creates a list of Node and Staking addresses that provided a valid challenge .
- ReportSys updates it's data and presents it in a user readable web page.
- Information from TrackSys as each response comes in.
- List of successful Secure Nodes per valid Challenge sequence number
- Historical record of Challenges and valid Responses
- Process 1-4 continues for the duration of the 1 week period. When the week is over, NodePaySys calculates payouts based on formula above.
- The more successful Responses, the less each Secure Node is paid.
- Payment will be sent to the Staking t_address
- Payments will be made weekly.
Video Overview of Secure Node System - https://youtu.be/pgTPy4D27Yg