From b9e961a7c442f45a4bf5a68711b45fa393c64a7f Mon Sep 17 00:00:00 2001 From: Neeharika-Sompalli Date: Fri, 18 Oct 2024 11:40:25 -0500 Subject: [PATCH] review comments Signed-off-by: Neeharika-Sompalli --- HIP/hip-1064.md | 103 +++++++++++++++++++++++++++--------------------- 1 file changed, 57 insertions(+), 46 deletions(-) diff --git a/HIP/hip-1064.md b/HIP/hip-1064.md index 4f71aa3ed..2c5b613ee 100644 --- a/HIP/hip-1064.md +++ b/HIP/hip-1064.md @@ -16,71 +16,76 @@ updated: 2024-10-17 ## Abstract -This HIP proposes a reward mechanism that will incentivize nodes to remain active on the network. The definition of active node is described below. The minimum reward per day for nodes will be a configurable property decided by the governance of the deployed network. This minimum reward may be adjusted based on fees already paid throughout the day. +This HIP proposes a reward mechanism that will incentivize nodes to remain active on the network. The definition of +active node is described below. The minimum reward per day for nodes will be a configurable property decided by the +governance of the deployed network. This minimum reward may be adjusted based on fees already paid throughout the day. ## Motivation -The goal is to give a strong incentive for node operators to keep them active and properly configured throughout every staking period. +The goal is to give a strong incentive for node operators to keep them active and properly configured throughout every +staking period. ## Rationale -Clearly defining the criteria for node activity, we can ensure that rewards are distributed fairly, incentivizing nodes to remain active and contribute to the network’s stability and growth. +Clearly defining the criteria for node activity, we can ensure that rewards are distributed fairly, incentivizing nodes +to remain active and contribute to the network’s stability and growth. ### Terminology
Judge
-
In the hashgraph algorithm, honest nodes that are online and contributing to consensus will regularly create unique famous witnesses, called judges, in nearly every round.
+
In the hashgraph algorithm, honest nodes that are online and contributing to consensus will regularly create unique +famous witnesses, called judges, in nearly every round.
Active Node
-
A node is an *Active Node* if it creates a "judge" in a significant fraction of rounds during a staking period, for example 80%. Any node that is trustworthy and submits events will create judges. If the node doesn’t submit events or when other nodes don’t build on this node’s events, the node will not create judges.
+
A node is an *Active Node* if it creates a "judge" in a significant fraction of rounds during a staking period, +for example 80%. Any node that is trustworthy and submits events will create judges. If the node doesn’t submit events +or when other nodes don’t build on this node’s events, the node will not create judges.
**User Stories** The implementation will be tested under various scenarios, including: -- As a node operator, I expect to receive at least a minimum node reward when the - node is active for at least `nodes.activeRoundsPercent` rounds -- As a node operator, I do not expect to receive any node rewards when the node - is not active for at least `nodes.activeRoundsPercent` rounds -- As a network operator, when `nodes.adjustNodeFees` is set to true, I expect - each node reward to be reduced by the average node fees already collected - during that period. -- As a network operator, when `nodes.adjustNodeFees` is set to false, I do not - expect each node reward to be reduced by the average node fees already - collected during that period. -- As a network operator, I expect each active node to receive at least a - minimum reward defined by `nodes.minNodeReward` +- As a node operator, I expect to receive at least a minimum node reward when the node is active for at least + `nodes.activeRoundsPercent` rounds +- As a node operator, I do not expect to receive any node rewards when the node is not active for at least + `nodes.activeRoundsPercent` rounds +- As a network operator, when `nodes.adjustNodeFees` is set to true, I expect each node reward to be reduced by the + average node fees already collected during that period. +- As a network operator, when `nodes.adjustNodeFees` is set to false, I do not expect each node reward to be reduced + by the average node fees already collected during that period. +- As a network operator, I expect each active node to receive at least a minimum reward defined by `nodes.minNodeReward` ## Specification -There will be three configurable properties added, which can be changed using `FileUpdate` transaction signed by the governance of the deployed network. +There will be three configurable properties added. -- `nodes.minNodeReward` : A minimum daily node reward amount. Each node SHALL - receive at least this many tinybar each day that the node is "Active". -- `nodes.adjustNodeFees` : A flag to adjust node fees. If this is set, the - network SHALL reduce the rewards given for a staking period by the average - node fees already collected during that period. +- `nodes.minNodeReward` : A minimum daily node reward amount. + Each node SHALL receive at least this many tinybar each day that the node is "Active". +- `nodes.adjustNodeFees` : A flag to adjust node fees. + If this is set, the network SHALL reduce the rewards given for a staking period by the average node fees already + collected during that period. - `nodes.activeRoundsPercent` : A percentage value relating to active nodes. - A node MUST create a judge in at least this percentage of rounds to be - considered active. This is set to 80% by default. - -The reward SHALL be adjusted based on average fees paid for all nodes when -`staking.fees.adjustNodeFees` is true. Each node is paid the constant reward -minus the average node fees received that day. This reduction is averaged -across all nodes; the network SHALL NOT subtract the node fees earned by -one node in particular. - -The node rewards SHALL be distributed at the end of a staking period using -`CryptoTransfer` transactions from `ledger.fundingAccount` to each node -account. Each `CryptoTransfer` only allows `ledger.transfers.maxLen` -transfers per transaction; it is possible, therefore, that multiple -`CryptoTransfer` transaction will be necessary to distribute rewards, -based on the total number of node accounts in the network. + A node MUST create a judge in at least this percentage of rounds to be considered active. + This is set to 80% by default. + +The reward SHALL be adjusted based on average fees paid for all nodes when `staking.fees.adjustNodeFees` is true. +Each node is paid the constant reward minus the average node fees received that day. +This reduction is averaged across all nodes; the network SHALL NOT subtract the node fees earned by one node in +particular. + +The node rewards SHALL be distributed at the end of a staking period using`CryptoTransfer` transactions from +`ledger.fundingAccount` to each node account. Each `CryptoTransfer` only allows `ledger.transfers.maxLen` +transfers per transaction; it is possible, therefore, that multiple `CryptoTransfer` transaction will be necessary to +distribute rewards, based on the total number of node accounts in the network. This HIP modifies the following state protobufs. -- Currently PlatformState’s ConsensusSnapshot contains information about the `judge_hashes`. But, it doesn’t provide the creator ids. We will deprecate the existing `judge_hashes` and add a list of `judges`. Each `Judge` will include the creator node id and the judge hash for that node. Any node that didn’t create a judge in a round will not be present in the list. +- Currently, PlatformState’s ConsensusSnapshot contains information about the `judge_hashes`. But, it doesn’t provide + the + creator ids. We will deprecate the existing `judge_hashes` and add a list of `judges`. Each `Judge` will include the + creator node id and the judge hash for that node. Any node that didn’t create a judge in a round will not be present + in the list. ``` /** @@ -125,7 +130,9 @@ message Judge { } ``` -- To store the number of rounds in a staking period and the number of rounds in which each node created judges, a new singleton state `NodeRewards` will be added to `TokenService`. This singleton state will be updated at the end of every round. +- To store the number of rounds in a staking period and the number of rounds in which each node created judges, a new + singleton state `NodeRewards` will be added to `TokenService`. This singleton state will be updated at the end of + every round. ``` syntax = "proto3"; @@ -190,7 +197,8 @@ message NodeActivity { ## Backward Compatibility -Existing nodes will not require any changes to their software or configuration to be eligible for rewards, as long as they meet the active criteria. +Existing nodes will not require any changes to their software or configuration to be eligible for rewards, as long as +they meet the active criteria. ## Security Implications @@ -198,17 +206,20 @@ No known security concerns. ## How to Teach This -This HIP incentivizes node operators for keeping the node active by guaranteeing a minimum reward in the periods that they accomplish this. +This HIP incentivizes node operators for keeping the node active by guaranteeing a minimum reward in the periods that +they accomplish this. ## Rejected Ideas - We considered using the number of transactions submitted by a node to assess node activity. - - This was rejected in favor of counting rounds with judges because the latter - approach incorporates consensus network assessment of node "honesty" and - is more "fair". + - This was rejected in favor of counting rounds with judges because the latter + approach incorporates consensus network assessment of node "honesty" and + is more "fair". ## Reference Implementation ## Copyright/license -This document is licensed under the Apache License, Version 2.0 -- see [LICENSE](https://github.com/Neeharika-Sompalli/hedera-improvement-proposal/blob/1cad867e75071dad048ec633e04e208ca242c0df/LICENSE) or (https://www.apache.org/licenses/LICENSE-2.0) \ No newline at end of file +This document is licensed under the Apache License, Version 2.0 -- +see[LICENSE](https://github.com/Neeharika-Sompalli/hedera-improvement-proposal/blob/1cad867e75071dad048ec633e04e208ca242c0df/LICENSE) +or (https://www.apache.org/licenses/LICENSE-2.0) \ No newline at end of file