github.com/Finschia/finschia-sdk@v0.48.1/x/slashing/spec/07_tombstone.md (about)

     1  <!--
     2  order: 7
     3  -->
     4  
     5  # Staking Tombstone
     6  
     7  ## Abstract
     8  
     9  In the current implementation of the `slashing` module, when the consensus engine
    10  informs the state machine of a validator's consensus fault, the validator is
    11  partially slashed, and put into a "jail period", a period of time in which they
    12  are not allowed to rejoin the validator set. However, because of the nature of
    13  consensus faults and ABCI, there can be a delay between an infraction occurring,
    14  and evidence of the infraction reaching the state machine (this is one of the
    15  primary reasons for the existence of the unbonding period).
    16  
    17  > Note: The tombstone concept, only applies to faults that have a delay between
    18  > the infraction occurring and evidence reaching the state machine. For example,
    19  > evidence of a validator double signing may take a while to reach the state machine
    20  > due to unpredictable evidence gossip layer delays and the ability of validators to
    21  > selectively reveal double-signatures (e.g. to infrequently-online light clients).
    22  > Liveness slashing, on the other hand, is detected immediately as soon as the
    23  > infraction occurs, and therefore no slashing period is needed. A validator is
    24  > immediately put into jail period, and they cannot commit another liveness fault
    25  > until they unjail. In the future, there may be other types of byzantine faults
    26  > that have delays (for example, submitting evidence of an invalid proposal as a transaction).
    27  > When implemented, it will have to be decided whether these future types of
    28  > byzantine faults will result in a tombstoning (and if not, the slash amounts
    29  > will not be capped by a slashing period).
    30  
    31  In the current system design, once a validator is put in the jail for a consensus
    32  fault, after the `JailPeriod` they are allowed to send a transaction to `unjail`
    33  themselves, and thus rejoin the validator set.
    34  
    35  One of the "design desires" of the `slashing` module is that if multiple
    36  infractions occur before evidence is executed (and a validator is put in jail),
    37  they should only be punished for single worst infraction, but not cumulatively.
    38  For example, if the sequence of events is:
    39  
    40  1. Validator A commits Infraction 1 (worth 30% slash)
    41  2. Validator A commits Infraction 2 (worth 40% slash)
    42  3. Validator A commits Infraction 3 (worth 35% slash)
    43  4. Evidence for Infraction 1 reaches state machine (and validator is put in jail)
    44  5. Evidence for Infraction 2 reaches state machine
    45  6. Evidence for Infraction 3 reaches state machine
    46  
    47  Only Infraction 2 should have its slash take effect, as it is the highest. This
    48  is done, so that in the case of the compromise of a validator's consensus key,
    49  they will only be punished once, even if the hacker double-signs many blocks.
    50  Because, the unjailing has to be done with the validator's operator key, they
    51  have a chance to re-secure their consensus key, and then signal that they are
    52  ready using their operator key. We call this period during which we track only
    53  the max infraction, the "slashing period".
    54  
    55  Once, a validator rejoins by unjailing themselves, we begin a new slashing period;
    56  if they commit a new infraction after unjailing, it gets slashed cumulatively on
    57  top of the worst infraction from the previous slashing period.
    58  
    59  However, while infractions are grouped based off of the slashing periods, because
    60  evidence can be submitted up to an `unbondingPeriod` after the infraction, we
    61  still have to allow for evidence to be submitted for previous slashing periods.
    62  For example, if the sequence of events is:
    63  
    64  1. Validator A commits Infraction 1 (worth 30% slash)
    65  2. Validator A commits Infraction 2 (worth 40% slash)
    66  3. Evidence for Infraction 1 reaches state machine (and Validator A is put in jail)
    67  4. Validator A unjails
    68  
    69  We are now in a new slashing period, however we still have to keep the door open
    70  for the previous infraction, as the evidence for Infraction 2 may still come in.
    71  As the number of slashing periods increase, it creates more complexity as we have
    72  to keep track of the highest infraction amount for every single slashing period.
    73  
    74  > Note: Currently, according to the `slashing` module spec, a new slashing period
    75  > is created every time a validator is unbonded then rebonded. This should probably
    76  > be changed to jailed/unjailed. See issue [#3205](https://github.com/cosmos/cosmos-sdk/issues/3205)
    77  > for further details. For the remainder of this, I will assume that we only start
    78  > a new slashing period when a validator gets unjailed.
    79  
    80  The maximum number of slashing periods is the `len(UnbondingPeriod) / len(JailPeriod)`.
    81  The current defaults in Gaia for the `UnbondingPeriod` and `JailPeriod` are 3 weeks
    82  and 2 days, respectively. This means there could potentially be up to 11 slashing
    83  periods concurrently being tracked per validator. If we set the `JailPeriod >= UnbondingPeriod`,
    84  we only have to track 1 slashing period (i.e not have to track slashing periods).
    85  
    86  Currently, in the jail period implementation, once a validator unjails, all of
    87  their delegators who are delegated to them (haven't unbonded / redelegated away),
    88  stay with them. Given that consensus safety faults are so egregious
    89  (way more so than liveness faults), it is probably prudent to have delegators not
    90  "auto-rebond" to the validator.
    91  
    92  ### Proposal: infinite jail
    93  
    94  We propose setting the "jail time" for a
    95  validator who commits a consensus safety fault, to `infinite` (i.e. a tombstone state).
    96  This essentially kicks the validator out of the validator set and does not allow
    97  them to re-enter the validator set. All of their delegators (including the operator themselves)
    98  have to either unbond or redelegate away. The validator operator can create a new
    99  validator if they would like, with a new operator key and consensus key, but they
   100  have to "re-earn" their delegations back.
   101  
   102  Implementing the tombstone system and getting rid of the slashing period tracking
   103  will make the `slashing` module way simpler, especially because we can remove all
   104  of the hooks defined in the `slashing` module consumed by the `staking` module
   105  (the `slashing` module still consumes hooks defined in `staking`).
   106  
   107  ### Single slashing amount
   108  
   109  Another optimization that can be made is that if we assume that all ABCI faults
   110  for Tendermint consensus are slashed at the same level, we don't have to keep
   111  track of "max slash". Once an ABCI fault happens, we don't have to worry about
   112  comparing potential future ones to find the max.
   113  
   114  Currently the only Tendermint ABCI fault is:
   115  
   116  - Unjustified precommits (double signs)
   117  
   118  It is currently planned to include the following fault in the near future:
   119  
   120  - Signing a precommit when you're in unbonding phase (needed to make light client bisection safe)
   121  
   122  Given that these faults are both attributable byzantine faults, we will likely
   123  want to slash them equally, and thus we can enact the above change.
   124  
   125  > Note: This change may make sense for current Tendermint consensus, but maybe
   126  > not for a different consensus algorithm or future versions of Tendermint that
   127  > may want to punish at different levels (for example, partial slashing).