The Future of Polkadot Staking

Tech Talk
1

Polkadot: The Staking Paper

Prelude

Polkadot’s staking system has evolved a lot since its inception. It has often been a pain-point for end-users, and a platform for technical progress given its difficult nature. Here are some of the noteworthy links to recap the history:

The rest of these notes enumerates a non-exhaustive list of potential next milestones for the staking system of Polkadot. @gpestana, @ankan from Parity engineering, and @AlistairStewart, @burdges and @AlfonsoCev from Web3 foundation have contributed to curation of the following list.

My main goal of presenting this list is that I presume we will embark on implementing at least parts of the following ideas over the next 1-2 years and I want to make sure we hear the entire community before moving forward. Some of these features are more beneficial to end-user experience, some are more important for security, and some are more useful for super-scaling and long term, multi-chain future of Polkadot.

Nomination Pools 2.0

Nomination pools are in a stable state where they can reasonably fulfill the main role they were designed for: allowing almost all DOT holders to stake.

Moreover, a number of simple improvements are expected to happen in the near future:

  • Permissionless claiming of rewards, simulating an auto-compounding pool as long as the pool operator or someone triggers the transaction (PR).
  • Optional commissions for pool operators, hopefully making the previous point economically feasible (PR).
  • Ability to rebond while unbonding into a pool, similar to direct nomination.

That being said, there are a number of major improvements that we foresee:

  • Governance participation while you are in pools.
  • Ability to join multiple-pools at the same time.
  • Ability to switch pools without the need to wait for a full unbonding period.
  • Pools that are auto-compounding by default, as opposed to the current scheme that is “non-compounding-by-default” (Issue).

Multi-Page NPoS

By NPoS, we mean the protocol that dictates the “active validator set”, and their exposure table (list of nominators who back each) per era. This is the “source of truth” for both slashing and rewards.

┌──────────────────┐                                      ┌─────────────────────┐
│                  │                                      │                     │
│                  │                                      │                     │
│    Validators    ├──────┐                               │  Exposure Table     │
│                  │      │     ┌──────────────┐     ┌────►                     │
│                  │      │     │              │     │    │                     │
└──────────────────┘      │     │              │     │    └─────────────────────┘
                          ├─────►     NPOS     ├─────┤
┌──────────────────┐      │     │              │     │    ┌─────────────────────┐
│                  │      │     │              │     │    │                     │
│                  │      │     └──────────────┘     │    │                     │
│    Nominators    │      │                          └────►  Active Validators  │
│                  ├──────┘                               │                     │
│                  │                                      │                     │
└──────────────────┘                                      └─────────────────────┘

Currently, the majority of the NPoS process (explained in depth in this video) is bounded to the blockspace of a single block at a time. While some processes are spread across multiple ones, the core parts (receiving a solution, verifying it) are still single-block.

The end goal is to do the entire NPoS process in a multi-page fashion. Such that If the protocol decides to allocate more blockspace to this process, we can expect to have a larger input (validator and nominators) and both a larger output (exposure table).

In short, this allows Polkadot to have a significantly larger number of direct nominators. Moreover, the NPoS system would then be ready to be deployed on a parachain.

“Operators” as First Class Citizen

The current NPoS protocol (as defined above) does not understand any notion of validator operator (via looking at e.g. identities). It only operates and optimizes the validator set based on raw account ids.

If you look at the stake distribution on Polkadot based on individual accounts, it looks very good, but once you take into account how many of those accounts belong to the same operator, the quality decreases.

We want to formalize the notion of “operator” deep into the NPoS protocol. That is, ALL validator are considered to be an operator, and run n nodes. By default, n == 1 for all. Some validators would opt to chose an n > 1. Nominators only express their approval of the operator, not individual nodes.

The benefits of this are multifold:

  1. Nominating an operator is now easier, as a nominator does not need to care about which node of the operator. The nominator can still express “I want to back operator x up to y of their nodes”. This can help the network decide to not let certain operators grow too large.
  2. Operators need to worry less about evenly distributing their nominators’ stake between their nodes. We expect the stake distribution to improve even further when doing this.
  3. The network would have a less chance of facing “nothing at stake” in the occurrence of slashing.
  4. Last, but perhaps most importantly, once Polkadot has this, the protocol can express constrains such that it disincentives a single known operator from growing too large.

Original notes from @AlfonsoCev: NPoS: delegator operators and multiplicities - HackMD

Deprecating Controller

Controller accounts were introduced way before proxies were made, and serve a very similar function. We Strongly believe that proxies are the future, and an important gateway to more usability of the overall ecosystem.

Imagine, having many proxies on hot-wallets and rarely using stash accounts.

In this spirit, we want to deprecate the controller concept from staking. This will result in less code (ergo, less possibility of error) and more efficient execution on the protocol side, and pushes us toward embracing the use of proxies in the UIs.

A simple analysis on Polkadot shows that among tens of thousands of bonded accounts in staking, less than a thousand have a distinct controller account set.

Related topic: Staking: deprecating controller for proxies strategy & implementation

Fast(er)-Unstake

Polkadot and Kusama will soon be equipped with a feature that allows “unexposed[1]” stakers to unstake much faster. The requirement for all stakers to wait 28 days is too strict, even if they end up being exposed.

We strive to move toward a better UX by allowing fast(er) unstake for all stakers as long as the security guarantees of the chain are not significantly affected.

This will most likely translate to a constrain on the amount that is being unstaked, and as long as it respected, unstaking can happen faster.

For example, at any point in time, the first 5% of the total staked amount can be unstaked with 7 days of bonding duration. The next 2.5% with 14 days, and the rest with 28 days.

Beyond this list, revising slashing is also a something that is ought to happen, but I have less concrete ideas and plans around it now, so I will postpone talking about it in this post.

As mentioned at the top, my hope is to let these ideas rest here and gather further opinion, and gradually embark on implementing them based on a reasonable order of priorities.

  1. not present anywhere in the exposure table of any era within the bonding duration ↩︎

16 Likes
2

Focus only on 2 points: Commission for pool operators, less good. Many operators already benefit indirectly when they choose themselves as validators.

Really? We have to become simpler. The nerdy tech deters and prevents mass adoption.

2 Likes
3

I’ll deliver fresh thoughts on slashing one of these days, much less idealist than my original ones upon which the current system is based, but right now I’m focused on ring VRFs for sassafras, and on supporting approval-voting optimizations.

2 Likes
4

Two additional points that should be considered:

The plan of moving staking feature into a common good parachain and how it plays with governance & other features. Do we want a governance chain and a staking chain or a single parachain chain for both staking & governance & some other features?

Put staking derivatives protocols into design consideration. For example, fixed number of nominator cap makes liquid staking protocol implementation very complicated for no obvious gain. We could also design the nomination pools in such way that could be used as a building block for staking derivatives protocols.

3 Likes
5

Could you elaborate more on the pain points with the current implementation? I would have assumed staking derivatives can work in a similar way as nomination pool where multiple nominators are represented as one by the derivative protocol.

Once we have multi-page election and reward payouts, the nominator cap should go away.

6

I’ve talked with Kian about this multiple times and we had https://github.com/paritytech/substrate/pull/10340 but unfortunately it didn’t make it.

Basically each validator have a staking amount cap (or else the reward % will decline) and each nominator have a nominations cap. This essentially creates a staking cap per each individual address. In order to workaround this cap, the Karura Liquid Staking protocol have to split the staking into multiple sub-accounts to ensure the staking optimal rewards.

1 Like
7

(https://github.com/paritytech/substrate/pull/10340 is being worked on again as we speak – I expect it to be over within Q1 this year, thanks to @gpestana.)

4 Likes
8

I totally agree, but I am not compelled that the feature should not even be an option. We’ve developed it such that there is a single global maximum commission set by governance. Moreover, even if this is non-zero, I am pretty sure the average commission will revolve around 0, as most pools will leave it be.

I am not decided yet, but I am leaning toward a “DOT chain” where the main utilities for DOT token live:

  • Staking
  • Governance
  • Auctions etc.

I think this is the most reasonable degree of composability and asynchrony to deal with.

I mentioned Allow for a dynamic number of nominators by kianenigma · Pull Request #10340 · paritytech/substrate · GitHub in another reply about nomination cap. Other than that, is there anything specific about pools that you have in mind? I think the pools can already be used in Liquid Staking protocols. Instead of setting up direct nomination, Acala can setup a pool on the relay chain and control that via the parachain, a contract etc. You can then allow other users to subscribe to the pool, charge your commission on the relay chain etc.

2 Likes
9

Agree with all the raised points.

On deprecating controllers: Please keep this as a soft requirement that a future system is at least as simple as controller-stash. If you are onboarding into Polkadot staking, it takes some time to think all of this through and it can be a stopper for new validators that get overwhelmed with the complexity. The new system should not gain in complexity towards validators.

4 Likes
10

I think that’s a great point btw - if we can minimise the intervals or steps, that would be great. In the end, we want to prevent high amounts unbonded all at once, so maybe we can just add a limit under which they can unbond without the above steps. Then, unbonding >1000 DOT (tbd) at once goes through the steps described.

This way we make it easier for the Polkadot newbies, and have more restrictions on the heavy weights (who are probably fine to read some fine print)

On another note, are there plans to make pool evaluation easier too? Like showing / calculating the pool performance and including filters? Or would this be staking dashboard UI updates?

3 Likes
11

This is mainly a UI problem, it would be highly contentious for Polkadot the protocol to make any decisions on this.

1 Like
12

I want to emphasize this a bit more, and mention that once this is done, we will be more confident in taking good steps towards Restaking similar to EigenLayer and leverage the relay chain security even more, and/or boost it a step further with adding additional staked parachain tokens as well.

Of course, we can do that now as well, but I would rather first clean up the slashing logic, revise it from first-principles, and then start any sort of re-staking. The existing slashing logic is sound, but arguable too strict and ergo not scalable to hundreds of thousands of nominators.

2 Likes