• scalability.
• scalability.
• scalability.
• scalability.
• and scalability.

• But we (strive to) get much better economic security measures in return 🌈.

• Long term, this can in itself be solved by what Polkadot provides best, more Blockspace 🎉!

NPoS Protocol Overview

• The current NPoS protocol revolves around an election round, which is itself made up of 4 episodes.
• This gives you an idea about how we solved the scalability issue for the time being.

---v

NPoS Protocol Overview: Episode 1

Snapshot

• Enables multi-block election.
• Allows us to not need to "freeze" the staking system.
• Allows us to index stakers, not AccountIds.

---v

NPoS Protocol Overview: Episode 2

Signed Submissions

• Any signed account can come up with a NPoS solution based on that snapshot.
• Deposits, rewards, slash, other game-theoretic tools incorporated to make to secure.

---v

NPoS Protocol Overview: Episode 3

Validator Submissions as Fallback

• As the first backup, any validator can also submit a solution as a part of their block authoring.

---v

NPoS Protocol Overview: Episode 4

Fallbacks

• If all of the above fails, the chain won't rotate validators and the governance can either:
  • dictate the next validator set.
  • trigger an onchain election (limited in what it can do).

This was recently used in Kusama 🦜.

NPoS Objective

• Given the powerful tool of NPoS, what should we aim for?
• Let's first recap:

1. Polkadot validators are the source of truth for the state transition of both the relay chain and all of the parachains + bridges.

2. Polkadot validator are assigned to parachains as backing group, and swapped over time.

3. Polkadot validators all author the same number of blocks, i.e. they are of same importance.

Notes:

Point 2 is not to imply that the polkadot validator set's security is partitioned among parachains, security comes from approval voters. https://www.polkadot.network/blog/polkadot-v1-0-sharding-and-economic-security/

---v

NPoS Objective: Election Score

#![allow(unused)]
fn main() {
pub struct ElectionScore {
  /// The minimal winner, in terms of total backing stake.
  ///
  /// This parameter should be maximized.
  pub minimal_stake: u128,
  /// The sum of the total backing of all winners.
  ///
  /// This parameter should maximized
  pub sum_stake: u128,
  /// The sum squared of the total backing of all winners, aka. the variance.
  ///
  /// Ths parameter should be minimized.
  pub sum_stake_squared: u128,
}
}

---v

NPoS Objective: Election Score

• NPoS allows us to incentivize the formation of a validator set that optimized the aforementioned ElectionScore.

• This score is ALWAYS calculate and checked onchain. This is why we can accept solutions from the outer world.

Notes:

A common example: we allow signed submissions. What if they send solutions that are censoring a particular validator? if it can achieve a better score, so be it! we don't care.

---v

NPoS Objective: Election Score

• The default algorithm used in both the onchain/offchain solvers is the Phragmen algorithm.
• Proved to provide high fairness and justified representation properties whilst being verifiable in linear time.

NPoS Future

• Fresh from the oven (Jan 2023): Future of Polkadot Staking in the Polkadot forum.
• Github issue-tracker/project

• Nomination Pools
• Multi-page election submission
• Operators as first class citizens.
• fast-unstake.

Additional Resources! 😋

Check speaker notes (click "s" 😉)

Notes:

Further Reading

• Recent Kusama slashing: https://forum.polkadot.network/t/kusama-era-4543-slashing/1410
• A verifiably secure and proportional committee election rule
• 4.1 in Overview of Polkadot and its Design Considerations
• Proportional Justified Representation
• Justified representation - Wikipedia

NPoS Protocol: More Details, Backup Slides

• bags-list: how to store an unbounded semi-sorted linked-list onchain.
• Nomination pools: best of both.
• Minimum-untrusted score.
• PJR checking: why we don't do it.
• reduce optimization.

Feedback After Lecture: