RFC-009: Consensus Parameter Upgrades #7524
Conversation
williambanfield
requested review from
cmwaters,
creachadair,
ebuchman and
tychoish
as code owners
|
Isn't there also an option where each parameter has a height/version information included in its self that would maintain compatibility but also allow parameters to change over the life of a change? |
Is there? I haven't heard of this if there is. From the sound of it, that would solve our problem quite nicely, I just maybe don't know about this feature yet? |
|
|
||
| #### Only Update HashedParams on Hash-Breaking Releases | ||
|
|
||
| An alternate solution to never hashing defaults is to not update the hashed |
There was a problem hiding this comment.
I think I understand this, but it seems subtle. Some hash-breaking changes are obvious, e.g., we change the value for some existing default. But what about adding a(nother) new consensus parameter? Presumably we have to choose a place for it in the global hashing order (e.g., "new parameters always go to the end" or something). Do we hash in its default value immediately?
Also (and this affects other implementation strategies too): What happens if we want to get rid of a consensus parameter? We can't get rid of it from the old blocks that committed to it, but we have to do something about the existing values in the hash order. Do we just leave it at its last-pinned value forever, or "zero" it before deleting, or something else? (We definitely can't remove it from the hash order entirely, or all future changes will be anchored to that merge)
Am I reading too much into it?
There was a problem hiding this comment.
I think that if we always stick to 'defaults are never hashed' we will mostly be fine.
Old blocks will still validate because we effectively consider them as having had the defaults in the past. Removing consensus parameters is the same, they'll just stop being included in the hash.
We can't get rid of it from the old blocks that committed to it, but we have to do something about the existing values in the hash order.
Without a verification/hash-breaking upgrade, we cannot get rid of old consensus parameters. Tendermint would no longer know how to produce the hash of the old blocks so this would break blocksync etc. Verifying old blocks relies on getting consensus parameter updates from the application and hashing these into the block.
There was a problem hiding this comment.
I don't think we can ever truly delete old consensus parameters, for the reason you say. When I say "get rid of" I really mean "agree to stop using". But then there is the question of how to tell nodes that parameter should no longer be used—otherwise it becomes a side channel.
My intuition is that "disabling" a parameter could be done by setting it to a designated "invalid" value and subsequently treating that as the default for subsequent blocks. That would be a hash-breaking change at the point of bugging the value, but presumably not thereafter.
Co-authored-by: M. J. Fromberger <fromberger@interchain.io>
Co-authored-by: M. J. Fromberger <fromberger@interchain.io>
| proposes applying different hashing rules depending on the active block version. | ||
| The consensus parameter hash could be versioned in the same way. When different | ||
| block versions are used, a different set of consensus parameters will be included | ||
| in the hash. |
There was a problem hiding this comment.
This is compatible with the original "defaults" based proposal, in that we still need some rule for how to bootstrap new consensus parameters. 👍🏼
williambanfield
added
the
S:automerge
Related to #7503