Skip to content

Commit

Permalink
review comments
Browse files Browse the repository at this point in the history
Signed-off-by: Neeharika-Sompalli <neeharika.sompalli@swirldslabs.com>
  • Loading branch information
Neeharika-Sompalli committed Oct 18, 2024
1 parent e6958d8 commit b9e961a
Showing 1 changed file with 57 additions and 46 deletions.
103 changes: 57 additions & 46 deletions HIP/hip-1064.md
Original file line number Diff line number Diff line change
Expand Up @@ -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

<dl>
<dt>Judge</dt>
<dd>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.</dd>
<dd>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.</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>
<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>

**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.

```
/**
Expand Down Expand Up @@ -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";
Expand Down Expand Up @@ -190,25 +197,29 @@ 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

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)
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)

0 comments on commit b9e961a

Please sign in to comment.