Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add strict requirements to upgrading chainID in 02-client UpgradeChain proposal #1309

Closed
3 tasks
colin-axner opened this issue Apr 28, 2022 · 2 comments
Closed
3 tasks
Assignees

Comments

@colin-axner
Copy link
Contributor

Summary

Same as #1308, but it should be applied to the proposal handling in 02-client here

Same switch can be used:

switch { 
case clienttypes.IsRevisionFormat(cs.ChainID):
    // check that the base of the cs.ChainID == base of upgradedClientState.ChainID
    oldChainIDBase := strings.TrimSuffix(chainID, fmt.Sprintf("-%d", clienttypes.ParseChainID(chainID)))
    newChainIDBase := chainID = strings.TrimSuffix(upgradedClientState.ChainID, fmt.Sprintf("-%d", clienttypes.ParseChainID(upgradedClientState.ChainID)))
    if oldChainIDBase != newChainIDBase {
        return err
    }

case cs.ChainID != upgradedClientState.ChainID
    // only allow upgrade from non-revision chainID to a chainID with "-0"
    if upgradedClientState.ChainID != clienttypes.SetRevisionNumber(cs.ChainID, 0) {
        return err
    }
}

For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate contributors tagged/assigned
@colin-axner
Copy link
Contributor Author

Despite this comment we can still implement this proposed change. This will prevent chains from accidentally losing misbehaviour detection support. They will need to explicitly overwrite this functionality

@charleenfei charleenfei self-assigned this Jul 19, 2022
@charleenfei
Copy link
Contributor

after discussion with @colin-axner, we decided the best way forward for this issue is to close it for now.

the reasoning is because the implementation of this issue would basically cause an upgrade to fail if the revision format was not in the expected format. this is important because misbehaviour detection support will be disabled if a chain does not have conformant revision formats. however, the upgrade would fail only AFTER a proposal has passed, as this handler is run only after the passing of the proposal, which is bad UX. therefore, the issue should only be implemented alongside a complete documentation work packet of this aspect of 02 client.

in addition, the implementation of this issue would require casting the client to the Tendermint type, which would need to be updated with Tendermint v2. while this is possible in the short term, in combination with the UX issue mentioned above we decided it was best to postpone this for now until we can flesh out the entire work packet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

No branches or pull requests

2 participants