x/gov v1 Module Readiness Checklist

[amaury1093]

x/gov v1 Module Readiness Checklist

This checklist is to be used for tracking the final internal audit of new Cosmos SDK modules prior to inclusion in a published release.

Release Candidate Checklist

The following checklist should be gone through once the module has been fully implemented. This audit should be performed directly on master, or preferably on a alpha or beta release tag that includes the module.

The module should not be included in any Release Candidate tag until it has passed this checklist.

The main change in v0.46's gov module is the Msg-based proposal submission and execution path, so everything related to proposals MUST be audited.

Since the gov module has never been internally audited, we propose the reviewers to run through the whole Module Readiness Checklist, and check on existing APIs, logic and docs, making sure they are either left untouched or improved upon.

• API audit (at least 1 person) (@likhita-809) (tracked in chore: x/gov v1 API audit changes #11474)
  • Are Msg and Query methods and types well-named and organized?
  • Is everything well documented (inline godoc as well as /spec/ folder in module directory)
• State machine audit (at least 2 people) (@atheeshp, @likhita-809).
  • Read through MsgServer code and verify correctness upon visual inspection (@atheeshp )
  • Ensure all state machine code which could be confusing is properly commented (@likhita-809 ) (tracked in docs: x/gov state machine inline comments changes #11498)
  • Make sure state machine logic matches Msg method documentation (@atheeshp )
  • Ensure that all state machine edge cases are covered with tests and that test coverage is sufficient (at least 90% coverage on module code) (@atheeshp ) (chore: improve code cov #11502)
  • Assess potential threats for each method including spam attacks and ensure that threats have been addressed sufficiently. This should be done by writing up threat assessment for each method (@likhita-809 )
  • Assess potential risks of any new third party dependencies and decide whether a dependency audit is needed (@atheeshp )
• Completeness audit, fully implemented with tests (at least 1 person) (@blushi ) chore: x/gov v1 Completeness audit #11567
  • Genesis import and export of all state
  • Query services
  • CLI methods
  • All necessary migration scripts are present (if this is an upgrade of existing module)

Published Release Checklist

After the above checks have been audited and the module is included in a tagged Release Candidate, the following additional checklist should be undertaken for live testing, and potentially a 3rd party audit (if deemed necessary):

• Testnet / devnet testing (2-3 people) (@assignee1, @assignee2, @assignee3) Manual Testing for v0.46 #11880
  • All Msg methods have been tested especially in light of any potential threats identified
  • Genesis import and export has been tested
• Nice to have (and needed in some cases if threats could be high): Official 3rd party audit

[faddat]

cosmos/ibc-go#949

I think that this might be something that we can use to work on the migration docs, but:

1. it is very not done yet
2. Uncertain if we're taking the right path by making all of the ibc gov tx's v1beta2.

[amaury1093]

Uncertain if we're taking the right path by making all of the ibc gov tx's v1beta2.

It's definitely the right path. The reason we kept v1beta1 is for apps to have a smoother transition. Whether it should be done now in your PR, or later, is your decision.

[catShaark]

The title and description from the old v1beta1.Content should then be marshal and put into v1beta2.Proposal Metadata right ?

[amaury1093]

@catShaark Correct. Another way is to put an URL to IPFS cid in metadata which links to the title/description. See #10490 too.

[amaury1093]

Re-opening, there's still some manual testing, in the RC phase

[amaury1093]

All done!