Daily rewards for active nodes

HIP/hip-1064.md

@@ -0,0 +1,227 @@
+---
+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: Draft
+last-call-date-time: 2024-04-08T07:00:00Z
+created: 2024-10-17
+discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/discussions/1063
+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.
+
+### 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>
+</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`
+
+## 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`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.
+
+```
+/**
+ * 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.
+
+```
+syntax = "proto3";
+
+package com.hedera.hapi.node.state.token;
+
+option java_package = "com.hederahashgraph.api.proto.java";
+// <<<pbj.java_package = "com.hedera.hapi.node.state.token">>> This comment is special code for setting PBJ Compiler java package
+option java_multiple_files = true;
+
+/**
+ * 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 in the 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 the 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 during a 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 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)