These are my opinions, which do not necessarily reflect the views of my employer.

Until recently, the story was that parachains should use the same staking implementation as the relay chain. The relay chain’s staking implementation uses an on-chain election to spread nominations among validators. This implementation benefits from years of mechanism design research by the Web3 Foundation and a well-reviewed implementation by the Parity engineering team. For these reasons, parachain teams were reluctant to write and maintain their own staking implementations outside Substrate under the assumption that pallet-staking would be the optimal solution for all Substrate blockchains.

However, parachain teams were recently notified of the fact that pallet-staking’s coupling to elections-phragmen makes it too expensive for parachains (which are limited to fewer execution resources than the relay chain).

Pallet-Staking is Too Expensive for Parachains

Substrate’s pallet-staking is used in production on Kusama and Polkadot. pallet-staking implements nominated Proof of Stake (nPoS), a variant of Proof of Stake (PoS) which supports on-chain nominations and enforces shared rewards among validators and their nominators.

To select relay chain validators, Polkadot and Kusama use an on-chain election in which token holders (nominators) submit a weighted ranking of validators (approval voting). These votes are used in the relay chain’s staking implementation (pallet-staking) to determine the allocation of nominator stake to validators. Nominators share validator rewards as well as slashing risk.

In elections-phragmen, Phragmen’s algorithm is invoked to determine the optimal spread of nominations among validators. Phragmen’s algorithm balances nominations algorithmically; individuals submit votes, but do not specify the exact amount delegated to each validator. Instead, on-chain logic determines the allocation of stake from nominators to validators.

diagram to show basic nPoS relationship between nominators and validators

While this implementation has many benefits for the relay chain, it is overkill for parachains. The relay chain provides shared security for many parachains so each parachain has limited execution resources relative to the relay chain. Likewise, parachains will prefer a simple, efficient staking mechanism to pallet-staking.

diagram to show multiple parachains and a single relay chain

Although pallet-staking is by far the most well-reviewed, audited, and tested staking implementation in the ecosystem, it is also an old implementation that inherits outdated concepts. For example, each identity in pallet-staking requires two different AccountIds, stash and controller accounts. The stash and controller account paradigm enables support for hot/cold wallets controlled by the same identity. Recently, the inclusion of pallet-proxy into substrate renders the stash/controller model obsolete by providing the same functionality hidden behind a single AccountId. This means that if pallet-staking were rewritten today, it would not use the stash/controller model for managing identities. It is hard to say how much complexity this would save without implementing it.

Statemint’s Pallet-Simple-Staking

Once pallet-staking was deemed unfit for parachains, Parity started to implement a minimal staking implementation for a System parachain called Statemint. System parachains are parachains that have special privileges on the relay chain which enable them to use the relay chain token (ie KSM, DOT) as their native token and pay fees in this currency as well.

pallet-simple-staking is written specifically for Statemint. The main differences include:

  • collator stake is constant (required stake == min_stake == max_stake)
  • does not support on-chain nominations
  • only pays fees for rewards (there is no inflation logic because it is using the relay chain native token)
  • no slashing implementation

These differences make pallet-simple-staking unsuitable for non-System parachains. Therefore, it has been recommended that parachain teams implement their own custom parachain-staking pallet to cater to their parachain’s specific staking needs. This recommendation implies a free rider problem that has taken many parachain teams by surprise. Most if not all of these teams had been developing their substrate runtimes under the assumption that pallet-staking would be their chain’s staking pallet.

The Nomination Economy is an Inevitability

ETH2 implements a minimal staking mechanism similar to pallet-simple-staking. Instead of supporting on-chain nominations and enforcing shared risk/reward, ETH2’s minimal implementation implicitly encourages off-chain staking pools. These staking pools achieve the same functionality as on-chain nominations, but do not use on-chain logic to enforce shared rewards between validators and nominators.

Requiring off-chain coordination for nominations is OK for an initial implementation. Good devs know that it is always best to start with the simplest version first and iteratively add complexity to address specific user needs.

However, the power of substrate is the ease with which runtime developers can express the on-chain business logic for shared payments. Enforcing shared risk/reward for nominations on-chain should be an eventual goal for every staking implementation because nominations are inevitable. Excluding nominations from the runtime logic pushes coordination off-chain, making the entire system less transparent. Moreover, staking pools coordinated off-chain do not benefit from on-chain enforcement of shared risk/reward between validators and nominators.

Cantillon Effect and The Necessity of On-Chain Nominations

Although nominations are inevitable in any staking system, it’s worth discussing why accessible nominations are important for any inflationary reward system.

The Cantillon Effect describes the implicit transfer of wealth that occurs when new money is printed. In ECON 101, they teach you that when new money is printed, the value of all money immediately depreciates.

“When the money supply increases, the value per unit decreases ceteris paribus.”

In practice, this change happens slowly over time. The first people to receive new money spend it as if it was worth as much as before. The new money retains its value immediately after it is printed because the market adjustment to a supply increase does NOT happen all at once. Instead, the supply increase => price decrease happens gradually, over time, as the new money circulates through the economy. This means that the first to receive the new money spend it at its highest value, while the last to receive it (after it has circulated) spend it at the lower value (after the supply increase => price decrease has already occurred).

The Cantillon Effect represents a transfer of wealth from those that receive new money last to those that receive it first. This transfer of wealth is subtle; it is not measured by idealistic supply/demand models which assume immediate adjustment.

If we limit inflationary rewards to only collators, we exclude non-collating token holders from participating in inflation without opaque coordination through off-chain staking pools.

Moonbeam’s Parachain Staking Implementation

Moonbeam’s runtime dev team wrote a delegated Proof of Stake pallet called parachain-staking.

Instead of running an on-chain election, parachain-staking implements direct delegation with a bounded number of nominations per AccountId (maximum of Config::MaxCollatorsPerNominator per account). In this implementation, token holders (nominators) express exactly which collator candidates they would like to support and with what quantity of stake.

There is a new round every <Round<T>>::get().length = 600 blocks. At the start of each round, the top <TotalSelected<T>>::get() = 16 collator candidates (in terms of total backing stake) are chosen to be in the active collator set. At every block, a subset of this active collator set is chosen pseudorandomly by the author-filter pallet as valid block authors. Only valid block authors can produce blocks.

TODO: explain connection to Nimbus

Inflation Logic

parachain-staking is the only staking implementation outside pallet-staking with inflation logic, but it is minimal relative to pallet-staking’s reward curve.

TODO: explain specific differences between this implementation and pallet-staking’s reward curve

Pallet-dPoS

Like in Tezos’s delegated Proof of Stake (dPoS) implementation, there is a maximum of 1 nomination per AccountId. This reduces the on-chain complexity for handling nominations by forcing users to create multiple accounts to express more than 1 nomination. Middleware could handle this for the user. This feels like the right design!

Conclusion

Parachains have the following options for their staking implementation:

  1. Substrate’s pallet-staking
  2. Statemint’s pallet-simple-staking
  3. Moonbeam’s parachain-staking
  4. pallet-dpos (not yet written)

(4) feels like the best design, but, for now, (3) is used in test networks for Moonbeam. (2) doesn’t make sense for parachains because it is designed specifically for Statemint, a System Parachain (which has no native currency => no inflation logic). (1) is too expensive for parachains now, but this could change in the future with efforts to decouple elections-phragmen from pallet-staking and bound the size of the nominator/validator sets.