Chainpoint Network Reward Queue Rules

Glenn Rempe edited this page Nov 2, 2018 · 4 revisions

Queue Initialization

  • The rewards queue will be initialized with a set of healthy Chainpoint Nodes that have passed any 1 of the previous four audits.
  • This set of healthy Nodes will be rank ordered by created_at (descending, oldest last) and each will be assigned an initial audit score. The oldest Nodes at the end of the list get the highest scores.
  • All Nodes not selected as healthy at the moment of queue creation will receive an audit score of 0.

Queue Rules:

  • Every Node has an audit score (0 or >= 1)
  • On passing an audit, the score is incremented by 1
  • On failing an audit, the score is decremented by 1
    • Nodes with a score of 0 that fail an audit will remain at 0
  • Each reward period, a single Node will be randomly selected from the top 100. The set from which the top 100 are selected is rank ordered by audit score (descending), and secondarily by created_at date (ascending). This advantages older Nodes in the case of a tie.
    • The winning Node is sent a reward and its audit score is reset to 0
  • The audit score of a Node that stops advertising its public URI (a "private Node") will be decremented by 1 at the time of every audit so long as it remains private and until it reaches a score of 0.
  • The audit score of a Node that begins advertising its public URI (a "public Node") will be incremented by 1 at the time of every audit as long it passes all other audit checks.
  • The audit score of a Node that fails the daily end-to-end API functionality test will be decremented by 96 audit score points for each day that it fails the tests.

New Nodes:

  • Nodes that register after the creation of the reward queue will be initialized with an audit score of 0

Audit Rules

Nodes are periodically audited. To pass an audit, a Node must pass all of the following checks:

  • A Chainpoint Node must be successfully registered with the Chainpoint Network.
  • The software version of the Node must be greater than, or equal to, the current required version.
  • The Node must advertise a public_uri in its local configuration and its /config and other HTTP endpoints must be reachable at that address.
  • The reported system time of the Node must be within acceptable tolerances of the time as known to Chainpoint Core. It is highly recommended that all Nodes run their own NTP server, or the NTP container provided by standard Node setup.
  • The Node must calculate and respond correctly to a changing cryptographic challenge that verifies the correctness and completeness of its Calendar data.
  • The Node must continuously maintain at least the required minimum balance of TNT associated with the Ethereum address the Node is registered with.
  • The Node must pass a daily end-to-end API functionality test. This includes demonstrating its ability to receive hashes, generate proofs, and verify those proofs. Nodes will be given several opportunities to pass each phase of the test over the course of a full day. Nodes that cannot perform these critical functions will be considered to have failed all audits for a day.

Audits are currently conducted every 30 minutes. End-to-end API functionality audits are currently conducted once per day.

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.