Polkadot: The Staking Paper
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:
- Polkadot/Kusama Staking Changes Report June 2021
- Polkadot Outage Postmortem (related to staking)
- Future of NPoS Talk June 2021
- Staking Monthly Updates (Sept 2021 - Now)
- Polkadot Decoded 2022 Talk on Nomination Pools
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
rebondwhile 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).
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:
- 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
yof their nodes”. This can help the network decide to not let certain operators grow too large.
- 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.
- The network would have a less chance of facing “nothing at stake” in the occurrence of slashing.
- 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
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
Polkadot and Kusama will soon be equipped with a feature that allows “unexposed” 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.
not present anywhere in the exposure table of any era within the bonding duration ↩︎