github.com/Finschia/finschia-sdk@v0.48.1/x/staking/spec/05_end_block.md (about) 1 <!-- 2 order: 4 3 --> 4 5 # End-Block 6 7 Each abci end block call, the operations to update queues and validator set 8 changes are specified to execute. 9 10 ## Validator Set Changes 11 12 The staking validator set is updated during this process by state transitions 13 that run at the end of every block. As a part of this process any updated 14 validators are also returned back to Tendermint for inclusion in the Tendermint 15 validator set which is responsible for validating Tendermint messages at the 16 consensus layer. Operations are as following: 17 18 - the new validator set is taken as the top `params.MaxValidators` number of 19 validators retrieved from the `ValidatorsByPower` index 20 - the previous validator set is compared with the new validator set: 21 - missing validators begin unbonding and their `Tokens` are transferred from the 22 `BondedPool` to the `NotBondedPool` `ModuleAccount` 23 - new validators are instantly bonded and their `Tokens` are transferred from the 24 `NotBondedPool` to the `BondedPool` `ModuleAccount` 25 26 In all cases, any validators leaving or entering the bonded validator set or 27 changing balances and staying within the bonded validator set incur an update 28 message reporting their new consensus power which is passed back to Tendermint. 29 30 The `LastTotalPower` and `LastValidatorsPower` hold the state of the total power 31 and validator power from the end of the last block, and are used to check for 32 changes that have occured in `ValidatorsByPower` and the total new power, which 33 is calculated during `EndBlock`. 34 35 ## Queues 36 37 Within staking, certain state-transitions are not instantaneous but take place 38 over a duration of time (typically the unbonding period). When these 39 transitions are mature certain operations must take place in order to complete 40 the state operation. This is achieved through the use of queues which are 41 checked/processed at the end of each block. 42 43 ### Unbonding Validators 44 45 When a validator is kicked out of the bonded validator set (either through 46 being jailed, or not having sufficient bonded tokens) it begins the unbonding 47 process along with all its delegations begin unbonding (while still being 48 delegated to this validator). At this point the validator is said to be an 49 "unbonding validator", whereby it will mature to become an "unbonded validator" 50 after the unbonding period has passed. 51 52 Each block the validator queue is to be checked for mature unbonding validators 53 (namely with a completion time <= current time and completion height <= current 54 block height). At this point any mature validators which do not have any 55 delegations remaining are deleted from state. For all other mature unbonding 56 validators that still have remaining delegations, the `validator.Status` is 57 switched from `types.Unbonding` to 58 `types.Unbonded`. 59 60 ### Unbonding Delegations 61 62 Complete the unbonding of all mature `UnbondingDelegations.Entries` within the 63 `UnbondingDelegations` queue with the following procedure: 64 65 - transfer the balance coins to the delegator's wallet address 66 - remove the mature entry from `UnbondingDelegation.Entries` 67 - remove the `UnbondingDelegation` object from the store if there are no 68 remaining entries. 69 70 ### Redelegations 71 72 Complete the unbonding of all mature `Redelegation.Entries` within the 73 `Redelegations` queue with the following procedure: 74 75 - remove the mature entry from `Redelegation.Entries` 76 - remove the `Redelegation` object from the store if there are no 77 remaining entries.