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.

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.

Purpose:
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.

General Description

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.

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

Publish

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

Zen node software

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

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:

Successful open source software project management experience

Proven software development history

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 schedule

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

Award - 30% of total

Testnet version running - 30% of total

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.

As the first step for decentralisation we’re going to plan on running multiple copies of each of the servers fronted by a DNS system that can check on server status. There’s different ways we can maintain copies of the databases between the servers in a publisher subscriber or cluster type model.

And similar things with the front-end web servers that are pulling from the back-end databases. We’ve got some experienced system administrators as part of the community that are used to operating resilient designs.

That’s why I’m calling it a secure node system and not just an application.

Even longer term would just like to have it run and have all the secured nodes themselves perform all the functions and consensus of tracking and payment.

Regarding a question on the slack of Dash Masternodes vs Zen SecureNodes

In my opinion, Dash has some systemic problems with their Masternodes that will cause issues in the future. I used to own five of them but now I only own one because the way things are set up are going to cause large volatility price swings for Dash. Because so much of the supply is locked up in their Master nodes anything that they do to change the staking requirement away from 1000 Dash will cause a sell-off on the market.

Also, the only people that get to vote on policy and proposals are the Dash Master node holders. That causes a bias towards maintaining that form of governance.

It is my understanding that two of the early Dash developers run businesses where they host other people’s Master nodes on concentrated systems. There is nothing I have against what they are doing, but if there is a concerted attack on the system it will take a lot of the master nodes offline at once.

Since Dash is going to be relying on their Master nodes for more of what they are doing with their instant send and private send functions in the future, that puts their system at risk. They will probably work their way through the significant upgrades they have planned without an issue, but the costs of running a node will go up as well.

With Zen secure nodes we are not looking to take a lot of the Zen off the market by having a large amount be required for a Secure node. Secure node owners are also not going to be the only ones participating in the governance system.

The main purpose of having Zen secure nodes is to have many distributed and hardened elements of the Zen Network to allow for private transactions and private Communications worldwide.

No sure if a typo, but section G, #3 call for payouts performed using “Payout per valid response = (Total Blocks) * (0.4375) / (Valid responses)”.

Wouldnt this mean that the more valid responses, the less you get paid.

On another note, I was curious as to the process for auditing the OS itself. I believe it is important to perform at least a daily audit for any open CVEs and produce a score, if the system goes below the score, it gets disconnected from the zen network. Something in the lines of OpenVAS or Lynis.

Well yes the amount of payment will depend on the amount of valid responses. The more secure nodes that are running and the more they can meet the response properly the lower the overall payout is her response.

Regarding the security of the operating system I guess we’d have to look at what would be the nature of the problem if the operating system wasn’t secure. I think as long as the Node software is passing along valid transactions and using a valid SSL certificate the operating system itself might not need to be as secure.

In the original design we were thinking to make the operator put the Zen on the Node itself and be responsible for maintaining security but I think we can have the owner of the secure node keep the Zen on his or her own wallet and merely tell the node what the transparent address that is staking the 42 Zen is.

Rather than publishing on a web page this should be available in JSON format thorugh a web server (may be that is what was meant). It will be read by software rather than people.

C - SecNodeApp - much like above, the SecNodeApp could make the challenge result available as JSON. I would also think a full web server operated on the node is overkill and contradicts the hardening requirement by incereasing the attack surface. The SecNodeApp can listen on a port and only accept connections from the TrackSys addresses, TLS authenticate connections and respond with the JSON over HTTPS. I am operating such small apps written in perl (using Perlbrew, Dancer2, etc.), it should be perfectly possible in Python as well, possibly even easier.

D - NodeInfoSys - How will this discover nodes? If it is possible to securely query connected clients with an RPC command that may be a way - i dont know. Otherwise some sort of ‘hello’ from the nodes might be needed. SecNodeApp could provide that for secure nodes.

E - TrackSys - I think allowing 3 nodes per IP is wrong and weakens one of the few ways (if not the only way) we have of ensuring nodes are distributed. SSL verification (pt. 5) should be perfectly possible.

Blockops:

If a specific t_address has an invalid response for the time period, it updates a third database with the information.

Challenge number

t_address

Reason

Not sure what would the ‘Reason’ field contain in the database with invalid responses. If the validity needs to be double checked/audited later, the invalid response should be stored there.

Blockops:

Maintain exactly 42 ZenCash in a t_address for each Secure Node

G - if payment is made to the node t_ address which holds the 42 zen, then possibly the requirement that the address should hold exactly 42 zen should be relaxed

Blockops:

Potential Issues

There will be issues that arise as the system is tested, with both internal and external sources. Some of the ones already identified are:

Spamming the shielded response address with garbage

To avoid spamming/ddos we could look at some form of proof-of-work ddos prevention mechanism. I think this is very important but don’t really have a solution atm.

This should be mitigated if node discovery is done over RPC commands through connected clients spidering. Not because RPC responses can’t be faked but because the host has to be a peer to get queried. Have no idea if that is possible and secure though.

Blockops:

Operating lazy nodes

If this becomes a problem a) the challenge response windown can be reduced b) intermittent responders can receive less payment

Thanks for the feedback - it makes sense to me to not run a full web server but instead publish the challenge as a JSON using the SSL cert on a specific port, both on the ChalPubSys as well as on the SecNodeApp

For the exactly 42 Zen per node. My idea was to maintain this on a user’s wallet on their own PC, not on the node. The SecNodeApp would send the user’s t_address in the response, but it would not be the same as the one on the node itself. It would not matter what the address of the node itself was, it would just need enough Zen on it to cover the transaction fees of sending the responses as shielded transactions.

I think we could totally eliminate this by generating the transaction id used in the challenge from the last block in the chain.

I.e.: ChallengeTXId = F(last block)

If a single TX is not enough multiple TX Ids could be generated from the last block. Someone needs to do the math to ensure that F(Block_i) generates evenly distributed results between 1 and i, but this would totally eliminate the need for a ChalPubSys.

I think we could use the text field of the z_address of a 42ZEN transaction to announce a new (potentially) secure node to the network.

As a result, NodeInfoSys and TrackSys could use the blockchain to poll and verify secure nodes by checking for transactions with a specially formatted text field that contains the FQDN of the node. During polling, the node will be able to prove it has a valid SSL certificate, provide the response to the last challenge it solved, etc.

1 - add openSSL to Zen node software - already in progress
2 - script to check for a new JSON information on a website. When it sees new JSON info, do a lookup, create a text block, publish text block on in JSON format, send a shielded transaction to an address - this is the software that runs on the Secure Node
3 - Centralized server based applications that:

publish challenge

read shielded transaction with JSON URL

get data from JSON url, check if response is valid

keep track of valid responses. Every week, total up the valid responses

run a payment process.

Centralized applications that report on the network - number of secure nodes, block explorer.

One other potential issue that I haven’t seen mentioned is a protection mechanism against a malicious secure node that is tracking user activity. If a user broadcasts a message through a malicious secure node, that node now has the IP of the user, and the data they sent. This could be mitigated by adding relay functionality to tunnel connections from users through other secure nodes randomly, similar to Tor. Using this approach, a secure node will never be able to see both the user IP address, and the data they are sending, at the same time. They will get one or the other at best.

Process as follows:

User selects X number of random secure nodes.

User connects to the first secure node.

User requests a relay through the first secure node to the second secure node.

User connects to the second secure node through the first secure node.

The connection process continues X times through random nodes.

User sends the message through the connection chain, broadcasting through the final exit node.

One problem that comes to mind is the linear labor required to run multiple secure nodes.
Is there a way to stake multiple secure nodes from the same wallet?

Otherwise, maintaining multiple secure nodes would be a huge pain for most.

For example:
I have 420 ZEN. I want to set up 10 secure nodes. Do I need to set up 10 wallets and monitor them all individually? Or can I just stake 420 from my single wallet and use the same t_address on each secure node? The latter seems necessary.

While working on the detailed specifications a few of the challenges had me rethink some of the proposed architecture. Please comment on this alternative approach and add any ideas or concerns you may have.

For clarity - you are saying a single (remote) node with 420 zen spread across 10 t-addresses in a single wallet.dat (‘the stake’) - then running 10 completely separate (preferably geographically separate) Secure nodes that hold NO ZEN
but point back to ‘the stake’ ???

I like the idea of this - especially utilising the method of loading ONLY the t-address (not the spending key) on the secure nodes wallet.dat for view-only access and ensuring that even a breach on the secure node server would not expose the zen stake to attack.