---
title: Staking mini retreat session notes
tags: parity, staking
---

# Staking mini retreat - session notes
*20-24th/Nov/2022*

**Actionable/to open issues**:

- ⭐ Consider automatic rebaging when rewards are received or slashes happen 
- ⭐ Revise the Kusama staking parameters (and make it on pair with Polkadot?)
- ⭐ Remove snapshots
- one of the ideas is to remove the requirement for the snapshot. Why? what's required for that?
- related to [W3F ideas on smaller solution size](https://hackmd.io/oKMOYrt8TLGnAcK8SMHA-Q?both#Smaller-Solution-Size)
- ⭐⭐⭐ [New staking design and refactoring](
https://forum.parity.io/t/mega-refactor-repot-staking-into-smaller-pallets/754)
- Rewards and staking should not be tight together -- a scalable rewards system should be re-written before (it should be it's own pallet). insight: the rewards should only know about the exposures.
- ⭐ Staking miner economics improvements
- currently, the system is not economical friendly, needs to be improved
- does it make sense to incentivise other players to run their own staking miner? what are the changes in the configurations, fees, deposits, etc required to make it economically friendly?
- maybe take part as a provider (and compete with W3F and Parity submitters)
- may not make a lot of profit, though
- ⭐⭐⭐ Add/improve alerting (notifications/etc) around the staking miner events and state (when is it not earning election runs and others)
- ⭐⭐ Create a dashboard with metrics related to staking miner
- e.g. in the past 3 months:
- what were the average scores of submitted solutions?
- how many elections were solved in the signed/unsigned phase, etc?

---

(raw notes)

## Day 1
#### Morning session

Unlimited amount of `Targets` -> `Bags lists` -> `Input of elections`
- Bags list (`VoterList` in staking and nomination pool)
- From Bags list -> flat vector of Targets of nominators/validators i.e. the snapshot. The snapshot is kept for slashing purposes and others.
- ⭐ Consider automatic rebaging when rewards are received or slashes happen 

- Bags list needs to be sorted at all times (not only passively), due to the staking backup of the validators changing when there is a reward or slash.

- Issue (in the congestion management in the staking pallet): what if the validators list is filled? No new validator is accepted, which is bad. There is one mechanism that goes around this, which is setting a `minValidatorBond` and `minNominatorBond`. These limits, with `ChillOther()`, allow any validator to chill other validator that has less bond than required by the required settings.

- ⭐ todo as follow up: revise the Kusama parameters (and make it on pair of Polkadot)?
- ⭐ one of the ideas is to remove the requirement for the snapshot. Why? what's required for that?
- related to [W3F ideas on smaller solution size](https://hackmd.io/oKMOYrt8TLGnAcK8SMHA-Q?both#Smaller-Solution-Size)
- snapshot needs to happen at every end if the era. However, it is a costly operation for it's done a few hundred blocks ahead of time.

- validators are active without self stake, relying mostly on the nominations (and on self-nominations). Self nominations and self validations are the same.
- problem is that if the validator is not self-staking and self-nominating, the validator is not slashed.

#### High level inter pallets

**A: EPM** Election Timeline (related to EPM, before `staking` pallet comes in):
- `t`
- `DataProvider::voters()` - snapshot
- `Signed phase` -- result is one valid, best (maybe not good enough), election solution that has been proposed by a off-chain staking miner
- `Unsighed phase` -- inherent from validators
- `extrinsic challenge()` (new feature )
- `elect()`
- `t+n`

**B: Staking**

⭐⭐⭐ staking refactoring/work on legacy code
- better plan for rewards so that ALL backers can be rewarded (no need to `ErasStakedClipped`, etc)
- `Exposures` should come completely consumable from the miner, the staking pallet should not be sorting and truncating the `exposure.others` vec.
- (look into `ErasStakers`, `ErasStakedClipped`)
BUT
first -- extract the rewards system out of the account `ledger` struct (where slashing spans etc are)
⭐⭐⭐ Rewards and staking should not be tight together -- a scalable rewards system should be re-written before (it should be it's own pallet)
- insight: the rewards should only know about the exposures
- the rewards pallet has a hook into the final exposures result from the EPM and reward based on that.
- 1st step: sit down, spec and think how to approach that (needs fairly complicated migration, etc)

⭐⭐⭐ **New staking design and refactoring:**
https://forum.parity.io/t/mega-refactor-repot-staking-into-smaller-pallets/754

Basically, the staking system can be broken down into 4 pallets:
- Validator Selection (election, EPM, etc) - outputs `Exposures`
- Roles: all the roles required for staking etc (permissions, etc)
- Rewards: consumers `Exposures` and rewards
- Slash: consumer `Exposures` and slashes

This work should be taken care *before* thinking about moving staking to the parachain (and the migration should piggy back)

---

staking miner
- ⭐⭐ currently, the system is not economical friendly, needs to be improved
- does it make sense to incentivise other players to run their own staking miner? what are the changes in the configurations, fees, deposits, etc required to make it economically friendly?
- maybe take part as a provider (and compete with W3F and Parity submitters)
- may not make a lot of profit, though

- ⭐ Decouple submitting the score and the solution (mid prio) to better incentivise staking miners and to create a better market for it

`election_score {min_stake, sum_stake, variance}`:
- `min_stake` is the main attribute (i.e. min_stake should be the highest across all solutions)
- `sum_stake` is the next most important

Reason for snapshots:
1. memory issues (we don't want tot signed phase to iterate through unbonded list of validators, may OOM the wasm in `on_initialize` which is very bad)
2. size constraints (similar to point 1.)
3. freeze the staking state

⭐⭐⭐ add pagerduty/alerts around the staking miner events and state (when is it not earning election runs and others)
- not fun to learn about the fact that the staking-miner is not minting stuff for 7 days
- who is the staking miner that is submitting solutions nowadays?
- use `ifthisthanthat` hook in subscan, for example (maybe a bot-like cronjob is better here)
- another: are we being notified when there are no solutions provided by staking miners?
- [https://github.com/paritytech/infrastructure-alerts/wiki/Blockchain:-Apps#staking-miner](https://github.com/paritytech/infrastructure-alerts/wiki/Blockchain:-Apps#staking-miner)
- other places for alerting?

⭐⭐ Add other metrics related to staking miner -- in the past 3 months:
- what were the average scores of submitted solutions?
- how many elections were solved in the signed/unsigned phase, etc?

If `elect()` is called if there are no solutions queued and fallback doesn't provide a solution --> we go into `Emergency Phase`:
1. `set_emergency_solution()`
1. this will just accept the solution from `ensure_root`, ie. governance proposed
2. `governance_fallback()`
(safeguard, it hasn't been triggered in Polkadot yet)

---

#### Afternoon session

**Main topic: Nomination Pools**

Open tasks for the future (all of these points should have issues, apart from the assets task)
- Fast-unstake UI
- ⭐⭐ Governance (see discussion https://github.com/paritytech/substrate/pull/12610)
- Vesting
- Auto-compound by operator (already done it by external, review PR https://github.com/paritytech/substrate/pull/12608)
- Switch pool (probably not a good idea)
- Use Assets (instead of points) (more of a research point)
- Robot pools (not yet an issue)
- (check this better, ask for a write up -- research question at this point)

- ⭐⭐⭐⭐ exercise: refactor the nomination-pools to use assets pallet instead of the point system (to allow "liquid staking"-like behaviour, switch pools, transferrable position of the nomination pool stake, have the derivedDOT txed through XCM etc)
- basically, "let the points be transferable" (liquid staking)

Non interactive staking PR: https://github.com/paritytech/substrate/pull/12610

- ⭐⭐⭐⭐ do project reviews https://github.com/orgs/paritytech/projects/33/views/9

---

## Day 2
#### Morning session

- [[⭐]][[⭐]] store current `min_active_bond` on chain (for UI)
- create issue for this
- nowadays it's calculated on the fly depending on the state of the nominations:
- 1 layer: EPM/staking pallet
- min active bond to be filtered and sent to the election
- 2. layer: on the exposures table `staking:: fn collect_exposures`
- min active bond that ends up on the election result
- must be calculated over the full exposures table (can't be done with only a val keeping the min)

- [[⭐]][[⭐]] check gov v2 (and gov v1)
- [[⭐]] check `conviction-pallet`

---

**chat with [[Kian]]**
[[⭐]][[⭐]][[⭐]] revise numbers on removing the snapshot (Back of the envelope calculation)
- How much do we gain from doing it? how much saving?
- How much would the new shorter version
- Measure if this new approach is feasible with the single-block approach of multi-block only
- The computation to de-pack the solution from the miners is larger, may be only doable on a multi block approach (check this out).
- [[⭐]] [[⭐]] [[⭐]] [[⭐]] `feasibility_checks` in EPM: Needs to rebuild the benchmark with an unreduced solution? check the benchmarks to get an high level understanding on the
- Related: https://github.com/paritytech/substrate/issues/12652#event-7851541985
- The prototype should have a way to benchmark the current solution (done -- may need revise) and with the new solution.
- [[⭐]] [[⭐]] [[⭐]] [[⭐]] check the EPM `unsigned.rs` down to `fn score`, considering the voter major/target major conversions and whether the code can/should be improved

- [[⭐]] [[⭐]] [[⭐]] Add/improve alerting (notifications/etc) around the staking miner events and state (when is it not earning election runs and others) -- more of a hacking project, nothing too robust/important
- [[⭐]] [[⭐]] Create a dashboard with metrics related to staking miner (ask Niklas about current state in minder-v2)
- e.g. in the past 3 months:
- what were the average scores of submitted solutions?
- how many elections were solved in the signed/unsigned phase, etc?

---

## Day 3

#### Staking Parachain discussion

**Naming**:
- Transparent Handler for Exposures and Memberships In Staking (THEMIS)
- () HERMES
- StakeChain
- ParaStake
- SChain

**Expectations** (when designing the StakeChain):
- Guaranteed message delivery
- Message passing costs are low

### Afternoon Session

- Snapshot usage (advantages):
1. Encoding of accounts in the ers
2. Freezing: no need to freeze staking state between eras
3. Fix target -- the offchain miners need to know the fix target of the election to solve
4. Parachain friendly/PoV
1. Due to this, it may not be smart to remove snapshots and bags (as mildly expected). PoV size is improved with snapshots

[[⭐]] [[⭐]] Why is the snapshot parachain friendly? Because of the PoV -- (double check this)

[[⭐]] [[⭐]] Nomination degree based on stake
- Bound the number of validators a nominator can nominate depending on the amount of DOT used for nomination. (e.g. 2 DOT nomination --> max 4 validators)
- This would decrease the size of the snapshot
- [[⭐]] What is the function that would optimise security and size of the snapshots?
- possible to check in the current chain data
- Perhaps we could remove the nomination cap (i.e. nominators can nominate with any amount of DOT, uncapped, and allow them to nominate more validators too. So the parameters are unbond)

Snapshots stays :)

---

## Day 4

**Pool balance locks (lockedDOTs)**

What if nominations would just lock account balances (remote locking), instead of transferring balances?
- This would simplify things in slashing, as the slashing is applied lazily when the accounts touch funds
- The problem is that the nominations from slashed accounts will still be able to back other pools, even after a slash (not good)
- but this is only a problem for pool hoping.
- If switching pools are not enabled, then this would simplify pool governance, slashing, etc

- Can we be lazy about historical slashes?
- Is it important to stop slashed nominators (that have been slashed lazily), from nominating other validators?
- Soundness slash -- 100% slash
- pool switching seems to be OK even with historical slashing
- in some cases it is, but in other cases it is not OK (e.g. soundness slash, why?)

If validators don't have self staking, what prevents the validators with large backing from turning rogue and mess up with the nominators?
- Slash does not affect validator (no self staking)

- "censored chain" cannot happen (a requirement/assumption), otherwise a lot of things go south

**Relay-chain fallback**: It's good idea to keep runtime logic in the relay chain that works as a backup when a parachain is attacker/misbehaves/does not work. A good example of this is the governance parachain -- the relay chain needs to still implement a fallback mechanism for governance when and if the governance parachain has any problems (which is much more likely to happen then if running the governance on the relay chain).

The elections logic is very much in line with the parathread model (as opposed to parachain). Since the elections is idle for most of the time but when it's required, it's pretty heavy and potentially multi-block (PJR checks etc).

DOT parachain is a bad idea -- leave DOT in the parachain and remove all the other logic (e.g. staking etc), to parachains. The DOT transfers should always happen on a relay chain (for the reasons above).

**[[robot pools*]]*: Pools that are unmanaged -- there's a default/lazy pool for every combination of nomination pools that can exist (2 flavours of them == auto-compounding or non auto-compounding).

[[⭐]][[⭐]] **[[staking miner]]** - think about the commit-reveal approach, to bring the tx cost down of participating in the solution and align economic incentives adequately.

**[[slashing]]**
open questions and what do we want? [https://hackmd.io/w37x4CahQhaGJNlq-yQBnA](https://hackmd.io/w37x4CahQhaGJNlq-yQBnA)
- 100% slashes should take nominator (and second order nominations) down immediately
- All slashes can be reverted

- idea: small misbehaving slashable stuff should not chill nominators (only the validators)
- operator chilling

- slashing spans -- essential trying to:
- deal with historical slashing (keep track of when slashes/nominations happened and be able to go back in time to know who needs to be slashed and make sure there are no double-slashings)

- [[⭐]] Cases of slashing: BABE, GRAMPA equivocation cases, soundness (aka 100% slashes), beefy (signed on unfinalized chain) being offline
- what, when, examples?
- GRAMPA equivocations are less serious than BABE