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

Upgrade and UpdateClient proposals for Tgrade #191

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

hashedone
Copy link
Collaborator

Addresses #142, #143.

I am not perfectly sure if it is what was expected, but this is what I understood - any leads about what I missed are welcome. Besides adding messages to tgrade gov proposals I added an upgrade plan validation - the name cannot be empty, and the height has to be greater or equal to the current height. A height field in the plan is required, as time-based upgrades are deprecated and should never be sent.

maurolacy
maurolacy previously approved these changes Oct 10, 2022
Copy link
Contributor

@maurolacy maurolacy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. Some comments on naming and docs / references.

Just checked tgrade sources and at this point there's no implementation for these governance proposals. So I guess the references below must be to the Cosmos SDK.

// reached and the software will exit.
pub name: String,
// The height at which the upgrade must be performed.
// Only used if Time is not set.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What Time? Remove this comment if not applicable.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fyi: time was deprecated and must not be set

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Obviously - I completely removed Time as it is deprecated, but forgot to get rid in doc-comments.

@@ -86,6 +85,48 @@ pub enum GovProposal {
/// all code ideas that should be removed from cache to free space
code_ids: Vec<u64>,
},
// ClientUpdateProposal is a governance proposal. If it passes, the substitute
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doc comments? Also, a url reference to the relevant Cosmos SDK / tgrade sources section would be good.

},
// UpgradeProposal is a gov Content type for initiating an IBC breaking
// upgrade.
Upgrade {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't better be called IbcUpgrade or so?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know. @alpe does it? I tried to figure it out but it is not clear to me.

// client's latest consensus state is copied over to the subject client. The proposal
// handler may fail if the subject and the substitute do not match in client and
// chain parameters (with exception to latest height, frozen height, and chain-id).
ClientUpdate {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this meant to replace IbcClientUpdate, above?

Copy link
Contributor

@maurolacy maurolacy Oct 10, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, the relevant message in ibc-go 3.1.0 has two extra string fields, title and description.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

title and description seems to be in every message and in rust implementation they are just extracted directly to ExecuteGovProposal (https://github.com/confio/poe-contracts/blob/ibc-client-update-proposal-fix/packages/bindings/src/msg.rs#L36-L37). It is not 100% clear to me.


// Plan specifies information about a planned upgrade and when it should occur.
#[derive(Serialize, Deserialize, Clone, PartialEq, Eq, PartialOrd, Ord, JsonSchema, Debug)]
pub struct UpgradePlan {
Copy link
Contributor

@maurolacy maurolacy Oct 10, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Better name it IbcUpgradePlan?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I try to keep consistency and it I feel like there is no Ibc prefix even for Ibc stuff here, but I am not sure. I would like to understand the context more and have an understanding of the naming consistency here, I admit I feel a bit lost on that. Personally I would separate all ibc-related things to its own type probably, I don't know.

@@ -101,6 +100,16 @@ pub enum ValidatorProposal {
/// The contract address to be cleared
contract: String,
},
ClientUpdate {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here too, a proper Ibc prefix would be nice.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is very important to not have this mixed with a chain upgrade.

Suggested change
ClientUpdate {
IBCClientUpdate {

IBC is an acronym and uppercase

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@alpe in CamelCase acronyms are done with capitalizing only first letter. I already had issues with tools using it this common way. Same thing as we tend to name types as TcpClient, HttpRequest and so. So if it is to be prefixed, it would be actually IbcClientUpdate.

/// The substitute client identifier for the client standing in for the subject client
substitute_client_id: String,
},
Upgrade {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And here too, a proper Ibc prefix to differentiate this update proposal from the chain upgrade one.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Upgrade {
IBCUpgrade {

Copy link
Contributor

@maurolacy maurolacy Oct 12, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the comments.

As I understand it, this message should go entirely, as it's a duplicate of the RegisterUpgrade message above. As such, it's also not related to IBC.

Then, in the GovProposal enum (bindings/src/gov.rs) , both ClientUpdate and Upgrade should go, and the current IBCClientUpdate message should be properly updated.

Copy link
Contributor

@maurolacy maurolacy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On a second look, found this:

https://github.com/confio/tgrade/blob/386fbed230e6d4e6a3ab080a1f9c12848e66192f/x/twasm/contract/incoming_msgs.go#L61-L128

The IBCClientUpdate points to a ClientUpdateProposal in ibc-go v3.1.0.

Looks like that's the one we need to target. Can anyone confirm this? @alpe.

@maurolacy
Copy link
Contributor

maurolacy commented Oct 10, 2022

Approved this in haste (already dismissed), but seems some changes are required:

  • The underlying IBC client update (ibc-go v3.1.0) message has two extra fields.
  • Not sure 3.1.0 is the right ibc-go version we need to target.
  • Seems to me the two messages here, Upgrade and ClientUpdate should be removed, and the only needed thing is to update the IbcClientUpdate message with the proper fields, targeting the proper ibc-go version (which we still need to define / agree upon).

@maurolacy maurolacy dismissed their stale review October 10, 2022 15:04

Approved in haste

@hashedone
Copy link
Collaborator Author

@maurolacy I completely agree it may be the case. I think I would like to have confirmation about it from someone who has an exact understanding of what is needed there as I didn't find proper documentation for that.

Copy link

@alpe alpe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Beside adding the IBC prefix to Upgrade and ClientUpdate it looks good.
Is the duplication in msg and gov.rs needed? It is the same data. 🤷

@@ -101,6 +100,16 @@ pub enum ValidatorProposal {
/// The contract address to be cleared
contract: String,
},
ClientUpdate {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is very important to not have this mixed with a chain upgrade.

Suggested change
ClientUpdate {
IBCClientUpdate {

IBC is an acronym and uppercase

/// The substitute client identifier for the client standing in for the subject client
substitute_client_id: String,
},
Upgrade {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Upgrade {
IBCUpgrade {

// reached and the software will exit.
pub name: String,
// The height at which the upgrade must be performed.
// Only used if Time is not set.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fyi: time was deprecated and must not be set

return Err(ContractError::EmptyUpgradeName {});
}

if height < &env.block.height {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@hashedone
Copy link
Collaborator Author

So now there is a question - the old IbcClientUpdate should be completely removed? That is my guess but I am not sure at this point.

@maurolacy
Copy link
Contributor

So now there is a question - the old IbcClientUpdate should be completely removed? That is my guess but I am not sure at this point.

Either updated or removed. See this previous comment #191 (comment) for reference.

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

Successfully merging this pull request may close these issues.

None yet

3 participants