update adr-016 (#2435)
This commit is contained in:
parent
26aa978456
commit
a045c562a2
|
@ -4,9 +4,17 @@
|
||||||
|
|
||||||
- How to / should we version the authenticated encryption handshake itself (ie.
|
- How to / should we version the authenticated encryption handshake itself (ie.
|
||||||
upfront protocol negotiation for the P2PVersion)
|
upfront protocol negotiation for the P2PVersion)
|
||||||
|
- How to / should we version ABCI itself? Should it just be absorbed by the
|
||||||
|
BlockVersion?
|
||||||
|
|
||||||
## Changelog
|
## Changelog
|
||||||
|
|
||||||
|
- 18-09-2018: Updates after working a bit on implementation
|
||||||
|
- ABCI Handshake needs to happen independently of starting the app
|
||||||
|
conns so we can see the result
|
||||||
|
- Add question about ABCI protocol version
|
||||||
|
- 16-08-2018: Updates after discussion with SDK team
|
||||||
|
- Remove signalling for next version from Header/ABCI
|
||||||
- 03-08-2018: Updates from discussion with Jae:
|
- 03-08-2018: Updates from discussion with Jae:
|
||||||
- ProtocolVersion contains Block/AppVersion, not Current/Next
|
- ProtocolVersion contains Block/AppVersion, not Current/Next
|
||||||
- signal upgrades to Tendermint using EndBlock fields
|
- signal upgrades to Tendermint using EndBlock fields
|
||||||
|
@ -19,18 +27,18 @@
|
||||||
|
|
||||||
## Context
|
## Context
|
||||||
|
|
||||||
|
Here we focus on software-agnostic protocol versions.
|
||||||
|
|
||||||
The Software Version is covered by SemVer and described elsewhere.
|
The Software Version is covered by SemVer and described elsewhere.
|
||||||
It is not relevant to the protocol description, suffice to say that if any protocol version
|
It is not relevant to the protocol description, suffice to say that if any protocol version
|
||||||
changes, the software version changes, but not necessarily vice versa.
|
changes, the software version changes, but not necessarily vice versa.
|
||||||
|
|
||||||
Software version shoudl be included in NodeInfo for convenience/diagnostics.
|
Software version should be included in NodeInfo for convenience/diagnostics.
|
||||||
|
|
||||||
We are also interested in versioning across different blockchains in a
|
We are also interested in versioning across different blockchains in a
|
||||||
meaningful way, for instance to differentiate branches of a contentious
|
meaningful way, for instance to differentiate branches of a contentious
|
||||||
hard-fork. We leave that for a later ADR.
|
hard-fork. We leave that for a later ADR.
|
||||||
|
|
||||||
Here we focus on protocol versions.
|
|
||||||
|
|
||||||
## Requirements
|
## Requirements
|
||||||
|
|
||||||
We need to version components of the blockchain that may be independently upgraded.
|
We need to version components of the blockchain that may be independently upgraded.
|
||||||
|
@ -86,11 +94,9 @@ to connect to peers with older version.
|
||||||
|
|
||||||
Each component of the software is independently versioned in a modular way and its easy to mix and match and upgrade.
|
Each component of the software is independently versioned in a modular way and its easy to mix and match and upgrade.
|
||||||
|
|
||||||
Good luck pal ;)
|
|
||||||
|
|
||||||
## Proposal
|
## Proposal
|
||||||
|
|
||||||
Each of BlockVersion, AppVersion, P2PVersion is a monotonically increasing int64.
|
Each of BlockVersion, AppVersion, P2PVersion, is a monotonically increasing int64.
|
||||||
|
|
||||||
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.
|
||||||
|
|
||||||
|
@ -100,19 +106,16 @@ Block Header should include a `Version` struct as its first field like:
|
||||||
|
|
||||||
```
|
```
|
||||||
type Version struct {
|
type Version struct {
|
||||||
CurrentVersion ProtocolVersion
|
Block int64
|
||||||
ChainID string
|
App int64
|
||||||
|
|
||||||
NextVersion ProtocolVersion
|
|
||||||
}
|
|
||||||
|
|
||||||
type ProtocolVersion struct {
|
|
||||||
BlockVersion int64
|
|
||||||
AppVersion int64
|
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
Note this effectively makes BlockVersion the first field in the block Header.
|
Here, `Version.Block` defines the rules for the current block, while
|
||||||
|
`Version.App` defines the app version that processed the last block and computed
|
||||||
|
the `AppHash` in the current block. Together they provide a complete description
|
||||||
|
of the consensus-critical protocol.
|
||||||
|
|
||||||
Since we have settled on a proto3 header, the ability to read the BlockVersion out of the serialized header is unanimous.
|
Since we have settled on a proto3 header, the ability to read the BlockVersion out of the serialized header is unanimous.
|
||||||
|
|
||||||
Using a Version struct gives us more flexibility to add fields without breaking
|
Using a Version struct gives us more flexibility to add fields without breaking
|
||||||
|
@ -120,8 +123,6 @@ the header.
|
||||||
|
|
||||||
The ProtocolVersion struct includes both the Block and App versions - it should
|
The ProtocolVersion struct includes both the Block and App versions - it should
|
||||||
serve as a complete description of the consensus-critical protocol.
|
serve as a complete description of the consensus-critical protocol.
|
||||||
Using the `NextVersion` field, proposer's can signal their readiness to upgrade
|
|
||||||
to a new Block and/or App version.
|
|
||||||
|
|
||||||
### NodeInfo
|
### NodeInfo
|
||||||
|
|
||||||
|
@ -129,23 +130,21 @@ NodeInfo should include a Version struct as its first field like:
|
||||||
|
|
||||||
```
|
```
|
||||||
type Version struct {
|
type Version struct {
|
||||||
P2PVersion int64
|
P2P int64
|
||||||
|
Block int64
|
||||||
|
App int64
|
||||||
|
|
||||||
ChainID string
|
Other []string
|
||||||
BlockVersion int64
|
|
||||||
AppVersion int64
|
|
||||||
SoftwareVersion string
|
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
Note this effectively makes P2PVersion the first field in the NodeInfo, so it
|
Note this effectively makes `Version.P2P` the first field in the NodeInfo, so it
|
||||||
should be easy to read this out of the serialized header if need be to facilitate an upgrade.
|
should be easy to read this out of the serialized header if need be to facilitate an upgrade.
|
||||||
|
|
||||||
The SoftwareVersion here should include the name of the software client and
|
The `Version.Other` here should include additional information like the name of the software client and
|
||||||
it's SemVer version - this is for convenience only. Eg.
|
it's SemVer version - this is for convenience only. Eg.
|
||||||
`tendermint-core/v0.22.8`.
|
`tendermint-core/v0.22.8`. It's a `[]string` so it can include information about
|
||||||
|
the version of Tendermint, of the app, of Tendermint libraries, etc.
|
||||||
The other versions and ChainID will determine peer compatibility (described below).
|
|
||||||
|
|
||||||
### ABCI
|
### ABCI
|
||||||
|
|
||||||
|
@ -158,6 +157,11 @@ version information.
|
||||||
We also need to be able to update versions in the life of a blockchain. The
|
We also need to be able to update versions in the life of a blockchain. The
|
||||||
natural place to do this is EndBlock.
|
natural place to do this is EndBlock.
|
||||||
|
|
||||||
|
Note that currently the result of the Handshake isn't exposed anywhere, as the
|
||||||
|
handshaking happens inside the `proxy.AppConns` abstraction. We will need to
|
||||||
|
remove the handshaking from the `proxy` package so we can call it independently
|
||||||
|
and get the result, which should contain the application version.
|
||||||
|
|
||||||
#### Info
|
#### Info
|
||||||
|
|
||||||
RequestInfo should add support for protocol versions like:
|
RequestInfo should add support for protocol versions like:
|
||||||
|
@ -199,28 +203,24 @@ message ResponseEndBlock {
|
||||||
ConsensusParams consensus_param_updates
|
ConsensusParams consensus_param_updates
|
||||||
repeated common.KVPair tags
|
repeated common.KVPair tags
|
||||||
|
|
||||||
VersionUpdates version_updates
|
VersionUpdate version_update
|
||||||
}
|
}
|
||||||
|
|
||||||
message VersionUpdates {
|
message VersionUpdate {
|
||||||
ProtocolVersion current_version
|
|
||||||
ProtocolVersion next_version
|
|
||||||
}
|
|
||||||
|
|
||||||
message ProtocolVersion {
|
|
||||||
int64 block_version
|
|
||||||
int64 app_version
|
int64 app_version
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
Tendermint will use the information in VersionUpdates for the next block it
|
Tendermint will use the information in VersionUpdate for the next block it
|
||||||
proposes.
|
proposes.
|
||||||
|
|
||||||
### BlockVersion
|
### BlockVersion
|
||||||
|
|
||||||
BlockVersion is included in both the Header and the NodeInfo.
|
BlockVersion is included in both the Header and the NodeInfo.
|
||||||
|
|
||||||
Changing BlockVersion should happen quite infrequently and ideally only for extreme emergency.
|
Changing BlockVersion should happen quite infrequently and ideally only for
|
||||||
|
critical upgrades. For now, it is not encoded in ABCI, though it's always
|
||||||
|
possible to use tags to signal an external process to co-ordinate an upgrade.
|
||||||
|
|
||||||
Note Ethereum has not had to make an upgrade like this (everything has been at state machine level, AFAIK).
|
Note Ethereum has not had to make an upgrade like this (everything has been at state machine level, AFAIK).
|
||||||
|
|
||||||
|
@ -251,7 +251,7 @@ this is the first byte of a 32-byte ed25519 pubkey.
|
||||||
|
|
||||||
AppVersion is also included in the block Header and the NodeInfo.
|
AppVersion is also included in the block Header and the NodeInfo.
|
||||||
|
|
||||||
AppVersion essentially defines how the AppHash and Results are computed.
|
AppVersion essentially defines how the AppHash and LastResults are computed.
|
||||||
|
|
||||||
### Peer Compatibility
|
### Peer Compatibility
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue