Modify IBC client governance unfreezing to reflect ADR changes #8405

colin-axner · 2021-01-21T16:41:47Z

Description

closes: #8197
closes: #8299

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

Targeted PR against correct branch (see CONTRIBUTING.md)
Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
Code follows the module structure standards.
Wrote unit and integration tests
Updated relevant documentation (docs/) or specification (x/<module>/spec/)
Added relevant godoc comments.
Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
Re-reviewed Files changed in the Github PR explorer
Review Codecov Report in the comment section below once CI passes

…-unfreeze-clients-gov-prop

colin-axner · 2021-01-21T16:47:45Z

I can document this in the specs, but some rationale for the current design

Cannot use substitute with different revision number: our consensus state key isn't fully lexicographical ordered since I believe we don't pack the revision numbers to 8 bytes. For now we can disallow this feature and add it later once range queries are easily supported. The likelyhood of an upgrade of a counterparty and a gov proposal occurring during the same time period seems very unlikely

Client implementations must copy consensus states/metadata: Clients will need the prefixed stores to copy metadata so pushing the burden on them to selectively choose what is needed is easiest and most flexible.

…mos/cosmos-sdk into colin/8197-unfreeze-clients-gov-prop

colin-axner · 2021-01-22T12:06:37Z

x/ibc/core/02-client/keeper/proposal.go

+// number of the subject client is explicityly disallowed. We cannot support
+// this until there is a way to range query for the all the consensus
+// states which occurred between two IBC Revision heights.
+// https://github.com/cosmos/cosmos-sdk/issues/7712
 func (k Keeper) ClientUpdateProposal(ctx sdk.Context, p *types.ClientUpdateProposal) error {


I thought of trying to enforce subject and substitute client types being equal here but just doing ClientType() doesn't add any more security from a malicious light client implementation, and if the light client implementation is malicious, it could just mess with other clients of its own type.

It is up to governance never to pass a vote where the subject belongs to a malicious light client implementation. Ideally, best practice (which I will document/recommend) would be to create an entirely new substitute client after the subject became frozen/expired. This way no other connection/channels are relying on the substitute.

…-unfreeze-clients-gov-prop

fedekunze

LGTM

x/ibc/core/02-client/types/errors.go

x/ibc/core/exported/client.go

cwgoes

ACK modulo minor doc nits

docs/ibc/proposals.md

cwgoes · 2021-02-10T22:47:06Z

docs/ibc/proposals.md

+evidence of such misbehaviour is likely to be submitted resulting in a frozen light client. 
+
+Frozen light clients cannot be updated under any circumstance except via a governance proposal.
+Since validators can arbitarily agree to make state transitions that defy the written code, a 


I don't understand this sentence, what is the relation? Do you mean that the security model would be the same?

Yes, I was just trying to refer to the security model outlined in the ADR. Why this feature is safe and why it requires a governance proposal. Is there a way I could clarify this better?

"a quorum validators can sign arbitrary state roots which may not be valid executions of the state machine"

something like this is clearer I think

cwgoes · 2021-02-10T22:47:34Z

docs/ibc/proposals.md

+Tendermint light clients may also become expired if the trusting period has passed since their 
+last update. If a chain undergoes an unplanned upgrade, there may be no commitment to that upgrade
+signed by the validator set before the chain-id changes. In this situation, the validator set of
+the last valid update for the light client is never expected to produce another valid header since 
+the chain-id has changed, which will ultimately lead the on-chain light client to become expired.  


I also don't understand the question

cwgoes · 2021-02-10T22:47:59Z

docs/ibc/proposals.md

+Tendermint light clients may also become expired if the trusting period has passed since their 
+last update. If a chain undergoes an unplanned upgrade, there may be no commitment to that upgrade
+signed by the validator set before the chain-id changes. In this situation, the validator set of
+the last valid update for the light client is never expected to produce another valid header since 
+the chain-id has changed, which will ultimately lead the on-chain light client to become expired.  


Oh, do you mean that they could be expired just because no headers have been submitted even if there was no unplanned upgrade?

cwgoes · 2021-02-10T22:48:05Z

docs/ibc/proposals.md

+Tendermint light clients may also become expired if the trusting period has passed since their 
+last update. If a chain undergoes an unplanned upgrade, there may be no commitment to that upgrade
+signed by the validator set before the chain-id changes. In this situation, the validator set of
+the last valid update for the light client is never expected to produce another valid header since 
+the chain-id has changed, which will ultimately lead the on-chain light client to become expired.  


Yeah, that should be clarified.

Co-authored-by: Christopher Goes <[email protected]>

AdityaSripal · 2021-02-11T14:56:56Z

docs/ibc/proposals.md

+Tendermint light clients may also become expired if the trusting period has passed since their 
+last update. If a chain undergoes an unplanned upgrade, there may be no commitment to that upgrade
+signed by the validator set before the chain-id changes. In this situation, the validator set of
+the last valid update for the light client is never expected to produce another valid header since 
+the chain-id has changed, which will ultimately lead the on-chain light client to become expired.  


The case when a light client is expired is a different situation from when the chain undergoes an unplanned upgrades.

x/ibc/core/02-client/keeper/proposal_test.go

x/ibc/light-clients/06-solomachine/types/proposal_handle_test.go

x/ibc/light-clients/07-tendermint/types/proposal_handle.go

AdityaSripal · 2021-02-11T15:24:48Z

x/ibc/light-clients/07-tendermint/types/proposal_handle.go

 		)
 	}

+	// substitute clients are not allowed to be upgraded during the voting period
+	if substituteClientState.GetLatestHeight().GetRevisionNumber() != initialHeight.GetRevisionNumber() {


NOTE: This logic may cause neighboring consensus states to have a time difference of more than the subject's trusting period.

I personally don't believe that is an issue.

x/ibc/light-clients/07-tendermint/types/proposal_handle_test.go

Co-authored-by: Aditya <[email protected]>

…-unfreeze-clients-gov-prop

…mos/cosmos-sdk into colin/8197-unfreeze-clients-gov-prop

…-unfreeze-clients-gov-prop

x/ibc/core/02-client/types/proposal.go

colin-axner · 2021-02-12T15:41:23Z

@fedekunze I noticed the ibc cli command for this was missing from the gaiad tx gov submit-proposal outputs. How do I wire it up?

Edit: nevermind

…mos/cosmos-sdk into colin/8197-unfreeze-clients-gov-prop

colin-axner · 2021-02-16T15:14:58Z

Tested simple case using 5m trusting period and 10m voting period. Client was unexpired and can process packets

…mos/cosmos-sdk into colin/8197-unfreeze-clients-gov-prop

AdityaSripal

utACK

@AdityaSripal

…s#8405) * update proto files * make proto-gen * update clienttypes * update localhost and solo machine * refactor tm client proposal handling * copy metadata * self review fixes * update 02-client keeper tests * fix 02-client type tests * fix localhost and solomachine tests * begin updating tm tests * partially fix tm tests * increase codecov * add more tests * add changelog * update specs * add docs * fix test * modify adr * allow modified chain-ids * add CLI command * fix typos * fix lint * Apply suggestions from code review Co-authored-by: Federico Kunze <[email protected]> * update docs, rm example * Update docs/ibc/proposals.md Co-authored-by: Christopher Goes <[email protected]> * update height checks to reflect chain-id changes cc @AdityaSripal * Apply suggestions from code review Co-authored-by: Christopher Goes <[email protected]> * Apply suggestions from code review Co-authored-by: Aditya <[email protected]> * address most of @AdityaSripal suggestions * update docs per review suggestions * Update x/ibc/core/02-client/types/proposal.go * add proposal handler * register proposal type * register proposal on codec * fix routing Co-authored-by: Federico Kunze <[email protected]> Co-authored-by: Christopher Goes <[email protected]> Co-authored-by: Aditya <[email protected]>

colin-axner added 8 commits January 19, 2021 11:44

update proto files

a654f27

Merge branch 'master' of github.com:cosmos/cosmos-sdk into colin/8197…

9aa500c

…-unfreeze-clients-gov-prop

Merge branch 'master' of github.com:cosmos/cosmos-sdk into colin/8197…

51b5001

…-unfreeze-clients-gov-prop

make proto-gen

a47dbbb

update clienttypes

73b2821

update localhost and solo machine

8d27dcf

refactor tm client proposal handling

fcb97ff

Merge branch 'master' into colin/8197-unfreeze-clients-gov-prop

0e93fb6

colin-axner added 2 commits January 21, 2021 17:50

copy metadata

bbd6d26

Merge branch 'colin/8197-unfreeze-clients-gov-prop' of github.com:cos…

0282996

…mos/cosmos-sdk into colin/8197-unfreeze-clients-gov-prop

colin-axner added the x/ibc label Jan 21, 2021

colin-axner added 3 commits January 22, 2021 12:27

self review fixes

ce4fe37

update 02-client keeper tests

c4cb7de

fix 02-client type tests

a7ef263

colin-axner commented Jan 22, 2021

View reviewed changes

colin-axner added 7 commits January 22, 2021 17:17

fix localhost and solomachine tests

d15f901

begin updating tm tests

0c6d98d

partially fix tm tests

fa28622

increase codecov

4c6688c

add more tests

a041987

Merge branch 'master' of github.com:cosmos/cosmos-sdk into colin/8197…

eefccd5

…-unfreeze-clients-gov-prop

add changelog

a5bc8d5

colin-axner requested review from AdityaSripal, fedekunze and cwgoes January 29, 2021 14:33

colin-axner added 2 commits January 29, 2021 17:16

update specs

861b1cb

add docs

908e5a0

fedekunze approved these changes Jan 29, 2021

View reviewed changes

x/ibc/core/02-client/types/errors.go Outdated Show resolved Hide resolved

x/ibc/core/exported/client.go Outdated Show resolved Hide resolved

Merge branch 'master' into colin/8197-unfreeze-clients-gov-prop

51905db

colin-axner requested review from AdityaSripal and cwgoes February 10, 2021 12:51

cwgoes approved these changes Feb 10, 2021

View reviewed changes

Apply suggestions from code review

b14ea6c

Co-authored-by: Christopher Goes <[email protected]>

AdityaSripal requested changes Feb 11, 2021

View reviewed changes

colin-axner and others added 6 commits February 11, 2021 16:48

Apply suggestions from code review

bbb4acf

Co-authored-by: Aditya <[email protected]>

address most of @AdityaSripal suggestions

10dfe43

Merge branch 'master' of github.com:cosmos/cosmos-sdk into colin/8197…

1edf9ab

…-unfreeze-clients-gov-prop

Merge branch 'colin/8197-unfreeze-clients-gov-prop' of github.com:cos…

eb5823c

…mos/cosmos-sdk into colin/8197-unfreeze-clients-gov-prop

Merge branch 'master' of github.com:cosmos/cosmos-sdk into colin/8197…

e01e8c5

…-unfreeze-clients-gov-prop

update docs per review suggestions

1869fbd

colin-axner requested a review from AdityaSripal February 12, 2021 14:41

colin-axner commented Feb 12, 2021

View reviewed changes

x/ibc/core/02-client/types/proposal.go Outdated Show resolved Hide resolved

Update x/ibc/core/02-client/types/proposal.go

84ebde6

colin-axner added 6 commits February 12, 2021 16:49

add proposal handler

912fdf5

Merge branch 'colin/8197-unfreeze-clients-gov-prop' of github.com:cos…

613cf69

…mos/cosmos-sdk into colin/8197-unfreeze-clients-gov-prop

register proposal type

b7834c6

register proposal on codec

1ba2c3d

fix routing

9fae3ce

Merge branch 'master' into colin/8197-unfreeze-clients-gov-prop

26837e2

Merge branch 'colin/8197-unfreeze-clients-gov-prop' of github.com:cos…

a5c09a7

…mos/cosmos-sdk into colin/8197-unfreeze-clients-gov-prop

AdityaSripal approved these changes Feb 16, 2021

View reviewed changes

colin-axner added the A:automerge Automatically merge PR once all prerequisites pass. label Feb 16, 2021

mergify bot merged commit 47dd07d into master Feb 16, 2021

mergify bot deleted the colin/8197-unfreeze-clients-gov-prop branch February 16, 2021 15:31

colin-axner mentioned this pull request Mar 4, 2021

Allow multiple subject clients to be updated with a substitute for IBC unfreezing governance proposal cosmos/ibc-go#17

Closed

4 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Modify IBC client governance unfreezing to reflect ADR changes #8405

Modify IBC client governance unfreezing to reflect ADR changes #8405

colin-axner commented Jan 21, 2021 •

edited

Loading

colin-axner commented Jan 21, 2021

colin-axner Jan 22, 2021

fedekunze left a comment

cwgoes left a comment

cwgoes Feb 10, 2021

colin-axner Feb 11, 2021

cwgoes Feb 11, 2021

cwgoes Feb 10, 2021

cwgoes Feb 10, 2021

cwgoes Feb 10, 2021

AdityaSripal Feb 11, 2021

AdityaSripal Feb 11, 2021

colin-axner commented Feb 12, 2021 •

edited

Loading

colin-axner commented Feb 16, 2021

AdityaSripal left a comment

Modify IBC client governance unfreezing to reflect ADR changes #8405

Modify IBC client governance unfreezing to reflect ADR changes #8405

Conversation

colin-axner commented Jan 21, 2021 • edited Loading

Description

colin-axner commented Jan 21, 2021

Choose a reason for hiding this comment

fedekunze left a comment

Choose a reason for hiding this comment

cwgoes left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

colin-axner commented Feb 12, 2021 • edited Loading

colin-axner commented Feb 16, 2021

AdityaSripal left a comment

Choose a reason for hiding this comment

colin-axner commented Jan 21, 2021 •

edited

Loading

colin-axner commented Feb 12, 2021 •

edited

Loading