-
Notifications
You must be signed in to change notification settings - Fork 11
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
base: main
Are you sure you want to change the base?
Conversation
48336f5
to
0820261
Compare
There was a problem hiding this 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.
packages/bindings/src/gov.rs
Outdated
// 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
packages/bindings/src/gov.rs
Outdated
@@ -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 |
There was a problem hiding this comment.
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.
packages/bindings/src/gov.rs
Outdated
}, | ||
// UpgradeProposal is a gov Content type for initiating an IBC breaking | ||
// upgrade. | ||
Upgrade { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
packages/bindings/src/gov.rs
Outdated
// 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 { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Better name it IbcUpgradePlan
?
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
ClientUpdate { | |
IBCClientUpdate { |
IBC is an acronym and uppercase
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Upgrade { | |
IBCUpgrade { |
There was a problem hiding this comment.
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.
There was a problem hiding this 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:
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 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. |
There was a problem hiding this 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 { |
There was a problem hiding this comment.
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.
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 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Upgrade { | |
IBCUpgrade { |
packages/bindings/src/gov.rs
Outdated
// 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. |
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
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. |
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.