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

Update expired light client with x/group #3326

Closed
3 tasks
womensrights opened this issue Mar 22, 2023 · 3 comments
Closed
3 tasks

Update expired light client with x/group #3326

womensrights opened this issue Mar 22, 2023 · 3 comments
Labels
02-client needs discussion Issues that need discussion before they can be worked on type: feature New features, sub-features or integrations
Milestone

Comments

@womensrights
Copy link
Contributor

Summary

If a light client is frozen or expired, currently the only method to recover the client is with a governance proposal. Consider enabling recovery of a client with the x/group module

Problem Definition

Currently you can only recover a client through governance, governance cycles can take weeks in some cases which is problematic for pending packets in the channel. Enabling client recovery through another means could reduce this wait time, although it would add in an additional trust assumption to the specified group with permission to recover the client. The group could be elected via governance.

Proposal

Enable client recovery using x/group, where the composition of the group could be determined with governance, there could also be another more preferable solution

cc @zmanian @jackzampolin


For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate contributors tagged/assigned
@jackzampolin
Copy link
Member

Maybe the right way to do this is to allow for a management address when instantiating the client and perhaps a list of functions that the management address can access. This way there could be a per client ability to different security features.

@crodriguezvega crodriguezvega added needs discussion Issues that need discussion before they can be worked on 02-client type: feature New features, sub-features or integrations labels Mar 23, 2023
@crodriguezvega crodriguezvega added this to the v8.0.0 milestone Jun 19, 2023
@crodriguezvega crodriguezvega moved this to Todo in ibc-go Jun 19, 2023
@crodriguezvega
Copy link
Contributor

crodriguezvega commented Sep 11, 2023

No work is needed for this issue. Using the newly added gov v1 MsgRecoverClient and authz it is possible to accomplish this use case. I tested locally with simd binary at commit hash f2e7b0d of feature branch feat/govv1 and I was able to recover an expired client by executing a group proposal. In a nutshell, what it is needed is:

  • A governance proposal granting authorisation (i.e. a proposal that executes MsgGrant on passing) to a group policy to execute the message to recover the client.
  • A group proposal that executes MsgExec with the message to recover the client.

I document below the steps followed in more detail.

Create a group

simd tx group create-group <group-admin-address> "" members.json

where members.json contains:

{
  "members": [
    {
      "address": "<group-member-address>",
      "weight": "1",
      "metadata": ""
    }
  ]
}

Create a group policy

simd tx group create-group-policy <group-admin-address> 1 "" policy.json

where policy.json contains:

{
  "@type": "/cosmos.group.v1.ThresholdDecisionPolicy",
  "threshold": "1",
  "windows": {
    "voting_period": "5m",
    "min_execution_period": "60s"
  }
}

Submit governance proposal with MsgGrant

simd tx gov submit-proposal proposal.json --from <signer>

where proposal.json contains:

{
  "title": "Grant client recovery to group",
  "summary": "Grant client recovery to group",
  "messages": [
    {
      "@type": "/cosmos.authz.v1beta1.MsgGrant",
      "granter": "<gov-module-address>",
      "grantee": "<group-policy-address>",
      "grant": {
        "authorization": {
          "@type": "/cosmos.authz.v1beta1.GenericAuthorization",
          "msg": "/ibc.core.client.v1.MsgRecoverClient"
        }
      }
    }
  ],
  "metadata": "AQ==",
  "deposit": "100stake"
}

Vote governance proposal

simd tx gov vote 1 yes --from <signer>

Submit proposal for MsgExec

simd tx group submit-proposal proposal_recover.json

where proposal_recover.json contains:

{
  "group_policy_address": "<group-policy-address>",
  "messages": [{
    "@type": "/cosmos.authz.v1beta1.MsgExec",
    "grantee": "<group-policy-address>",
    "msgs": [{
      "@type": "/ibc.core.client.v1.MsgRecoverClient",
      "signer": "<gov-module-address>",
      "subject_client_id": "07-tendermint-0",
      "substitute_client_id": "07-tendermint-1"
    }]
  }],
  "metadata": "",
  "proposers": ["<group-proposal-proposer-address>"]
}

Vote group proposal

simd tx group vote 1 <group-proposal-voter-address> VOTE_OPTION_YES ""

Execute proposal

simd tx group exec 1 --from <signer>

I will close the issue for now. If more sophisticated mechanisms to recover a client are needed, let's discuss that in a new issue. @womensrights @srdtrk Let me know if you consider valuable to create some kind of tutorial (that we can for now add to the wiki); I could probably put something together pretty quickly.

@github-project-automation github-project-automation bot moved this from Todo to Done in ibc-go Sep 11, 2023
@womensrights
Copy link
Contributor Author

Great, that works for me, thank you very much. In that case it would be good to keep a record of this in the wiki when you get the chance :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
02-client needs discussion Issues that need discussion before they can be worked on type: feature New features, sub-features or integrations
Projects
Status: Done 🥳
Development

No branches or pull requests

3 participants