consolidate into valset-changes.md

This commit is contained in:
Ethan Buchman 2018-05-08 17:45:05 -04:00
parent 111e7ecd52
commit b8b200ac34
4 changed files with 98 additions and 110 deletions

View File

@ -34,4 +34,8 @@ The following specification uses *Atom* as the native staking token. The module
4. Unbond
5. Redelegate
6. ProveLive
3. **[Validator Set Changes](valset-changes.md)**
1. Validator set updates
2. Slashing
3. Automatic Unbonding
3. **[Future improvements](future_improvements.md)**

View File

@ -1,79 +0,0 @@
# Slashing
A validator bond is an economic commitment made by a validator signing key to both the safety and liveness of
the consensus. Validator keys must not sign invalid messages which could
violate consensus safety, and their signed precommit messages must be regularly included in
block commits.
The incentivization of these two goals are treated separately.
## Safety
Messges which may compromise the safety of the underlying consensus protocol ("equivocations")
result in some amount of the offending validator's shares being removed ("slashed").
Currently, such messages include only the following:
- prevotes by the same validator for more than one BlockID at the same
Height and Round
- precommits by the same validator for more than one BlockID at the same
Height and Round
We call any such pair of conflicting votes `Evidence`. Full nodes in the network prioritize the
detection and gossipping of `Evidence` so that it may be rapidly included in blocks and the offending
validators punished.
For some `evidence` to be valid, it must satisfy:
`evidence.Height >= block.Height - MAX_EVIDENCE_AGE`
If valid evidence is included in a block, the offending validator loses
a constant `SLASH_PROPORTION` of their current stake:
```
oldShares = validator.shares
validator.shares = oldShares * (1 - SLASH_PROPORTION)
```
This ensures that offending validators are punished the same amount whether they
act as a single validator with X stake or as N validators with collectively X
stake.
## Liveness
Every block includes a set of precommits by the validators for the previous block,
known as the LastCommit. A LastCommit is valid so long as it contains precommits from +2/3 of voting power.
Proposers are incentivized to include precommits from all
validators in the LastCommit by receiving additional fees
proportional to the difference between the voting power included in the
LastCommit and +2/3 (see [TODO](https://github.com/cosmos/cosmos-sdk/issues/967)).
Validators are penalized for failing to be included in the LastCommit for some
number of blocks by being automatically unbonded.
TODO: do we do this by trying to track absence directly in the state, using
something like the below, or do we let users notify the app when a validator has
been absent using the
[TxLivenessCheck](https://github.com/cosmos/cosmos-sdk/blob/develop/docs/spec/staking/spec-technical.md#txlivelinesscheck).
A list, `ValidatorAbsenceInfos`, is stored in the state and used to track how often
validators were included in a LastCommit.
```go
// Ordered by ValidatorAddress.
// One entry for each validator.
type ValidatorAbsenceInfos []ValidatorAbsenceInfo
type ValidatorAbsenceInfo struct {
ValidatorAddress []byte // address of the validator
FirstHeight int64 // first height the validator was absent
Count int64 // number of heights validator was absent since (and including) first
}
```

View File

@ -7,7 +7,6 @@ Available Transactions:
* TxDelegate
* TxUnbond
* TxRedelegate
* TxLivelinessCheck
* TxProveLive
## Transaction processing
@ -264,37 +263,10 @@ redelegate(tx TxRedelegate):
return
```
### TxLivelinessCheck
Liveliness issues are calculated by keeping track of the block precommits in
the block header. A queue is persisted which contains the block headers from
all recent blocks for the duration of the unbonding period. A validator is
defined as having livliness issues if they have not been included in more than
33% of the blocks over:
* The most recent 24 Hours if they have >= 20% of global stake
* The most recent week if they have = 0% of global stake
* Linear interpolation of the above two scenarios
Liveliness kicks are only checked when a `TxLivelinessCheck` transaction is
submitted.
```golang
type TxLivelinessCheck struct {
PubKey crypto.PubKey
RewardAccount Addresss
}
```
If the `TxLivelinessCheck` is successful in kicking a validator, 5% of the
liveliness punishment is provided as a reward to `RewardAccount`.
### TxProveLive
If the validator was kicked for liveliness issues and is able to regain
liveliness then all delegators in the temporary unbonding pool which have not
transacted to move will be bonded back to the now-live validator and begin to
once again collect provisions and rewards. Regaining liveliness is demonstrated
by sending in a `TxProveLive` transaction:
If a validator was automatically unbonded due to liveness issues and wishes to
assert it is still online, it can send `TxProveLive`:
```golang
type TxProveLive struct {
@ -302,3 +274,10 @@ type TxProveLive struct {
}
```
All delegators in the temporary unbonding pool which have not
transacted to move will be bonded back to the now-live validator and begin to
once again collect provisions and rewards.
```
TODO: pseudo-code
```

View File

@ -1,5 +1,89 @@
# Slashing
### End of block handling
A validator bond is an economic commitment made by a validator signing key to both the safety and liveness of
the consensus. Validator keys must not sign invalid messages which could
violate consensus safety, and their signed precommit messages must be regularly included in
block commits.
The incentivization of these two goals are treated separately.
## Safety
Messges which may compromise the safety of the underlying consensus protocol ("equivocations")
result in some amount of the offending validator's shares being removed ("slashed").
Currently, such messages include only the following:
- prevotes by the same validator for more than one BlockID at the same
Height and Round
- precommits by the same validator for more than one BlockID at the same
Height and Round
We call any such pair of conflicting votes `Evidence`. Full nodes in the network prioritize the
detection and gossipping of `Evidence` so that it may be rapidly included in blocks and the offending
validators punished.
For some `evidence` to be valid, it must satisfy:
`evidence.Height >= block.Height - MAX_EVIDENCE_AGE`
If valid evidence is included in a block, the offending validator loses
a constant `SLASH_PROPORTION` of their current stake:
```
oldShares = validator.shares
validator.shares = oldShares * (1 - SLASH_PROPORTION)
```
This ensures that offending validators are punished the same amount whether they
act as a single validator with X stake or as N validators with collectively X
stake.
## Liveness
Every block includes a set of precommits by the validators for the previous block,
known as the LastCommit. A LastCommit is valid so long as it contains precommits from +2/3 of voting power.
Proposers are incentivized to include precommits from all
validators in the LastCommit by receiving additional fees
proportional to the difference between the voting power included in the
LastCommit and +2/3 (see [TODO](https://github.com/cosmos/cosmos-sdk/issues/967)).
Validators are penalized for failing to be included in the LastCommit for some
number of blocks by being automatically unbonded.
TODO: do we do this by trying to track absence directly in the state, using
something like the below, or do we let users notify the app when a validator has
been absent using the
[TxLivenessCheck](https://github.com/cosmos/cosmos-sdk/blob/develop/docs/spec/staking/spec-technical.md#txlivelinesscheck).
A list, `ValidatorAbsenceInfos`, is stored in the state and used to track how often
validators were included in a LastCommit.
```go
// Ordered by ValidatorAddress.
// One entry for each validator.
type ValidatorAbsenceInfos []ValidatorAbsenceInfo
type ValidatorAbsenceInfo struct {
ValidatorAddress []byte // address of the validator
FirstHeight int64 // first height the validator was absent
Count int64 // number of heights validator was absent since (and including) first
}
```
### BeginBlock Handling
### EndBlock Handling
This is where we inflate the Atoms and deal with validator set changes.
```golang
tick(ctx Context):