github.com/MetalBlockchain/metalgo@v1.11.9/vms/platformvm/docs/chain_time_update.md (about)

     1  # Chain time update mechanism
     2  
     3  The activation of the Banff fork changes the way P-chain tracks its `ChainTime`. In this brief document we detail these changes.
     4  
     5  ## About `ChainTime`
     6  
     7  One of the P-chain's main responsibilities is to record staking periods of any staker (i.e. any validator or delegator) on any subnet to duly reward their activity.
     8  
     9  The P-chain tracks a network agreed timestamp called `ChainTime` that allows nodes to reach agreement about when a staker starts and stops staking. These start/stop times are basic inputs to determine whether the staker should be rewarded based on what percentage of `ChainTime` it was perceived as active from other validators.
    10  
    11  Note that this `ChainTime` has nothing to do with the `Snowman++` timestamp. `Snowman++` timestamps are local times used to reduce network congestion and have no role in rewarding of any staker.
    12  
    13  ## Pre Banff fork context
    14  
    15  Before the Banff fork activation, `ChainTime` was incremented by an `AdvanceTimeTx` transaction, being included into an `ApricotProposalBlock` block type. Validators voted on `ChainTime` advance by accepting either the `ApricotCommitBlock` or the `ApricotAbortBlock` following the `ApricotProposalBlock`. `ChainTime` was moved ahead only if the `CommitBlock` was accepted.
    16  
    17  `AdvanceTimeTx` transactions are subject to three main validations:
    18  
    19  1. *Strict Monotonicity*: proposed time must be *strictly* greater than current `ChainTime`.
    20  2. *Synchronicity*: proposed time must not be greater than node’s current time plus a synchronicity bound (currently set to 10 seconds).
    21  3. *No Skipping*: proposed time must be less than or equal to the next staking event, that is start/end of any staker.
    22  
    23  Note that *Synchronicity* makes sure that `ChainTime` approximates “real” time flow. If we dropped synchronicity requirement, a staker could declare any staking time and immediately push `ChainTime` to the end, so as to pocket a reward without having actually carried out any activity in the “real” time.
    24  
    25  ## Post Banff fork context
    26  
    27  Following the Banff fork activation, `AdvanceTimeTx`s cannot be included anymore in any block. Instead, each P-chain block type explicitly serializes a timestamp so that `ChainTime` is set to the block timestamp once the block is accepted.
    28  
    29  Validation rules for block timestamps varies slightly depending on block types:
    30  
    31  * `BanffCommitBlock`s and `BanffAbortBlock`s timestamp must be equal to the timestamp of the `BanffProposalBlock` they depend upon.
    32  * `BanffStandardBlock`s and `BanffProposalBlock`s share `AdvanceTimeTx`s validation rules with the exception of the *strict monotonicity*:
    33    1. *Monotonicity*: block timestamp must be *greater than or equal to* the current `ChainTime` (which is also its parent's timestamp if the parent was accepted).
    34    2. *Synchronicity*: block timestamp must not be greater than node’s current time plus a synchronicity bound (currently set to 10 seconds).
    35    3. *No Skipping*: proposed time must be less than or equal to the next staking event (a staker starting or stopping).