Signaling proposal for the Nakamoto bonus

This signaling proposal aims to gather community feedback on updating the x/distribution module to improve the Nakamoto Coefficient of the AtomOne chain. To this end, the way in which block rewards are distributed would be updated to incentivize delegators to delegate to validators having less staked tokens.

This feature would divide the staking reward in two components: a part proportional to the overall amount of stake of a validator - this coincides with the current staking reward model, and a part that is distributed uniformly to validators - the Nakamoto bonus.

The overall amount of the reward remains unchanged, however the criteria for assigning the reward changes.

Motivation

The Nakamoto Coefficient is the main way used to measure the amount of decentralization of a blockchain. Many of the benefits of the blockchain technology can be directly attributed to its decentralization: its resilience to attacks, collusion and errors.

The Nakamoto Coefficient is defined as the minimum number of nodes that need to be compromised to harm the network. In the case of AtomOne, a voting power of 33.3% is enough to disrupt the consensus algorithm, therefore the Nakamoto Coefficient of the chain is the minimum number of validators having such voting power.

At the time of writing, the AtomOne chain suffers from a concentration of delegations on the top staking validators. The current Nakamoto coefficient is 5, which is lower that the ideal (34, given that the current maximum number of validators at the time of writing is 100) and armful to the security of the chain. There are multiple ways in which the issue of low decentralization could be addressed. One way is to incentivize delegators to increase the decentralization of AtomOne which is the aim of this proposal.

Implementation

The feature in this proposal would split the block reward in two components: proportional reward (PR) and Nakamoto Bonus (NB), such that:

$$ R_i = PR_i + NB_i $$

Where:

• $R_i$ is the total reward obtained by validating block $i$.
• $PR_i$ is the proportional reward for block $i$.
• $NB_i$ is the Nakamoto Bonus for block $i$.

The parameter η ∈ [0,1] defines how NB is computed from the reward:

$NB_i = R_i \times \eta$, where $R_i$ is the total reward obtained by validating block $i$.

Increasing η increases the part of the reward assigned to the Nakamoto Bonus (i.e. NB). If η is equal to 1, the entire reward is assigned using the Nakamoto Bonus criteria - uniformly distributing it across all validators. When η is 0, the entire reward is assigned to the validators proportionally to their stake, as in the current system.

The reward obtained by a validator j at block i is computed as:

$$ r_{ji} = \frac {x_{ji}}{S_i} \times PR_i + \frac{NB_i}{N_i} $$

Where:

• $r_{ji}$ is the reward of validator $j$ for block $i$.
• $x_{ji}$ is the stake of validator $j$ at block $i$.
• $PR_i$ is the proportional reward for block $i$.
• $S_i$ is the total stake across all validators at block $i$.
• $NB_i$ is the Nakamoto Bonus for block $i$.
• $N_i$ is the total number of validators for block $i$.

The way in which the reward obtained by a validator is distributed across delegators remains unchanged.

Dynamic update of η

The η coefficient will move between 0 and 100% and its initial value of will be set to 3%. The coefficient will be updated every 120K blocks (~ one week) by performing increases or decreases of +- 3%.

The decision on whether η needs to be increased or decreased is performed as follows:

1. Bonded validators are sorted by voting power and split into 3 groups (33 in high, 33 in medium, and 34 in low).
2. The average voting power of the high and low validator groups is computed.
3. If the average voting power of the high group is *3x* or more the average voting power of the low group, η is increased, otherwise it is decreased.

Validator Commissions

Unrestricted, validator-set commissions can be used to undermine the mechanisms proposed. For example, a top validator could temporarily lower their commission to counteract the effects of the Nakamoto Bonus in the short term. Moreover, unrestricted commissions may enable validators to exploit delegators. A validator could lower their commission to attract delegations, only to later increase it — potentially up to 100% — for personal gain. To address this, the commission rate will become a equal-for-all, network-wide parameter adjustable only through governance. This measure is also mandated by the AtomOne Constitution.

This will require modification of the x/staking module which will therefore also be updated as part of this mechanism.

Key Module Changes

1. Distribution of block rewards to validators: the x/distribution module needs to be updated to implement the feature in this proposal.
2. Fixed network-wide validator commission: the x/staking module will equally need to be updated to make the validator commission a network-wide fixed parameter.

Testing and Testnet

The Nakamoto Bonus feature will be rigorously tested via unit and end-to-end tests.

The AtomOne public testnet will undergo a coordinated upgrade that will include the Nakamoto Bonus feature before a software upgrade is proposed on mainnet, allowing more testing before mainnet deployment.

Potential risks

User Experience Challenges

Users may experience fluctuations in their staking reward as a result of this feature. Moreover, the choice of the validator a user delegate its stake to will impact his rewards. The user can take advantage of the proposed feature using clear client-side tools that sort validators by profitability and automated tools that periodically re-delegate his stake.

Audit

An audit covering the entire AtomOne codebase and the x/distribution and x/staking modules including the Nakamoto Bonus feature and fixed validator commission will be performed before the presented system is included in any software upgrade proposal submitted on the mainnet.

Upgrade Process

The implementation of the Nakamoto Bonus is contingent upon the successful completion of a third-party audit and thorough validation of its functionality. Once these conditions are met, we anticipate releasing this feature as part of a future AtomOne upgrade.

Codebase

https://github.com/atomone-hub/atomone/blob/main/docs/architecture/adr-004-nakamoto-bonus.md

https://github.com/atomone-hub/atomone/pull/135

Voting options

• Yes: You are in favor of adding the Nakamoto Bonus
• No: You are against having the Nakamoto Bonus.
• ABSTAIN - You wish to contribute to the quorum but you formally decline to vote either for or against the proposal.