Proposal: Enhancing Decentralization on the Namada Blockchain

Background

The Namada blockchain currently employs cubic slashing as a mechanism to incentivize decentralization. This approach penalizes validators proportionally to their stake when they exhibit malicious behavior, such as double signing, thereby encouraging delegators to diversify their staking across multiple validators. However, cubic slashing is only effective in cases of validator misbehavior. It does not address the centralization of voting power under a few validators who operate without exhibiting malicious actions.

Presently, the Namada blockchain has a critical issue: two operators running three validators collectively hold over 30% of the network’s voting power. This poses a systemic risk, as the shutdown of these operators’ nodes could halt block production and bring the network to a standstill. To strengthen decentralization and ensure the long-term security and resilience of the network, I propose introducing a cap on the stake that can be delegated to a single validator.

The Problem

While cubic slashing deters misbehavior, it does not provide sufficient safeguards against the concentration of voting power. Large amounts of NAM can be staked on a single validator without any mechanism to disincentivize such behavior. This creates a scenario where:

  1. Voting power becomes concentrated in the hands of a few operators.
  2. The network’s resilience to failures or attacks diminishes.
  3. Delegators lack incentives to perform due diligence and distribute their stake.

Proposed Solution

Introduce a dynamic cap on the amount of NAM that can be staked on a single validator. If the stake exceeds this cap, cubic slashing would activate, resulting in a loss of assets for delegators. This mechanism ensures that delegators are motivated to diversify their stake and prevents excessive concentration of voting power.

Calculation of the Cap (Example)

The cap would be calculated dynamically to ensure that 70% of the total voting power is distributed across at least 50 validators. For instance:

  • Current total voting power: 348,664,548 NAM
  • 70% of voting power: 244,065,183 NAM
  • Voting power cap per validator: 244,065,183 / 50 = 4,881,303 NAM

With this approach, no single validator could exceed a voting power of 4,881,303 NAM without triggering cubic slashing, thereby encouraging a more balanced distribution of stake across the network.

Benefits

  1. Enhanced Decentralization: Encourages a more equitable distribution of stake and voting power.
  2. Increased Resilience: Reduces the risk of network failure due to the shutdown of a small number of validators.
  3. Improved Due Diligence: Incentivizes delegators to evaluate validators and diversify their stakes.
  4. Sustainable Growth: Supports the long-term security and decentralization of the Namada blockchain.

Implementation Considerations

  • The cubic slashing mechanism for exceeding the cap would need to be carefully designed to balance disincentives without overly penalizing delegators.
  • Adjustments to the cap calculation should account for changes in the total voting power and validator count over time.
  • Community feedback and simulations should be conducted to refine the proposal and ensure its feasibility.

Call to Action

To the Namada community: decentralization is at the heart of blockchain technology. By implementing a stake cap mechanism, we can safeguard the network against centralization risks and uphold the principles of resilience and fairness. I invite the community to discuss, provide feedback, and collaborate on this proposal to ensure its success.

This proposal is one of the most extreme I have seen in any context, and I cannot recommend strongly enough it is not put into action.

2 Likes

100% against this approach .

1 Like

Strongly disagree with the proposal. What could be worse for an unaware staker than having their tokens slashed right after staking in the hope of increasing their NAM?

If the protocol is to be changed, it should focus on incentivizing, not punishing.
something like having a higher APR on low-VP validators

1 Like

While I agree with the necessity of decentralization, it can probably not be solved at the protocol level. A maximum voting power per validator can be easily worked around by the operator by splitting a big validator into multiple smaller ones. That actually already happened.

The culprit is that the voting power is concentrated in a relatively small amount of individuals, ‘whales’ if you will: 32% of the total supply went to AF Backers and they put that voting power to use.

AF backers seem to prefer a few specific validators, perhaps because they require an enterprise level service contract with a registered company that has a physical address. They are not going to delegate to an anonymous validator. No matter the protocol mechanisms, the real world need for such a contract could weigh more strongly than any protocol incentives or disincentives.

Meanwhile, I suspect that a significant part of the public allocations is not delegated, but simply held.

There are ways to even out the distribution eventually, for example:

  • Motivate the public allocations recipients to delegate more NAM
  • Entice whales to spend NAM on (public) goods and services
1 Like

The proposed mechanism appears to inadvertently “punish success.” While striving for greater decentralization is essential, we must ensure that we do not undermine the contributions of honest participants in the process.

1 Like

Thank you very much for your constructive feedback.
I am happy to convert this thread and discuss other options rather than necessarly elaborate on the original proposal.

What it is important for Namada is to identify a solution and guarantee a better decentralization.

I guess that on this point there are no objections in the community.

I can start with another idea, but I’d encourage everyone to speak up, as we really need to address this issue.

If the problem is with ‘whales’, another idea could be to completely remove the validator selection capability and let the protocol to automatically allocate the NAM to different validators.
We could move away from the idea that your NAM are staked to a validator and you’re responsible for its selection.
Instead the delegator’s concern would be solely to stake their NAM on Namada to guarantee the network security and the validators will become purely a technical aspect that is transparent for the delegators.

  1. The delegator would not longer choose the validators, but only decide how many NAM to Stake. The protocol would do rest.

  2. The protocol could use a pseudo random mechanism while distributing the funds across multiple validators to ensure decentralization as well as to maximize the APY for the delegators. Today the protocol uses a pseudo random mechanism to selct the block proposal based on the voting power and tomorrow it could use as well a similar mechanism to distribute the stake across the validators.

  3. Some criteria that could be used by the protocol pseudo random mechanism:
    A) Commission Rate (less is better)
    B) Uptime (probably not just the last 100 blocks, but look at a longer time window)
    C) Current delegator’s voting power (less is better)
    D) Initialization epoch grace period ( brand new validtors would need some history of uptime before they would have been selected by the protocol)
    E) Community & Infra support ( e.g. validators providing infra support with RPC,indexer, snapshot etc would have a higher weight)
    F) Validator Slash history (A validator with an histors of slash would consistute a penatly)

  4. The protocol should automatically rebalance / redelgate the allocation as situation might changes over time to reflect the above criteria (e.g. different total voting power, validator unhealty,)

1 Like

:+1:

Perhaps a bonus tied to:

  • how long NAM has been delegated
  • How decentrailized the chosen validator is
  • A metric that publicly displays public allocation delegation %

I think everyone agrees there is a centralization problem at the moment. However the replies given in this thread is in response to an extreme proposal which to be perfectly honest should not even have been put on the table.

As for other measures that could be taken, I fully support @Rigorous’ analysis in that the issue here is more fundamental in 1. staking patterns of token holders and 2. token concentrations in supply. I don’t see any way of introducing compensatory measures that would not be foundationally unfair.

I think this has to be solved on the diplomatic/social level, and I hope the relevant parties are reading here, and would consider some form of mitigation.

Let me also remind that while 33% of VP can halt the chain, that percentage in collusion can’t do much more. Let me also caution against hyperbole, in that at any time 66.67 % of vp (corresponding validators) could collude and do some awful stuff - by definition, at any point in time, in any similar chain, and yet we don’t go around being scared of that constantly. I think such a scenario also is prevented mainly by social mechanisms that anything else imo. If one thinks it through, if such events were to occur they would be so detrimental it would not even be in the interests of the parties that would gain from it. This all to say, let’s relax just a little. (It helps too that the top validators are both professional and responsible - in this context that might even be a net plus for the chain)

1 Like
  • How decentrailized the chosen validator is

What do you mean by that?
How should it be visualized?

The opposite of this. Open to ideas, but preferences of validators out of top 15 comes to mind.

Some KPI would need to be created, I suggested => A metric that publicly displays public allocation delegation %. Whether this is feasible is an open question. The more we talk about this as an educational exercise, the better. I think this topic needs more input from the community.

While the intention is good, the approach sounds like the economics of communism or slavery. Equality is not a good thing. Equal treatment is great. Equally balanced is great. All up for the intention, against the implementaiton. Sorry. I dont have one to counter offer