rfc: add section on vote extension upgrade path

This commit is contained in:
William Banfield
2022-05-08 22:41:04 -04:00
parent cec0a97987
commit 529330a514

View File

@@ -5,6 +5,7 @@
- 11-Apr-2022: Initial draft (@sergio-mena).
- 15-Apr-2022: Addressed initial comments. First complete version (@sergio-mena).
- 09-May-2022: Addressed all outstanding comments.
- 09-May-2022: Add section on upgrade path (@wbanfield)
## Abstract
@@ -553,6 +554,32 @@ Then, we need to handle two new situations, roughly equivalent to cases (h.1) an
However we can manually have the node crash and recover as a workaround. This effectively converts
this case into (h.1).
### Upgrade Path
v0.36 of Tendermint will be the first version to implement the vote extension system.
The v0.36 release aims to be backwards compatible with the previous release, v0.35,
which had no implementation of vote extensions and no mechanisms in place to facilitate
their later addition.
Vote extensions pose an issue for Tendermint upgrades. Chains that upgrade from
v0.35 to v0.36 will attempt to produce the first height running v0.36 without vote
extension data from the previous height. We intend to allow chains to _require_
vote extensions data. Chains that do so will not make progress without vote
extension data and the corresponding application will expect vote extension
data to be present for [PrepareProposal](https://github.com/tendermint/tendermint/blob/cec0a9798/proto/tendermint/abci/types.proto#L129) call it receives.
To facilitate the upgrade and provide applications a mechanism to require
vote extensions, we will provide application developers with a [ConsensusParam](https://github.com/tendermint/tendermint/blob/cec0a9798/proto/tendermint/types/params.proto#L13)
to transition the chain from no history of vote extensions to requiring vote extensions.
This parameter will be an `int64` representing the first height where vote extensions
will be required for votes to be considered valid. Once the configured height occurs,
the parameter will be disallowed from changing, meaning that vote extensions cannot flip from being
required to again being optional. Whatever system is created for transitioning a
chain to requiring vote extensions needs to save the height at which the
parameter changed so that Tendermint can determine whether or not to enforce
vote extension presence on the `PrepareProposal` call. For further clarification
and implementation, see [issue 8453](https://github.com/tendermint/tendermint/issues/8453)
### Formalization Work
A formalization work to show or prove the correctness of the different use cases and solutions