Performance Based Node Rewards

Governance
11

Hi all,

Following up on the topic of performance based node rewards, I would like to share suggestions on the handling of nodes which are not assigned to a subnet.

Background & Goals

The overall aim is to link node rewards to performance on the Internet Computer Protocol. Trustworthy metrics (block maker success rates) can be used to measure performance for nodes assigned to subnets. Unassigned nodes lack trustworthy metrics as they do not participate in the protocol.

Goals:

  • Ensure node providers are incentivized to maintain operational standards for all nodes, assigned or not.
  • Nodes which are completely offline, should face higher penalties compared to online nodes (or even no rewards at all).
  • Focus should be on getting incentives right, rather than reducing the overall inflation.

Analysis - Overview of Node Health Status

As of September 26, 2024, data from the IC dashboard show a total of 1402 nodes categorized as follows:

  • UP (assigned to a subnet),
  • UNASSIGNED (online but not assigned to a subnet),
  • DEGRADED (online with at least one monitoring alert), and
  • DOWN (offline).

Initial observations:

  • 40% of nodes are assigned to subnets, with the remaining 60% being unassigned, degraded, or offline. Please note, that the assignment ratio would increase with the creation of additional subnets as recently suggested in this post.
  • In total 1465 nodes get rewards and thus there is a delta of 63 to the nodes in the registry/dashboard. This means, 63 nodes which are not in the registry receive rewards.
  • Almost all node providers have at least one node being assigned.

The following four charts show a breakdown of node health status by node provider, sorted by node count.

856×424 28.5 KB

856×424 26 KB

856×424 27.4 KB

|960px;x476px;
|960px;x476px;856×424 23.7 KB

Suggested Measures

Measure #1: Unregistered nodes

Proposal:

  • Nodes not listed in the current registry cannot be assigned to subnets, contributing no value to the protocol.
  • Hence, it suggested that nodes which are not registered at all in a given reward period should not receive rewards.
  • This could be implemented via an automated check at the time of the reward calculation.

Impact:

Currently at least 63 nodes receive rewards but are not registered (4.3% of 1465). Assuming an average reward rate of 1.5k per node, this would lead to an overall reduction in node rewards of 94K XDR.

Measure #2: Performance extrapolation

Proposal:

  • The current node assignment ratio is 40% and thus we cannot have all nodes assigned, but at least one/some node per node provider.
  • In case that a node is assigned and unassigned during a reward period, then the node would receive a score derived from the assigned period.
  • The average performance score of a provider’s (partially) assigned nodes will be applied to all their completely unassigned nodes.
  • For providers with four or more nodes, if none of their nodes are assigned, a flat penalty of 80% (reward multiplier of 0.2) will be applied. This penalty matches the maximum penalty for assigned nodes.

Impact:

The precise impact is to be estimated. Given the leniency of the reward penalty function, it is anticipated that most node providers will not be impacted.

Example Calculation:

1600×546 62.1 KB

Alternative to Measure #2: Malus/Bonus System (not suggested at the current stage)

Proposal

  • Currently, 40% of nodes are assigned to subnets, with the remaining 60% being unassigned, degraded, or offline.
  • As a starting of a malus/bonus system, we make the assumption that the total reward pool size should remain unchanged. Based on this, one could apply a 60% bonus for assigned nodes and a 40% malus for others to maintain reward balance. One could also use alternatives with the same ratio, e.g. 30% and 20% (or 15% and 10%).
  • The approach could be implemented through the already proposed linear reward function for assigned nodes, allowing for a reward multiplier greater than 1 for nodes with high availability.

Assessment
This approach represents a broader modification to the node reward system. While it positively integrates the benefits of decentralization into reward calculations, it may also trigger numerous competing node assignment proposals due to incentives for having many nodes assigned. Therefore, while it could be beneficial, such a change might be better introduced as part of a more comprehensive overhaul at a later stage. Nevertheless, it is worth sharing this idea at this point for completeness.

Next Steps

We invite the community to provide feedback on the suggested measure #1 and #2 (and comments on the mentioned alternative to measure #2). In addition we suggest discussing this topic in the next node provider working group meeting.

4 Likes