You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In preparation for mainnet, I would like us to take a more conservative approach to module readiness. I see two pieces to address:
introduce a regend flag for enabling experimental modules which we should do in testnets and devnets (but not the final pre-mainnet testnet)
tag all new/experimental modules as experimental and only enable them when the regend experimental flag is set. This includes: group, authz, feegrant, ecocredit, data and cosmwasm, basically anything that is not already live on the hub
define "pre-flight" clear gating criteria for module readiness and only move modules out of experimental once we've checked and re-checked this checklist
I have a number of concerns about module readiness that I think we need to address and I think it's more prudent to not rush things.
I propose to prioritize making modules really production ready in the following order:
group
ecocredit
authz & feegrant
data
cosmwasm
I would propose the following draft pre-flight checklist and welcome other input:
good unit and integration test coverage for all state machine logic
internal API audit (at least 1 person)
are Msg and Query methods and types well-named and organized?
is everything well documented?
internal state machine audit (at least 2 people)
read through MsgServer code and verify correctness upon visual inspection
ensure all state machine code which could be confusing is properly commented
make sure state machine logic matches Msg method documentation
ensure that all state machine edge cases are covered with tests and that test coverage is sufficient
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
assess potential risks of any new third party dependencies and decide whether a dependency audit is needed
internal completeness audit (at least 1 person). Verify that the following are properly implemented, ideally with tests:
genesis import and export of all state
query services
CLI methods
testnet/devnet testing after above internal audits
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
The text was updated successfully, but these errors were encountered:
I would explicitly assign 2 people (or 3 even) on testnet/devnet testing after above internal audits, I personally see this step as the most important one, ideally each person with some variation:
In preparation for mainnet, I would like us to take a more conservative approach to module readiness. I see two pieces to address:
regend
flag for enabling experimental modules which we should do in testnets and devnets (but not the final pre-mainnet testnet)regend
experimental flag is set. This includes: group, authz, feegrant, ecocredit, data and cosmwasm, basically anything that is not already live on the hubI have a number of concerns about module readiness that I think we need to address and I think it's more prudent to not rush things.
I propose to prioritize making modules really production ready in the following order:
I would propose the following draft pre-flight checklist and welcome other input:
Msg
andQuery
methods and types well-named and organized?MsgServer
code and verify correctness upon visual inspectionMsg
method documentationMsg
methods have been tested especially in light of any potential threats identifiedThe text was updated successfully, but these errors were encountered: