|
1 |
| -# Deploy |
| 1 | +# Terra Wormhole Contract Deployment |
2 | 2 |
|
3 |
| -First build the contracts |
| 3 | +This readme describes the steps for building, verifying, and deploying Terra smart contracts for Wormhole. |
4 | 4 |
|
| 5 | +**WARNING**: *This process is only Linux host compatible at this time.* |
5 | 6 |
|
6 |
| -``` sh |
7 |
| -docker build -f Dockerfile.build -o artifacts . |
| 7 | +## Verify Tilt |
| 8 | + |
| 9 | +Before building Terra contracts, ensure that the specific commit you will be |
| 10 | +building from passes in tilt. This that ensures basic functionality of the |
| 11 | +Terra smart contracts that you are about to build and deploy. |
| 12 | + |
| 13 | +## Build Contracts |
| 14 | + |
| 15 | +The following command can be used to build Terra contracts via Docker. |
| 16 | + |
| 17 | +Build Target Options: [`mainnet`|`testnet`|`devnet`| |
| 18 | + |
| 19 | +These network names correspond to the naming convention used by wormhole |
| 20 | +elsewhere. This means that `mainnet` corresponds to Terra `mainnet`, |
| 21 | +`testnet` corresponds to Terra `testnet`, and `devnet` is `localterra`. |
| 22 | + |
| 23 | +```console |
| 24 | +wormhole/terra $ make artifacts |
8 | 25 | ```
|
9 | 26 |
|
10 |
| -Then, for example, to deploy `token_bridge.wasm`, run in the `tools` directory |
| 27 | +Upon completion, the compiled bytecode for the Terra contracts will be placed |
| 28 | +into the `artifacts` directory. |
11 | 29 |
|
12 |
| -``` sh |
13 |
| -npm ci |
14 |
| -node deploy_single.js --network mainnet --artifact ../artifacts/token_bridge.wasm --mnemonic "..." |
| 30 | +## Verify Checksums |
| 31 | + |
| 32 | +Now that you have built the Terra contracts, you should ask a peer to build |
| 33 | +using the same process and compare the equivalent checksums.txt files to make |
| 34 | +sure the contract bytecode(s) are deterministic. |
| 35 | + |
| 36 | +```console |
| 37 | +wormhole/terra $ cat artifacts/checksums.txt |
15 | 38 | ```
|
16 | 39 |
|
17 |
| -which will print something along the lines of |
| 40 | +Once you have verified the Terra contracts are deterministic with a peer, you can now move to the deploy step. |
18 | 41 |
|
19 |
| -``` sh |
20 |
| -Storing WASM: ../artifacts/token_bridge.wasm (367689 bytes) |
21 |
| -Deploy fee: 88446uluna |
22 |
| -Code ID: 2435 |
| 42 | +## Deploy Contracts |
| 43 | + |
| 44 | +Now that you have built and verified checksums, you can now deploy one or more relevant contracts to the Terra blockchain. |
| 45 | + |
| 46 | +Deploy Target Options: [`mainnet`|`testnet`|`devnet`] |
| 47 | + |
| 48 | +You will need to define a `payer-DEPLOY_TARGET.json` for the relevant deploy |
| 49 | +target (eg. `payer-testnet.json`). This will contain the relevant wallet |
| 50 | +private key that you will be using to deploy the contracts. |
| 51 | + |
| 52 | +```console |
| 53 | +wormhole/terra $ make deploy/bridge |
| 54 | +wormhole/terra $ make deploy/token_bridge |
| 55 | +wormhole/terra $ make deploy/nft_bridge |
23 | 56 | ```
|
24 | 57 |
|
25 |
| -# Migrate |
| 58 | +For each deployed contract, you will get a code id for that relevant |
| 59 | +contract for the deployment, make note of these so you can use them in |
| 60 | +the next step for on-chain verification. |
| 61 | + |
| 62 | +## Verify On-Chain |
| 63 | + |
| 64 | +Now that you have deployed one or more contracts on-chain, you can verify the |
| 65 | +onchain bytecode and make sure it matches the same checksums you identified |
| 66 | +above. |
| 67 | + |
| 68 | +For each contract you wish to verify on-chain, you will need the following elements: |
| 69 | + |
| 70 | +- Path to the contracts bytecode (eg. `artifacts-testnet/token_bridge.wasm`) |
| 71 | +- Terra code id for the relevant contract (eg. `59614`) |
| 72 | +- A network to verify on (`mainnet`, `testnet`, or `devnet`) |
| 73 | + |
| 74 | +Below is how to verify all three contracts: |
| 75 | + |
| 76 | +```console |
| 77 | +wormhole/terra $ ./verify artifacts/wormhole.wasm NEW_BRIDGE_CODE_ID |
| 78 | +wormhole/terra $ ./verify artifacts/token_bridge.wasm NEW_TOKEN_BRIDGE_CODE_ID |
| 79 | +wormhole/terra $ ./verify artifacts/nft_bridge.wasm NEW_NFT_BRIDGE_CODE_ID |
| 80 | +``` |
| 81 | +Example: `./verify artifacts/token_bridge.wasm 59614` |
| 82 | + |
| 83 | +For each contract, you should expect a `Successfully verified` output message. |
| 84 | +If all contracts can be successfully verified, you can engage in Wormhole |
| 85 | +protocol governance to obtain an authorized VAA for the contract upgrade(s). |
| 86 | + |
| 87 | +A verification failure should never happen, and is a sign of some error in the |
| 88 | +deployment process. Do not proceed with governance until you can verify the |
| 89 | +on-chain bytecode with the locally compiled bytecode. |
| 90 | + |
| 91 | + |
| 92 | +## Governance |
| 93 | + |
| 94 | +### Mainnet |
| 95 | + |
| 96 | +Upgrades on mainnet have to go through governance. Once the code is deployed in |
| 97 | +the previous step, an unsigned governance VAA can be generated |
| 98 | + |
| 99 | +```sh |
| 100 | +./generate_governance -m token_bridge -c 59614 > token-bridge-upgrade-59614.prototxt |
| 101 | +``` |
26 | 102 |
|
27 |
| -## Mainnet |
| 103 | +This will write to the `token-bridge-upgrade-59614.prototxt` file, which can |
| 104 | +now be shared with the guardians to vote on. |
28 | 105 |
|
29 |
| -Migrations on mainnet have to go through governance. Once the guardians sign the |
30 |
| -upgrade VAA, the contract can be upgraded by submitting the signed VAA to the |
31 |
| -appropriate contract. For example, to upgrade the token bridge on mainnet, |
32 |
| -in `wormhole/clients/token_bridge/`: |
| 106 | +Once the guardians have reached quorum, the VAA may be submitted from any |
| 107 | +funded wallet: TODO - make this easier and more unified |
33 | 108 |
|
34 | 109 | ``` sh
|
35 | 110 | node main.js terra execute_governance_vaa <signed VAA (hex)> --rpc "https://lcd.terra.dev" --chain_id "columbus-5" --mnemonic "..." --token_bridge "terra10nmmwe8r3g99a9newtqa7a75xfgs2e8z87r2sf"
|
36 | 111 | ```
|
37 | 112 |
|
38 |
| -## Testnet |
| 113 | +### Testnet |
39 | 114 |
|
| 115 | +For the contracts on testnet, the deployer wallet retains the upgrade |
| 116 | +authority, so these don't have to go through governance. |
40 | 117 |
|
41 |
| -For example, to migrate the token bridge to 37262, run in `tools/`: |
| 118 | +For example, to migrate the token bridge to 59614, run in `tools/`: |
42 | 119 |
|
43 | 120 | ``` sh
|
44 |
| -node migrate_testnet.js --code_id 37262 --contract terra1pseddrv0yfsn76u4zxrjmtf45kdlmalswdv39a --mnemonic "..." |
| 121 | +node migrate_testnet.js --code_id 59614 --contract terra1pseddrv0yfsn76u4zxrjmtf45kdlmalswdv39a --mnemonic "..." |
45 | 122 | ```
|
0 commit comments