beaker
beaker copied to clipboard
[Research] List steps to verify contract hash
Inspecting contract
First, create new contract
https://docs.osmosis.zone/developing/dapps/get_started/cosmwasm-testnet.html
Once the contract is created we can check query the contract information. Assuming you are connected to the testnet.
contract_info
osmosisd query wasm contract osmo1mpf0guu0t363xrshhedandypq003ahzaxvsxzgu69n3ej03mh2zqx5gk8l
Output:
contract version
osmosisd query wasm contract-state raw osmo1mpf0guu0t363xrshhedandypq003ahzaxvsxzgu69n3ej03mh2zqx5gk8l 636F6E74726163745F696E666F --node https://rpc-test.osmosis.zone:443 --output json | jq -r .data | base64 -d | jq
What in the world is 636F6E74726163745F696E666F
? 😕
ContractInfo is must be stored under "contract_info" key which translates to "636F6E74726163745F696E666F" in hex format. As documented here.
Output:
Downloading the Contract from the network
osmosisd query wasm code 205 205_code.wasm --node https://rpc-test.osmosis.zone:443
Output:
Getting the hash
sha256sum 205_code.wasm
Output :
0b662785042cd938d0f0e8142f69d2d23fdf0addec965d1fbeacf44080330016
Verify hash
Now it's time to verify the hash with the source repos. All contracts should provide a repository with a hash for their contracts the same way that cw-plus does on their checksum as shown below:
10bc1a8cf82055106b26136f26137d6bf132df99c2d2098a75d03b64e7fe75a5 cw1155_base.wasm
539b62678532596c73b27764186623a2bb868f5e67c3e588508c4a28e105e8c9 cw1_subkeys.wasm
b67bc69fef770c28d48730feb800ea9c91eaae1a608e3ea7819aac64a6e99d92 cw1_whitelist.wasm
704890409d0e82f33951f0f4d06e42b27082d91b5c8c98853969296191244baf cw1_whitelist_ng.wasm
db366741dcbad5f2e4933cda49133cd2a11fdb32b08c67cb1d22379bd392448e cw20_base.wasm
ac452ac5c96ac843cad0267a0f465d39f6dd43d4e47631e6deefd23a4cf77a61 cw20_ics20.wasm
b3d44429dfb1e445a7ea3c0125b71efdc85185666f35e4e62581ffc1310905bd cw3_fixed_multisig.wasm
62131b508b448dad7d7878188f55b674c24a1b705791179b87e85e0854538837 cw3_flex_multisig.wasm
163566b6f65819c2ea6cadddc847cbaaa59f5218dbbd895bcc2fcefe1afd7d0e cw4_group.wasm
0c44f17035eb51c0115d95f14e83ce2cdfbcb804ffa95e1f8203d22300d6ba90 cw4_stake.wasm
With this approach, verification is happening after the fact that it's deployed, which could be useful for reassuring but as for the part of the store-code process, should we gate the proposal by the verification? I have elaborated more about this on #59 .