WIP: Delaying a validator set update by 1 block.#1638
WIP: Delaying a validator set update by 1 block.#1638
Conversation
| privValidator types.PrivValidator // for signing votes | ||
|
|
||
| // services for creating and executing blocks | ||
| // TODO: encapsulate all of this in one "BlockManager" |
state/state.go
Outdated
| // Note that if s.LastBlockHeight causes a valset change, | ||
| // we set s.LastHeightValidatorsChanged = s.LastBlockHeight + 1 | ||
| Validators *types.ValidatorSet | ||
| NextNextValidators *types.ValidatorSet |
There was a problem hiding this comment.
why not Validators and NextValidators ?
There was a problem hiding this comment.
You're right, it should be Validators, esp since State is a field of ConsensusState & the way it's used there.
Codecov Report
@@ Coverage Diff @@
## develop #1638 +/- ##
===========================================
- Coverage 61.51% 61.44% -0.07%
===========================================
Files 121 121
Lines 11095 11101 +6
===========================================
- Hits 6825 6821 -4
- Misses 3649 3656 +7
- Partials 621 624 +3
|
|
It would be helpful if you could point to the rationale behind this change? |
|
Hi @kansi, thank you for bringing this up. The transactions in the LastBlock are sufficient for validators to know what the next validator should be, because it can update the validator set based on the validator updates returned by EndBlock. But light clients don't know that, so if the application wants to change the validator set completely 100%, a general purpose tendermint light client can't validate it because it doesn't know how to interpret the txs which caused the validator changes. Delaying validator set updates by 1 block allows the next pending validator set to be included in the block header as "NextValidators", so light clients can know how the validator set changed for a blockchain, even with arbitrary validator set changes. See #1756 which includes the changes to the "lite" packages which can now handle arbitrary validator set changes. |
|
Closing, replaced by #1756 |
No description provided.