Questions about rewards after version 1.4.19

Node Running
,
1

We all know that after version 1.4.19, the VDF calculation and proof information for rewards are stored locally in the store file. There are serveral points that I think folks might be confused about:

  1. What is the total amount of rewards after version 1.4.19, and how is the supply controlled? If there are an infinite number of nodes spinning up, would it lead to a significant increase in supply, which does not fit our issuance curve?
  2. How do we prevent malicious activities in this case? Because I’ve seen many nodes running without a network still getting rewards, does this lead to a Sybil attack problem, and how do we handle these malicious nodes?
  3. How are rewards claimed after version 1.4.19? Is it done by submitting proof information on a claim webpage until exhaustion to claim the rewards? How to prevent cheating?
2
  1. Going off of live data (and even giving a multiplier to node count), we’re still well in line for issuance under 2.0 PoMW curve. An infinite number of nodes requires an infinite amount of capital to run those nodes, given network growth and timeframe involved we’re not at risk to run into unbounded supply increases for this period.
  2. The proof itself is the prevention – we’re fighting two issues that are blockers for 2.0 release: message propagation and memory consumption. As a consequence, these are not considered in scope of the proofs, so orphaned nodes are free to continue producing proofs during this time. The proof is strictly linearized in nature – because there is no way to produce sequence proofs in parallel and proofs are bounded to the peer id of the proof producer, the winning strategy is to keep a single lineage of proofs running.
  3. Reward claiming will be fully outlined alongside 2.0, it is not using a centralized claim page, but rather is protocol-bound. The simple synopsis is that there will be a period of time in which these proofs can be claimed at the start of the 2.0 network, it will be part of the validator registration process, and once that claim process begins it is locked in at the increment provided (e.g. a peer claiming and registering as a validator, or just claiming if disinterested, submits the last increment generated with a signature of the peer id to begin the claim/registration, and walks backwards through the proofs to produce the final proof to claim and join the network as a validator)
3 Likes