-
Notifications
You must be signed in to change notification settings - Fork 143
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge branch 'main' into hip-991-update
* main: Daily rewards for active nodes (#1064) HIP-980: Add shadow fork support as a rejected idea (#1058) Update HIP-904 status and HSCS details (#1080)
- Loading branch information
Showing
3 changed files
with
336 additions
and
44 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,225 @@ | ||
| --- | ||
| hip: 1064 | ||
| title: Daily Rewards For Active Nodes | ||
| author: Neeharika Sompalli <@Neeharika-Sompalli> | ||
| working-group: Leemon Baird (@lbaird), Richard Bair <@rbair23>, Michael Tinker <@tinker-michaelj> | ||
| requested-by: Hashgraph | ||
| type: Standards Track | ||
| category: Core | ||
| needs-tsc-approval: Yes | ||
| status: Last Call | ||
| last-call-date-time: 2024-12-11T07:00:00Z | ||
| created: 2024-10-17 | ||
| discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/discussions/1063 | ||
| updated: 2024-11-27 | ||
| --- | ||
|
|
||
| ## 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. | ||
|
|
||
| ### Terminology | ||
|
|
||
| <dl> | ||
| <dt>Judge</dt> | ||
| <dd>An event that wins the election to be made a judge. It must be a witness, and it will have tended to have been | ||
| gossiped to most of the other nodes quickly (otherwise it would have lost the election). An event reaches consensus | ||
| when it is an ancestor of all judges in a given round. The first round where that happens is its consensus round. | ||
| It’s a math theorem that every round is guaranteed to have at least one judge, and a math conjecture that every round | ||
| is guaranteed to have judges created by a supermajority of nodes (>2/3 of weight).</dd> | ||
| <dt>Active Node</dt> | ||
| <dd>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.</dd> | ||
| <dt>Staking Period</dt> | ||
| <dd>Staking rewards are currently recalculated once per day, though this duration is a setting called the | ||
| "staking period". Node rewards will be transferred on the same schedule. Everywhere that this document mentions | ||
| a "day", it should be interpreted as the staking period. And every time calculations about a fraction of rounds | ||
| are done, they are the average over a single staking period.</dd> | ||
| </dl> | ||
|
|
||
| ## Motivation | ||
|
|
||
| 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. | ||
|
|
||
| ## 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 user of the network, I expect that non-active nodes do not receive any rewards | ||
|
|
||
| ## Specification | ||
|
|
||
| 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.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 synthetic `CryptoTransfer` transactions from | ||
| `ledger.fundingAccount` to each node account. Each synthetic `CryptoTransfer` only allows `ledger.transfers.maxLen` | ||
| transfers per transaction; it is possible, therefore, that multiple synthetic `CryptoTransfer` transactions 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. | ||
|
|
||
| ``` | ||
| /** | ||
| * A consensus snapshot.<br/> | ||
| * This is a snapshot of the consensus state for a particular round. | ||
| * | ||
| * This message SHALL record consensus data necessary for restart | ||
| * and reconnect. | ||
| */ | ||
| message ConsensusSnapshot { | ||
| .... | ||
| /** | ||
| * A list of SHA-384 hash values.<br/> | ||
| * The hashes of all judges for this round. | ||
| * <p> | ||
| * This list SHALL be ordered by creator ID.<br/> | ||
| * This list MUST be deterministically ordered. | ||
| */ | ||
| repeated bytes judge_hashes = 2 [deprecated=true]; | ||
| .... | ||
| /* | ||
| * A list of judges. | ||
| * This list SHALL be ordered by creator ID.<br/> | ||
| * This list MUST be deterministically ordered. | ||
| */ | ||
| repeated Judge judges = 6; | ||
| } | ||
| /** | ||
| * A judge information | ||
| */ | ||
| message Judge { | ||
| /** | ||
| * The creator node ID who created this judge. | ||
| */ | ||
| uint64 creator_id = 1; | ||
| /** | ||
| * SHA-384 hash value of this judge | ||
| */ | ||
| bytes judge_hash = 2; | ||
| } | ||
| ``` | ||
|
|
||
| - 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. | ||
|
|
||
| ``` | ||
| /** | ||
| * A record of node "active" status.<br/> | ||
| * This is used to record the number of "active" nodes in a staking | ||
| * period based on number of judges each node created in that period. | ||
| * | ||
| * A Node SHALL be considered "active" if it produced "judges" according | ||
| * to the consensus algorithm in a percentage of rounds, during the | ||
| * staking period, greater than the network configuration value for | ||
| * `nodes.activeRoundsPercent`. | ||
| */ | ||
| message NodeRewards { | ||
| /** | ||
| * A number of rounds so far, in this staking period. | ||
| */ | ||
| uint64 num_rounds_in_staking_period = 1; | ||
| /** | ||
| * A list of node activities.<br/> | ||
| * This records the number of rounds when each node created | ||
| * judges for the consensus algorithm. | ||
| * <p> | ||
| * This list SHALL contain one entry for each node participating | ||
| * in consensus during this staking period. | ||
| */ | ||
| repeated NodeActivity node_activities = 2; | ||
| } | ||
| /** | ||
| * A record of judge rounds for a single node.<br/> | ||
| * This records, for a single node, the number of rounds so far, during this staking | ||
| * period that contained at least one judge created by that node. | ||
| * | ||
| * This message SHALL NOT record the total number of rounds in a staking | ||
| * period.<br/> | ||
| * This message SHALL record a count of rounds for a single node.<br/> | ||
| * This message SHALL contain the number of rounds that contain at | ||
| * least one judge from the node identified. | ||
| */ | ||
| message NodeActivity { | ||
| /** | ||
| * A node identifier. | ||
| */ | ||
| uint64 node_id = 1; | ||
| /** | ||
| * A count of rounds.<br/> | ||
| * This is the count of rounds so far, in this staking period in which the node identified | ||
| * by `node_id` created judges. | ||
| */ | ||
| uint64 num_judge_rounds = 2; | ||
| } | ||
| ``` | ||
|
|
||
| ## 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. | ||
|
|
||
| ## Security Implications | ||
|
|
||
| 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. | ||
|
|
||
| ## 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". | ||
|
|
||
| ## 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) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.