fluencelabs/tendermint
1
0
Fork 0
mirror of https://github.com/fluencelabs/tendermint synced 2025-04-25 14:52:17 +00:00
Code Issues Projects Releases Wiki Activity

adr-016: update int64->uint64; add version to ConsensusParams (#2667)

Browse Source
This commit is contained in:
Ethan Buchman 2018-10-18 17:32:53 -04:00 committed by GitHub
parent ed4ce5ff6c
commit c3384e88e5
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 29 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

51
docs/architecture/adr-016-protocol-versions.md
View File

@ -96,7 +96,7 @@ Each component of the software is independently versioned in a modular way and i
## Proposal ## Proposal
Each of BlockVersion, AppVersion, P2PVersion, is a monotonically increasing int64. Each of BlockVersion, AppVersion, P2PVersion, is a monotonically increasing uint64.
To use these versions, we need to update the block Header, the p2p NodeInfo, and the ABCI. To use these versions, we need to update the block Header, the p2p NodeInfo, and the ABCI.
@ -106,8 +106,8 @@ Block Header should include a `Version` struct as its first field like:
``` ```
type Version struct { type Version struct {
Block int64 Block uint64
App int64 App uint64
} }
``` ```
@ -130,9 +130,9 @@ NodeInfo should include a Version struct as its first field like:
``` ```
type Version struct { type Version struct {
P2P int64 P2P uint64
Block int64 Block uint64
App int64 App uint64
Other []string Other []string
} }
@ -168,9 +168,9 @@ RequestInfo should add support for protocol versions like:
``` ```
message RequestInfo { message RequestInfo {
string software_version string version
int64 block_version uint64 block_version
int64 p2p_version uint64 p2p_version
} }
``` ```
@ -180,39 +180,46 @@ Similarly, ResponseInfo should return the versions:
message ResponseInfo { message ResponseInfo {
string data string data
string software_version string version
int64 app_version uint64 app_version
int64 last_block_height int64 last_block_height
bytes last_block_app_hash bytes last_block_app_hash
} }
``` ```
The existing `version` fields should be called `software_version` but we leave
them for now to reduce the number of breaking changes.
#### EndBlock #### EndBlock
Updating the version could be done either with new fields or by using the Updating the version could be done either with new fields or by using the
existing `tags`. Since we're trying to communicate information that will be existing `tags`. Since we're trying to communicate information that will be
included in Tendermint block Headers, it should be native to the ABCI, and not included in Tendermint block Headers, it should be native to the ABCI, and not
something embedded through some scheme in the tags. something embedded through some scheme in the tags. Thus, version updates should
be communicated through EndBlock.
ResponseEndBlock will include a new field `version_updates`: EndBlock already contains `ConsensusParams`. We can add version information to
the ConsensusParams as well:
``` ```
message ResponseEndBlock { message ConsensusParams {
repeated Validator validator_updates
ConsensusParams consensus_param_updates
repeated common.KVPair tags
VersionUpdate version_update BlockSize block_size
EvidenceParams evidence_params
VersionParams version
} }
message VersionUpdate { message VersionParams {
int64 app_version uint64 block_version
uint64 app_version
} }
``` ```
Tendermint will use the information in VersionUpdate for the next block it For now, the `block_version` will be ignored, as we do not allow block version
proposes. to be updated live. If the `app_version` is set, it signals that the app's
protocol version has changed, and the new `app_version` will be included in the
`Block.Header.Version.App` for the next block.
### BlockVersion ### BlockVersion