Skip to content

Commit

Permalink
tokenomics edits
Browse files Browse the repository at this point in the history
  • Loading branch information
@serinko
serinko authored Dec 12, 2024
1 parent 2ab1721 commit fe2817c
Showing 1 changed file with 23 additions and 18 deletions.
41 changes: 23 additions & 18 deletions documentation/docs/pages/operators/tokenomics/mixnet-rewards.mdx
View file
Original file line number Diff line number Diff line change
Expand Up @@ -133,29 +133,33 @@ This is a quick summary, to understand the full picture, please see detailed [*R

### Rewarded Set Selection

For a node to be rewarded, the node must be part of a [Rewarded set](https://validator.nymtech.net/api/v1/epoch/reward_params) (which currently = active set) in the first place. The active set is selected in the beginning of each epoch (every 60min) where total of 240 Nym nodes - represented by 120 mixnodes and 120 gateways, are randomly allocated across the layers.
For a node to be rewarded, the node must be part of a [Rewarded set](https://validator.nymtech.net/api/v1/epoch/reward_params) (which currently = active set) in the first place. The Rewarded set is freshly selected at the start of each epoch (every 60 min), and it consists of 240 Nym nodes that are probabilistically chosen from all the available nodes. These 240 nodes include 120 gateways and 120 mixnodes (40 for each of 3 mixnet layers).

The algorithm choosing nodes into the active set takes into account these parameters:
Rewarded set nodes are randomly selected, and their selection chances increase with a node score that includes three parameters:

1. [Config score](#config-score-calculation)
2. [Performance](#performance-calculation)
3. [Stake saturation](../tokenomics.mdx#stake-saturation)
1. [Config score](#config-score-calculation): highest (`1`) when the node is running the latest version of the software with [T&C's accepted](../nodes/nym-node/setup.mdx#terms--conditions)
2. [Performance](#performance-calculation): highest (`1`) when the node is consistently online and correctly processes all the received traffic
3. [Stake saturation](../tokenomics.mdx#stake-saturation): including bond and delegated stake

Besides these values, the API is also looking whther the node is bonded in Mixnet smart contract as a Nym Node or legacy node (Mixnode or Gateway). **Only nodes bonded as Nym Node in Mixnet smart contract can be selected to the Rewrded set, if you haven't migrated your node yet, please [follow these steps](../nodes/nym-node/bonding#migrate-to-nym-node-in-mixnet-smart-contract)!**
Besides these values, the API is also looking whether the node is bonded in Mixnet smart contract as a Nym Node or legacy node (Mixnode or Gateway). **Only nodes bonded as Nym Node in Mixnet smart contract can be selected to the Rewrded set, if you haven't migrated your node yet, please [follow these steps](../nodes/nym-node/bonding#migrate-to-nym-node-in-mixnet-smart-contract)!**

**The Rewarded set selection probablity formula:**
**The node score is calculated with this formula:**

<Callout type="info" emoji="📌">
> **active_set_selection_probability = config_score \* ( node_performance ^ 20 ) \* stake_saturation**
> **active_set_selection_probability = total_stake \* ( config_score \* node_performance ) ^ 20 )**
</Callout>
Note that the score helps prioritize some nodes over others. If all available nodes have the same score, then the selection is done uniformly at random. By raising the config and performance components to 20, values of these parameters that are below one incur a heavy penalization for the node’s selection chances.

Besides these values, the API is also checks whether the node is bonded in Mixnet smart contract as a Nym Node or legacy node (Mixnode or Gateway). **Only nodes bonded as Nym Node in Mixnet smart contract can be selected to the Rewrded set. Thus, if you haven't migrated your node yet, please [follow these steps](../nodes/nym-node/bonding#migrate-to-nym-node-in-mixnet-smart-contract)!**

#### Config Score Calculation

The nodes selection to the active set has a new parameter - `config_score`. Config score currently looks into three paramteres:

1. If the node binary is `nym-node` (not legacy `nym-mixnode` or `nym-gateway`)
2. If [Terms & Conditions](../nodes/nym-node/setup.mdx#terms--conditions) are accepted.
3. Version of `nym-node` binary
1. If the node binary is `nym-node` (not legacy `nym-mixnode` or `nym-gateway`): `1` if `True`, `0` if `False`
2. If [Terms & Conditions](../nodes/nym-node/setup.mdx#terms--conditions) are accepted: `1` if `True`, `0` if `False`
3. Version of `nym-node` binary: decreasing weight for outdated versions, as explained below

**The `config_score` parameter calculation formula:**

Expand All @@ -174,10 +178,9 @@ First two points have binary values of either 0 or 1, with a following logic:

Only if both conditions above are `True` the node can have any chance to be selected, as otherwise the probability will always be 0.

**The `version_behind` parameter in `config_score` calculation**
**The `versions_behind` parameter in `config_score` calculation**

From release `2024.14-crunch` (`nym-node v1.2.0`), the `config_score` parameter takes into account also nodes version. Current version is the
one marked as `Latest` in our repository. From that one we count the parameter `version_behind`, where every version back the number of `versions_behind` increases by 1 in this formula:
From release `2024.14-crunch` (`nym-node v1.2.0`), the `config_score` parameter takes into account also nodes version. The "current version" is the one marked as `Latest` in our repository. The parameter `versions_behind` indicates the number of versions between the `Latest` version and the version run by the node, and it is factored into the config score with the formula:

<Callout type="info" emoji="📌">
> **0.995 ^ ( ( X * versions_behind ) ^ 1.65 )**
Expand All @@ -192,7 +195,9 @@ one marked as `Latest` in our repository. From that one we count the parameter `
Our versioning convention is: `major_version . minor_version . patch`

For example `nym-node` on version `1.2.0` is on 1st major version, 2nd minor and 0 patches. See the the table and graph below:
For example `nym-node` on version `1.2.0` is on 1st major version, 2nd minor and 0 patches.

Note that the `X` multiplier heavily lowers the `config_score` when nodes are outdated with respect to more significant updates. See the the table and graph below:

| **Version behind** | **Patches (X = 1)** | **Minor versions (X = 10)** | **Major versions (X = 100)** |
| :-- | --: | --: | --: |
Expand All @@ -212,12 +217,12 @@ As you can see above, the algorithm is designed to give maximum selection score

Performance is measured by Nym Network Monitor which sends thousands of packages through different routes every 15 minutes and measures how many were dropped on the way. Test result represents percentage of packets succesfully returned (can be anything between 0 and 1). Performance value is nodes average of these tests in last 24h.

Good performance is much more essential than [stake saturation](../tokenomics.mdx#stake-saturation), because it's lifted to 20th power in the selection formula.
Good performance is much more essential than [total stake](../tokenomics.mdx#stake-saturation), because it's lifted to 20th power in the selection formula.

For a comparison we made an example with 5 nodes, where first number is node performance and second stake saturation (assuming all of them `config_score` = 1):
For a comparison we made an example with 5 nodes, where first number is node performance and second stake saturation (assuming all of them `config_score` = 1 for simplification):

<br />
<AccordionTemplate name="✏️ Example: Performance ^ 20 \* stake saturation calculation">
<AccordionTemplate name="✏️ Example: Performance ^ 20 \* total_stake calculation">
> node_1 = 1.00 ^ 20 \* 1.0 = 1 <br />
> node_2 = 1.00 ^ 20 \* 0.5 = 0.5 <br />
> node_3 = 0.99 ^ 20 \* 1.0 = 0.818 <br />
Expand Down

0 comments on commit fe2817c

Please sign in to comment.