update to indicate upgrade with is dependent on other work

This commit is contained in:
William Banfield
2022-01-13 14:07:41 -05:00
parent 2c9bfa32ae
commit 45ebcdd5fc
+9 -34
View File
@@ -168,41 +168,14 @@ namely, each value must be non-negative.
### Migration
Migration to using these new parameters will occur across two releases.
During the v0.36 release, Tendermint will add these as consensus parameters.
The old local config parameters will continue to exist as well in the
v0.36 release. If the parameters are set as consensus parameters, the config-local
parameters will be ignored. If the consensus parameters are not set, Tendermint
will fall back to using the values contained in the `config.toml` file.
The new `ConsensusParameters` will be added during an upcoming release. In this
release, the old `config.toml` parameters will cease to control the timeouts and
an error will be logged on nodes that continue to specify these values. The specific
mechanism by which these parameters will added to a chain is being discussed in
[RFC-009][rfc-009] and will be decided ahead of the next release.
During the v0.36 release cycle, if non-default values are set in the `config.toml`,
the node will log a warning alerting operators that the parameters will soon be removed
in the upcoming release.
In the v0.37 release, the config-local parameters will be removed. If a node
continues to set the parameters in the configuration file, an error will be logged
that indicates how to upgrade or remove them.
### Add New Consensus Parameters to HashedParams
Tendermint currently only verifies that a subset of the consensus parameters are
equal across all validators. These parameters are the `BlockMaxBytes` and the `BlockMaxGas`.
A [hash of these parameters][hashed-params] is included in the block. Validators ensure
their values of the parameters match by hashing their value of the parameters and
checking that their hashed value matches the hash included in the block.
Including the new parameters in this hash could break verification of old blocks.
To add the parameters in a hash-compatible way, we will only include these consensus
parameters in the hash if they have ever been updated to be non-default values.
This is safe for validation of historic blocks because the parameters could not have
been set during heights where they did not exist. Eliding them from the hash
them will therefore produce the same hash that would have been produced as before
they existed.
For backwards compatibility, Tendermint will keep track of these initial default
values for each of these parameters. If the defaults ever change, our hash-compatible
upgrade scheme requires remembering the initial defaults so as to ignore the parameters
when that initial default is being used.
The specific mechanism for adding these parameters depends on work related to
[soft upgrades][soft-upgrades], which is still ongoing.
## Consequences
@@ -229,3 +202,5 @@ when that initial default is being used.
[tendermint-issue-5911-comment]: https://github.com/tendermint/tendermint/issues/5911#issuecomment-973560381
[spec-issue-359]: https://github.com/tendermint/spec/issues/359
[arxiv-paper]: https://arxiv.org/pdf/1807.04938.pdf
[soft-upgrades]: https://github.com/tendermint/spec/pull/222
[rfc-009]: https://github.com/tendermint/tendermint/pull/7524