25abafc753
* sdk/rust: Move profile settings to workspace * sdk/rust: Add serde_wormhole crate The serde_wormhole crate implements the wormhole wire format as a serde data format. This will let us replace all the hand-rolled serialization with auto-generated code, which is less error-prone and easier to review. * sdk/rust: Add serde-based struct defintions Refactor the core crate to add serde-based struct definitions for the various messages used by the different wormhole smart contracts. This will also make it easier to use alternate data formats (like json) for client-side tooling. Co-authored-by: Reisen <reisen@morphism.org> * sdk/rust: Drop references to `de::Unexpected` The `de::Unexpected` enum from serde has a `Float(f64)` variant. Referencing this enum anywhere in the code will cause the compiler to emit its `fmt::Display` impl, which includes an `f64.load` instruction on wasm targets. Even if this instruction is never executed, its mere existence will cause cosmos chains to reject any cosmwasm contract that has it. Fix this by removing all references to `de::Unexpected`. * cosmwasm: Use cargo resolver version "2" Enable the new feature resolver for the entire workspace. This prevents features that are enabled only for dev builds from also being enabled in normal builds. * Move cosmwasm Dockerfile to root directory The cosmwasm contracts now also depend on the rust sdk so the docker build context needs to be set to the root directory rather than the cosmwasm/ directory. * cosmwasm: Add wormchain-accounting contract This contract implements tokenbridge accounting specifically for the wormchain environment. Fixes #1880. * cosmwasm/accounting: Drop references to `de::Unexpected` The `de::Unexpected` enum from serde has a `Float(f64)` variant. Referencing this enum anywhere in the code will cause the compiler to emit its `fmt::Display` impl, which includes an `f64.load` instruction on wasm targets. Even if this instruction is never executed, its mere existence will cause cosmos chains to reject any cosmwasm contracts that contain it. Fix this by removing references to `de::Unexpected`. Co-authored-by: Reisen <reisen@morphism.org> |
||
|---|---|---|
| .. | ||
| artifacts | ||
| contracts | ||
| devnet | ||
| packages | ||
| test | ||
| tools | ||
| .dockerignore | ||
| .gitignore | ||
| Cargo.lock | ||
| Cargo.toml | ||
| Makefile | ||
| README.md | ||
| rustfmt.toml | ||
| verify | ||
README.md
Terra Wormhole Contract Deployment
This readme describes the steps for building, verifying, and deploying Terra smart contracts for Wormhole.
WARNING: This process is only Linux host compatible at this time.
Verify Tilt
Before building Terra contracts, ensure that the specific commit you will be building from passes in tilt. This that ensures basic functionality of the Terra smart contracts that you are about to build and deploy.
Build Contracts
The following command can be used to build Terra contracts via Docker.
Build Target Options: [mainnet|testnet|devnet|
These network names correspond to the naming convention used by wormhole
elsewhere. This means that mainnet corresponds to Terra mainnet,
testnet corresponds to Terra testnet, and devnet is localterra.
wormhole/terra $ make artifacts
Upon completion, the compiled bytecode for the Terra contracts will be placed
into the artifacts directory.
Verify Checksums
Now that you have built the Terra contracts, you should ask a peer to build using the same process and compare the equivalent checksums.txt files to make sure the contract bytecode(s) are deterministic.
wormhole/terra $ cat artifacts/checksums.txt
Once you have verified the Terra contracts are deterministic with a peer, you can now move to the deploy step.
Run tests
Disclaimer: Currently the only test that exists is for the token bridge's transfer.
You can run the integration test suite on the artifacts you built.
wormhole/terra $ make test
This command deploys your artifacts and performs various interactions with your contracts in a LocalTerra node. Any new functionality (including expected errors) to the contracts should be added to this test suite.
Deploy Contracts
Now that you have built and verified checksums, you can now deploy one or more relevant contracts to the Terra blockchain.
Deploy Target Options: [mainnet|testnet|devnet]
You will need to define a payer-DEPLOY_TARGET.json for the relevant deploy
target (eg. payer-testnet.json). This will contain the relevant wallet
private key that you will be using to deploy the contracts.
wormhole/terra $ make deploy/bridge
wormhole/terra $ make deploy/token_bridge
wormhole/terra $ make deploy/nft_bridge
For each deployed contract, you will get a code id for that relevant contract for the deployment, make note of these so you can use them in the next step for on-chain verification.
Verify On-Chain
Now that you have deployed one or more contracts on-chain, you can verify the onchain bytecode and make sure it matches the same checksums you identified above.
For each contract you wish to verify on-chain, you will need the following elements:
- Path to the contracts bytecode (eg.
artifacts-testnet/token_bridge.wasm) - Terra code id for the relevant contract (eg.
59614) - A network to verify on (
mainnet,testnet, ordevnet)
Below is how to verify all three contracts:
wormhole/terra $ ./verify artifacts/wormhole.wasm NEW_BRIDGE_CODE_ID
wormhole/terra $ ./verify artifacts/token_bridge.wasm NEW_TOKEN_BRIDGE_CODE_ID
wormhole/terra $ ./verify artifacts/nft_bridge.wasm NEW_NFT_BRIDGE_CODE_ID
Example: ./verify artifacts/token_bridge.wasm 59614
For each contract, you should expect a Successfully verified output message.
If all contracts can be successfully verified, you can engage in Wormhole
protocol governance to obtain an authorized VAA for the contract upgrade(s).
A verification failure should never happen, and is a sign of some error in the deployment process. Do not proceed with governance until you can verify the on-chain bytecode with the locally compiled bytecode.
Governance
Mainnet
Upgrades on mainnet have to go through governance. Once the code is deployed in the previous step, an unsigned governance VAA can be generated
./generate_governance -m token_bridge -c 59614 > token-bridge-upgrade-59614.prototxt
This will write to the token-bridge-upgrade-59614.prototxt file, which can
now be shared with the guardians to vote on.
Once the guardians have reached quorum, the VAA may be submitted from any funded wallet: TODO - make this easier and more unified
node main.js terra execute_governance_vaa <signed VAA (hex)> --rpc "https://lcd.terra.dev" --chain_id "columbus-5" --mnemonic "..." --token_bridge "terra10nmmwe8r3g99a9newtqa7a75xfgs2e8z87r2sf"
Testnet
For the contracts on testnet, the deployer wallet retains the upgrade authority, so these don't have to go through governance.
For example, to migrate the token bridge to 59614, run in tools/:
node migrate_testnet.js --code_id 59614 --contract terra1pseddrv0yfsn76u4zxrjmtf45kdlmalswdv39a --mnemonic "..."