Skip to content
  • Gonçalo Pestana's avatar
    Refactor staking ledger (#1484) · 8ee4042c
    Gonçalo Pestana authored
    This PR refactors the staking ledger logic to encapsulate all reads and
    mutations of `Ledger`, `Bonded`, `Payee` and stake locks within the
    `StakingLedger` struct implementation.
    
    With these changes, all the reads and mutations to the `Ledger`, `Payee`
    and `Bonded` storage map should be done through the methods exposed by
    StakingLedger to ensure the data and lock consistency of the operations.
    The new introduced methods that mutate and read Ledger are:
    
    - `ledger.update()`: inserts/updates a staking ledger in storage;
    updates staking locks accordingly (and ledger.bond(), which is synthatic
    sugar for ledger.update())
    - `ledger.kill()`: removes all Bonded and StakingLedger related data for
    a given ledger; updates staking locks accordingly;
    `StakingLedger::get(account)`: queries both the `Bonded` and `Ledger`
    storages and returns a `Option<StakingLedger>`. The pallet impl exposes
    fn ledger(account) as synthatic sugar for `StakingLedger::get(account)`.
    
    Retrieving a ledger with `StakingLedger::get()` can be done by providing
    either a stash or controller account. The input must be wrapped in a
    `StakingAccount` variant (Stash or Controller) which is treated
    accordingly. This simplifies the caller API but will eventually be
    deprecated once we completely get rid of the controller account in
    staking. However, this refactor will help with the work necessary when
    completely removing the controller.
    
    Other goals:
    
    - No logical changes have been introduced in this PR;
    - No breaking changes or updates in wallets required;
    - No new storage items or need to perform storage migrations;
    - Centralise the changes to bonds and ledger updates to simplify the
    OnStakingUpdate updates to the target list (related to
    https://github.com/paritytech/polkadot-sdk/issues/443)
    
    Note: it would be great to prevent or at least raise a warning if
    `Ledger<T>`, `Payee<T>` and `Bonded<T>` storage types are accessed
    outside the `StakingLedger` implementation. This PR should not get
    blocked by that feature, but there's a tracking issue here
    https://github.com/paritytech/polkadot-sdk/issues/149
    
    Related and step towards
    https://github.com/paritytech/polkadot-sdk/issues/443
    8ee4042c