Gridcoin-research: Allow non-Windows clients to stake superblocks using Windows contracts

Created on 12 Apr 2018  路  3Comments  路  Source: gridcoin-community/Gridcoin-Research

Sometimes superblocks are delayed when the eligible Windows nodes are unable to stake a block due to high competition. One way of solving this is to implement the portable NN (#289) but this also increases the load of the BOINC servers. The portable NN is also quite a large task which will both take a while to implement and to test. In the meantime I propose a system where non-Windows nodes are able to stake superblocks using the contracts taken from an eligible Windows node.

Proposal

Whenever an eligible Linux node sees that a superblock is needed and that the Windows nodes have reached a consensus it randomly picks one of the eligible nodes, including Linux nodes, from its node list and asks it to send the contract along with the hash. If the hash matches the consensus the receiving node stores the data and includes it in its staked blocks. To avoid overloading the Windows nodes with contract distribution the Linux nodes will be able to propagate the contract.

I believe this will be a relatively small change compared to a full NN rewrite along with its side effects. We might even be able to write it without requiring a mandatory update.

Implementation

Contract distribution

There is already a neuralnet message which takes a command such as neural_data and neural_hash. This is used to distribute the data and the hash so each node knows what the others have. This can be utilized for _passive NN nodes_ to allow them to store and propagate the data further.

Hashes

We currently use MD5 as our hash. This is not considered secure and must be either changed to SHA256 or the SHA256 is included in the votes along with the MD5. If we only include it we will remain backwards compatible.

enhancement

Most helpful comment

Great idea to patch things up without too much work. Let me summarize how it would work:

any node:

  1. determines majority neural hash as normal
  2. has peer with the same neural hash as majority
  3. downloads neural data from that peer
  4. verifies the contract
  5. it is now technically in supermajority
  6. when stake include this neural data in the block ->superblock

Edit: It is important that the nodes who obtain the contract this way do not vote!

I think the vote counting should be changed, because currently latest vote has more weight than rest of the possible votes together.

The hash algo change could be introduced in the same mandatory and if scheduled outside of SB term, the transition will be simple (else some votes would get lost). But I do not think the hash algo is very high in the weakness list.

All 3 comments

I like this idea very much as a stopgap measure. Another idea for the future when we get the NN ported, is to create another stage in the process whereby a consensus round is done simply to pick which nodes will pull from the BOINC servers. This can be used to reduce the load on the servers while preventing centralization of the BOINC information pull.

Great idea to patch things up without too much work. Let me summarize how it would work:

any node:

  1. determines majority neural hash as normal
  2. has peer with the same neural hash as majority
  3. downloads neural data from that peer
  4. verifies the contract
  5. it is now technically in supermajority
  6. when stake include this neural data in the block ->superblock

Edit: It is important that the nodes who obtain the contract this way do not vote!

I think the vote counting should be changed, because currently latest vote has more weight than rest of the possible votes together.

The hash algo change could be introduced in the same mandatory and if scheduled outside of SB term, the transition will be simple (else some votes would get lost). But I do not think the hash algo is very high in the weakness list.

Fixed in 4.0.0.0.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ghost picture ghost  路  5Comments

tomasbrod picture tomasbrod  路  4Comments

Lenni picture Lenni  路  3Comments

kotenok2000 picture kotenok2000  路  5Comments

michalkania picture michalkania  路  5Comments