mirrors/tendermint
1
0
Fork 0
mirror of https://github.com/tendermint/tendermint.git synced 2026-08-16 20:26:12 +00:00
Code Issues Packages Projects Releases Wiki Activity

blockchain: change validator set sorting method (#91)

Browse Source 
* abci: specify sorting of RequestInitChain.Validators

* blockchain: change validator sorting method

Refs https://github.com/tendermint/tendermint/issues/2478
This commit is contained in:
Anton Kaliaev
2020-05-06 11:02:20 +04:00
committed by GitHub
parent 90797cef90
commit c3cd54a8e0
3 changed files with 10 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files
spec/abci/abci.md
+5 -5
View File
@@ -216,17 +216,17 @@ Commit are included in the header of the next block.
- `Time (google.protobuf.Timestamp)`: Genesis time.
- `ChainID (string)`: ID of the blockchain.
- `ConsensusParams (ConsensusParams)`: Initial consensus-critical parameters.
- `Validators ([]ValidatorUpdate)`: Initial genesis validators.
- `Validators ([]ValidatorUpdate)`: Initial genesis validators, sorted by voting power.
- `AppStateBytes ([]byte)`: Serialized initial application state. Amino-encoded JSON bytes.
- **Response**:
- `ConsensusParams (ConsensusParams)`: Initial
consensus-critical parameters.
- `Validators ([]ValidatorUpdate)`: Initial validator set (if non empty).
consensus-critical parameters (optional).
- `Validators ([]ValidatorUpdate)`: Initial validator set (optional).
- **Usage**:
- Called once upon genesis.
- If ResponseInitChain.Validators is empty, the initial validator set will be the RequestInitChain.Validators
- If ResponseInitChain.Validators is not empty, the initial validator set will be the
ResponseInitChain.Validators (regardless of what is in RequestInitChain.Validators).
- If ResponseInitChain.Validators is not empty, it will be the initial
validator set (regardless of what is in RequestInitChain.Validators).
- This allows the app to decide if it wants to accept the initial validator
set proposed by tendermint (ie. in the genesis file), or if it wants to use
a different one (perhaps computed based on some application specific
spec/blockchain/blockchain.md
+2 -2
View File
@@ -343,7 +343,7 @@ block.ValidatorsHash == MerkleRoot(state.Validators)
MerkleRoot of the current validator set that is committing the block.
This can be used to validate the `LastCommit` included in the next block.
Note the validators are sorted by their address before computing the MerkleRoot.
Note the validators are sorted by their voting power before computing the MerkleRoot.
### NextValidatorsHash
@@ -354,7 +354,7 @@ block.NextValidatorsHash == MerkleRoot(state.NextValidators)
MerkleRoot of the next validator set that will be the validator set that commits the next block.
This is included so that the current validator set gets a chance to sign the
next validator sets Merkle root.
Note the validators are sorted by their address before computing the MerkleRoot.
Note the validators are sorted by their voting power before computing the MerkleRoot.
### ConsensusHash
spec/blockchain/state.md
+3 -2
View File
@@ -62,8 +62,9 @@ type Validator struct {
When hashing the Validator struct, the address is not included,
because it is redundant with the pubkey.
The `state.Validators`, `state.LastValidators`, and `state.NextValidators`, must always be sorted by validator address,
so that there is a canonical order for computing the MerkleRoot.
The `state.Validators`, `state.LastValidators`, and `state.NextValidators`,
must always be sorted by voting power, so that there is a canonical order for
computing the MerkleRoot.
We also define a `TotalVotingPower` function, to return the total voting power: