docs: quit the spelling spam typo fix PRs with cspell magic (#3845)
* Add cspell configuration and custom dictionary
The goal is to cut down on both incoming tyops, and well meaning but
spammy tyop fix PRs.
To run cspell locally install it and run:
cspell '**/*.md' \
--config cspell.config.yaml \
--words-only \
--unique \
--quiet | sort --ignore-case
* docs: cspell updates
* wormchain: cspell updates
* aptos: cspell updates
* node: cspell updates
* algorand: cspell updates
* whitepapers: cspell updates
* near: cspell updates
* solana: cspell updates
* terra: cspell updates
* cosmwasm: cspell updates
* ethereum: cspell updates
* clients: cspell updates
* cspell updates for DEVELOP document
* github: run cspell github action
* sdk: cspell updates
* github: only run cspell on markdown files
* algorand: EMMITTER --> EMITTER
Suggested-by: @evan-gray
* cspell: removed from dictionary
Suggested-by: @evan-gray
* aptos and node: cspell updates
Suggested-by: @evan-gray
* cosmowasm: doc updates for terra2
Suggested-by: @evan-gray
* algorand: cspell updates
Suggested-by: @evan-gray
* algorand: cspell updates
Suggested-by: @evan-gray
* cspell: updated custom word dictionary
This resorts the dictionary and adds a few new words from the
algorand/MEMORY.md document around varints and integers.
* cspell: sort the dictionary how vscode does it
On macOS the sorting is locale dependent. To do this on macOS, you have
to invert the case, do a character insensitive sort, and then invert the
case again:
LC_COLLATE="en_US.UTF-8" cspell '**/*.md' --config cspell.config.yaml \
--words-only \
--unique \
--no-progress \
--quiet \
| tr 'a-zA-Z' 'A-Za-z' \
| sort --ignore-case \
| tr 'a-zA-Z' 'A-Za-z'
This requires the `LC_COLLATE` variable to be set to `en_US.UTF-8`, or it
will not do the right thing.
* docs: grammar clean up
---------
Co-authored-by: Evan Gray <battledingo@gmail.com>
This commit is contained in:
Jeff Schroeder
GitHub
parent
21eea8c2ed
commit
b175dd43c8
|
|
@ -308,6 +308,19 @@ jobs:
|
|||
docker build --target go-export -f Dockerfile.proto -o type=local,dest=node .
|
||||
git diff --name-only --exit-code && echo "✅ Generated proto matches committed proto" || (echo "❌ Generated proto differs from committed proto, run \`rm -rf node/pkg/proto && docker build --target go-export -f Dockerfile.proto -o type=local,dest=node .\` and commit the result" >&2 && exit 1)
|
||||
|
||||
spellcheck:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
# Pinned version of the v6 tag, which is a lightweight and hence mutable tag
|
||||
- uses: streetsidesoftware/cspell-action@214db1e3138f326d33b7a6a51c92852e89ab0618
|
||||
with:
|
||||
# For now, only lint markdown files
|
||||
files: '**/*.md'
|
||||
inline: warning
|
||||
# Only check files in the PR or push
|
||||
incremental_files_only: true
|
||||
|
||||
# Run Go tests
|
||||
node-tests:
|
||||
# The tests are slow enough that we want to run it on the self-hosted runner
|
||||
|
|
|
|||
|
|
@ -140,10 +140,12 @@ To re-generate these files run `rm -rf node/pkg/proto && docker build --target g
|
|||
|
||||
### Call gRPC services
|
||||
|
||||
<!-- cspell:disable-next-line -->
|
||||
tools/bin/grpcurl -protoset <(tools/bin/buf build -o -) -plaintext localhost:7072 spy.v1.SpyRPCService/SubscribeSignedVAA
|
||||
|
||||
With parameters (using proto json encoding):
|
||||
|
||||
<!-- cspell:disable-next-line -->
|
||||
tools/bin/grpcurl -protoset <(tools/bin/buf build -o -) \
|
||||
-d '{"filters": [{"emitter_filter": {"emitter_address": "574108aed69daf7e625a361864b1f74d13702f2ca56de9660e566d1d8691848d", "chain_id": "CHAIN_ID_SOLANA"}}]}' \
|
||||
-plaintext localhost:7072 spy.v1.SpyRPCService/SubscribeSignedVAA
|
||||
|
|
@ -152,10 +154,12 @@ With parameters (using proto json encoding):
|
|||
|
||||
To Solana:
|
||||
|
||||
<!-- cspell:disable-next-line -->
|
||||
kubectl exec solana-devnet-0 -c setup -- client post-message Bridge1p5gheXUvJ6jGWGeCsgPKgnE3YgdGKRVCMY9o 1 confirmed ffff
|
||||
|
||||
To Solana as CPI instruction:
|
||||
|
||||
<!-- cspell:disable-next-line -->
|
||||
kubectl exec solana-devnet-0 -c setup -- client post-message --proxy CP1co2QMMoDPbsmV7PGcUTLFwyhgCgTXt25gLQ5LewE1 Bridge1p5gheXUvJ6jGWGeCsgPKgnE3YgdGKRVCMY9o 1 confirmed ffff
|
||||
|
||||
### Observation Requests
|
||||
|
|
|
|||
|
|
@ -100,7 +100,7 @@ It's important to remember this is an iterative process and to stay positive. If
|
|||
|
||||
## Chain Integrators
|
||||
|
||||
As the list of chains connected to Wormhole increases, so does the risk that a given connected could introduce risks to the Wormhole network. As a result, Wormhole does have built-in safety features (e.g.: [Governor white-paper](https://github.com/wormhole-foundation/wormhole/blob/main/whitepapers/0007_governor.md)) to reduce the "blast radius" of such case. That said, a defense in depth strategy is required to do as much as possible to secure the network. As part of this methodology, the Wormhole project recommends that all connected chains current and future implement robust security programs of their own to do their part in managing chain compromise risk to the wormhole network.
|
||||
As the list of chains connected to Wormhole increases, so does the risk that a given connection could introduce risks to the Wormhole network. As a result, Wormhole does have built-in safety features (e.g.: [Governor white-paper](https://github.com/wormhole-foundation/wormhole/blob/main/whitepapers/0007_governor.md)) to reduce the "blast radius" of such case. That said, a defense in depth strategy is required to do as much as possible to secure the network. As part of this methodology, the Wormhole project recommends that all connected chains current and future implement robust security programs of their own to do their part in managing chain compromise risk to the Wormhole network.
|
||||
|
||||
Here are a few ways in which connected chains can maintain high security standards:
|
||||
|
||||
|
|
|
|||
|
|
@ -41,6 +41,7 @@ if __name__ == '__main__':
|
|||
|
||||
If we run this program, it will generate a file called `sig.tmpl.teal` based on whatever `get_sig_tmpl()` returns from the `TmplSig` class. The first few lines of `sig.tmpl.teal` look like this:
|
||||
|
||||
<!-- cspell:disable -->
|
||||
```
|
||||
#pragma version 6
|
||||
intcblock 1
|
||||
|
|
@ -79,6 +80,7 @@ assert
|
|||
intc_0 // 1
|
||||
return
|
||||
```
|
||||
<!-- cspell:enable -->
|
||||
|
||||
We’ll examine this file more carefully soon. For now, the key takeaway is that it contains TEAL bytecode, which is a stack-based programming language. What’s curious is that right at the beginning, we push `TMPL_ADDR_IDX` and `TMPL_EMITTER_ID`, only to immediately pop them from the stack, which seems redundant. Indeed, as we will see, these four lines of code are here just for the sake of being here, and we don’t actually expect them to do anything useful. This will make more sense soon.
|
||||
|
||||
|
|
@ -115,7 +117,7 @@ Here are the two pop statements we looked at in the TEAL code. The pyTEAL compil
|
|||
|
||||
`Tmpl.Int("TMPL_ADDR_IDX")` and `Tmpl.Bytes("TMPL_EMITTER_ID")` are _template variables_. Normally, they can be thought of as variables in a TEAL program that get replaced at compile time by the compiler, sort of like CPP macros. In fact, this already hints at how the LogicSig is going to be used: these variables will be programmatically replaced (albeit not just at compile time, but more on that later) with distinct values to generate distinct LogicSigs, with deterministic addresses. The wormhole contract will then be able to use the memory of the associated accounts of these LogicSigs. To see how, we’ll first go through what the LogicSig does in the first place.
|
||||
|
||||
When using a LogicSig to sign a transaction (like in our case), the LogicSig program can query information about the transaction from the Algorand runtime. If the LogicSig doesn't revert, then the transaction will be executed on-chain. It is the LogicSig’s responsibility to decide whether it wants to approve this transaction, so it will perform a number of checks to ensure the transaction does what’s expected. Importantly, anyone can pass in their own transactions and use the LogicSig to sign it, so forgetting a check here could result in hijacking the LogicSig’s associated account. That's because (by default), transactions that are signed (that is, approved) by the LogicSig can acces the LogicSig’s account. In fact, that's what LogicSigs were designed for in the first place: to implement arbitrary logic for deciding who can spend money out of some account.
|
||||
When using a LogicSig to sign a transaction (like in our case), the LogicSig program can query information about the transaction from the Algorand runtime. If the LogicSig doesn't revert, then the transaction will be executed on-chain. It is the LogicSig’s responsibility to decide whether it wants to approve this transaction, so it will perform a number of checks to ensure the transaction does what’s expected. Importantly, anyone can pass in their own transactions and use the LogicSig to sign it, so forgetting a check here could result in hijacking the LogicSig’s associated account. That's because (by default), transactions that are signed (that is, approved) by the LogicSig can access the LogicSig’s account. In fact, that's what LogicSigs were designed for in the first place: to implement arbitrary logic for deciding who can spend money out of some account.
|
||||
|
||||
The first instruction after the two `Pop`s above is
|
||||
|
||||
|
|
@ -128,14 +130,16 @@ The first instruction after the two `Pop`s above is
|
|||
Which asserts that the transaction being signed is an application call.
|
||||
Note that `==` here is an overloaded operator, and it doesn’t compare two python values. Instead, it generates a piece of pyTEAL abstract syntax that represents an equality operation. In TEAL’s concrete syntax, this looks like:
|
||||
|
||||
<!-- cspell:disable -->
|
||||
```
|
||||
txn TypeEnum
|
||||
pushint 6 // appl
|
||||
==
|
||||
assert
|
||||
```
|
||||
<!-- cspell:enable -->
|
||||
|
||||
The `txn` opcode pushes a transaction field variable to the stack, in this case its type, which is made avaiable by the AVM runtime.
|
||||
The `txn` opcode pushes a transaction field variable to the stack, in this case its type, which is made available by the AVM runtime.
|
||||
`pushint` pushes an integer to the stack, here the number 6, which corresponds to application call. `==` pops the top two elements from the stack and pushes 1 if they are equal, or 0 if they are not. Finally, `assert` pops the top of the stack, and reverts the transaction if it’s 0 (or if the stack is empty).
|
||||
|
||||
Application calls are one of the built-in transaction types defined by Algorand, another one is Payment. We require that this one is an application call, because of the next check, opting in:
|
||||
|
|
@ -179,7 +183,7 @@ Approve()
|
|||
|
||||
[/algorand/TmplSig.py#L152](https://github.com/wormhole-foundation/wormhole/blob/0af600ddde4f507b30ea043de66033d7383f53af/algorand/TmplSig.py#L152)
|
||||
|
||||
To summarize, this is how allocation works: a special program opts in to the wormhole contract, thereby allowing wormhole to write memory into the program’s account, then transfers ownership of the account to wormhole. Since the address of this account is derived from the program’s bytecode, the addresses are reconstructable deterministically, and a given account with such an address cannot have been created any other way than by executing that program with the expected arguments.
|
||||
To summarize, this is how allocation works: a special program opts in to the wormhole contract, thereby allowing wormhole to write memory into the program’s account, then transfers ownership of the account to wormhole. Since the address of this account is derived from the program’s bytecode, the addresses are reconstructible deterministically, and a given account with such an address cannot have been created any other way than by executing that program with the expected arguments.
|
||||
|
||||
<a id="orgf176818"></a>
|
||||
|
||||
|
|
@ -193,6 +197,7 @@ Instead, we turn to programmatically patching the generated binary. The LogicSig
|
|||
|
||||
The constructor of the `TmplSig` class starts by initializing the following data structure:
|
||||
|
||||
<!-- cspell:disable -->
|
||||
```python
|
||||
self.map = {"name":"lsig.teal","version":6,"source":"","bytecode":"BiABAYEASIAASDEQgQYSRDEZIhJEMRiBABJEMSCAABJEMQGBABJEMQkyAxJEMRUyAxJEIg==",
|
||||
"template_labels":{
|
||||
|
|
@ -203,6 +208,7 @@ The constructor of the `TmplSig` class starts by initializing the following data
|
|||
},
|
||||
}
|
||||
```
|
||||
<!-- cspell:enable -->
|
||||
|
||||
[/algorand/TmplSig.py#L39-L47](https://github.com/wormhole-foundation/wormhole/blob/0af600ddde4f507b30ea043de66033d7383f53af/algorand/TmplSig.py#L39-L47)
|
||||
|
||||
|
|
@ -217,6 +223,7 @@ To see what the layout looks like, let’s decode the first few bytes of the byt
|
|||
|
||||
and the first few lines of the TEAL code as a reminder:
|
||||
|
||||
<!-- cspell:disable -->
|
||||
```
|
||||
#pragma version 6
|
||||
intcblock 1
|
||||
|
|
@ -225,6 +232,7 @@ pop
|
|||
pushbytes TMPL_EMITTER_ID // TMPL_EMITTER_ID
|
||||
pop
|
||||
```
|
||||
<!-- cspell:enable -->
|
||||
|
||||
The first byte (`0x06`) is the version identifier. This matches `#pragma version 6` in the TEAL file. `0x20` is the `intcblock` instruction. It takes a byte that represents how many ints are stored (1 here) in this section, and then a list of ints (here, it’s just 1). `0x81` is the `pushint` instruction, and here we push `0x0`. This means that that this program was compiled with the template variables filled with zeros. This 0 is at offset 5 in the bytecode, which agrees with the `'position': 5'` field of the above data structure for `TMPL_ADDR_IDX`. The `0x48` opcode next is the pop instruction. Next, `0x80` is a `pushbytes` instruction, which first takes the a varint for the length of the byte array, then the byte array. Here, since the length is 0, there are no bytes following, instead `0x48` pops immediately. This byte array is at position 8, which corresponds to `TMPL_EMITTER_ID` above.
|
||||
|
||||
|
|
@ -234,6 +242,7 @@ The first byte (`0x06`) is the version identifier. This matches `#pragma version
|
|||
|
||||
The python code that constructs the bytecode is defined as
|
||||
|
||||
<!-- cspell:disable -->
|
||||
```python
|
||||
def populate(self, values: Dict[str, Union[str, int]]) -> LogicSigAccount:
|
||||
"""populate uses the map to fill in the variable of the bytecode and returns a logic sig with the populated bytecode"""
|
||||
|
|
@ -261,6 +270,7 @@ The python code that constructs the bytecode is defined as
|
|||
# Create a new LogicSigAccount given the populated bytecode,
|
||||
return LogicSigAccount(bytes(contract))
|
||||
```
|
||||
<!-- cspell:enable -->
|
||||
|
||||
[/algorand/TmplSig.py#L58-L85](https://github.com/wormhole-foundation/wormhole/blob/0af600ddde4f507b30ea043de66033d7383f53af/algorand/TmplSig.py#L58-L85)
|
||||
|
||||
|
|
@ -285,7 +295,7 @@ The on-chain program is similar to the above, but it just concatenates the byte
|
|||
tmpl_sig.get_bytecode_chunk(0),
|
||||
encode_uvarint(acct_seq_start, Bytes("")),
|
||||
|
||||
# EMMITTER_ID
|
||||
# EMITTER_ID
|
||||
tmpl_sig.get_bytecode_chunk(1),
|
||||
encode_uvarint(Len(emitter), Bytes("")),
|
||||
emitter,
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ put into dev/node.yaml
|
|||
|
||||
Install the algorand requirements
|
||||
|
||||
python3 -m pip install -r requirements.txt
|
||||
python3 -m pip install -r requirements.txt
|
||||
|
||||
install docker-compile
|
||||
|
||||
|
|
@ -42,6 +42,7 @@ bring up the dev sandbox
|
|||
./sandbox down; ./sandbox clean
|
||||
|
||||
|
||||
<!-- cspell:disable -->
|
||||
[jsiegel@gusc1a-ossdev-jsl1 ~/.../algorand/_sandbox]{master} git diff
|
||||
diff --git a/images/indexer/start.sh b/images/indexer/start.sh
|
||||
index 9e224c2..f1714ea 100755
|
||||
|
|
@ -311,3 +312,4 @@ python3 test.py
|
|||
echo "bring the sandbox down"
|
||||
cd ..
|
||||
./sandbox down
|
||||
<!-- cspell:enable -->
|
||||
|
|
|
|||
|
|
@ -198,7 +198,7 @@ def approve_token_bridge(seed_amt: int, tmpl_sig: TmplSig, devMode: bool):
|
|||
tmpl_sig.get_bytecode_chunk(0),
|
||||
encode_uvarint(acct_seq_start, Bytes("")),
|
||||
|
||||
# EMMITTER_ID
|
||||
# EMITTER_ID
|
||||
tmpl_sig.get_bytecode_chunk(1),
|
||||
encode_uvarint(Len(emitter), Bytes("")),
|
||||
emitter,
|
||||
|
|
|
|||
|
|
@ -104,7 +104,7 @@ def getCoreContracts( genTeal, approve_name, clear_name,
|
|||
tmpl_sig.get_bytecode_chunk(0),
|
||||
encode_uvarint(acct_seq_start, Bytes("")),
|
||||
|
||||
# EMMITTER_ID
|
||||
# EMITTER_ID
|
||||
tmpl_sig.get_bytecode_chunk(1),
|
||||
encode_uvarint(Len(emitter), Bytes("")),
|
||||
emitter,
|
||||
|
|
|
|||
|
|
@ -1,5 +1,6 @@
|
|||
# first build the image
|
||||
|
||||
<!-- cspell:disable-next-line -->
|
||||
(cd ..; DOCKER_BUILDKIT=1 docker buildx build --platform linux/amd64 -f aptos/Dockerfile.base -t aptos .)
|
||||
|
||||
# tag the image with the appropriate version
|
||||
|
|
|
|||
|
|
@ -215,7 +215,7 @@ simpler for users and integrators.
|
|||
|
||||
`signer` objects can also be used for access control, because the existence of a
|
||||
`signer` value with a given address proves that the address authorised that
|
||||
transaction. The key observation is that a `signer` is an unforgable token of
|
||||
transaction. The key observation is that a `signer` is an unforgeable token of
|
||||
authority, also known as a _capability_. The issue is, as described in the above
|
||||
section, is that the `signer` capability is too general, as it can authorise
|
||||
arbitrary actions on behalf of the user. For this reason, we don't use `signer`s
|
||||
|
|
@ -335,7 +335,3 @@ single entity having full control over the contracts, the contracts need to be
|
|||
their own signing authority. For details on how this is implemented, see
|
||||
[deployer.move](./deployer/sources/deployer.move) and
|
||||
[contract_upgrade.move](./wormhole/sources/contract_upgrade.move).
|
||||
|
||||
## Newtypes
|
||||
|
||||
TODO
|
||||
|
|
|
|||
|
|
@ -50,8 +50,8 @@ to identify collections (only 20 bytes of which are used on EVM chains, for the
|
|||
contract address) and another 32 bytes to identify the token within the
|
||||
collection. Neither of these fields are sufficient to pack the necessary
|
||||
information on Aptos, since the creator address itself is already 32 bytes, and
|
||||
the collection name can be an arbitary string up to 128 bytes. Token names can
|
||||
also be arbitary 128 byte strings.
|
||||
the collection name can be an arbitrary string up to 128 bytes. Token names can
|
||||
also be arbitrary 128 byte strings.
|
||||
|
||||
Thus, we store 32 byte hashes of these two fields respectively. The exact
|
||||
details of how the hashes are computed are defined in
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ This tool is a command line interface to Wormhole.
|
|||
|
||||
## Installation
|
||||
|
||||
Pull down the repo if you dont already have it and cd to the appropriate directory:
|
||||
Pull down the repo if you don't already have it and cd to the appropriate directory:
|
||||
|
||||
git clone https://github.com/wormhole-foundation/wormhole
|
||||
cd wormhole/clients/js
|
||||
|
|
@ -28,16 +28,14 @@ Commands:
|
|||
worm edit-vaa Edits or generates a VAA
|
||||
worm evm EVM utilities
|
||||
worm generate generate VAAs (devnet and testnet only)
|
||||
worm info Contract, chain, rpc and address informatio
|
||||
n utilities
|
||||
worm info Contract, chain, rpc and address information utilities
|
||||
worm near NEAR utilities
|
||||
worm parse <vaa> Parse a VAA (can be in either hex or base64
|
||||
format)
|
||||
worm recover <digest> <signature> Recover an address from a signature
|
||||
worm submit <vaa> Execute a VAA
|
||||
worm sui Sui utilities
|
||||
worm verify-vaa Verifies a VAA by querying the core contrac
|
||||
t on Ethereum
|
||||
worm verify-vaa Verifies a VAA by querying the core contract on Ethereum
|
||||
|
||||
Options:
|
||||
--help Show help [boolean]
|
||||
|
|
|
|||
|
|
@ -7,14 +7,14 @@ This readme describes the steps for building, verifying, and deploying Terra2 sm
|
|||
## 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
|
||||
building from passes in tilt. This ensures the 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 Terra2 contracts via Docker.
|
||||
|
||||
Build Target Options: [`mainnet`|`testnet`|`devnet`|
|
||||
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`,
|
||||
|
|
@ -120,9 +120,11 @@ 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
|
||||
|
||||
<!-- cspell:disable -->
|
||||
```sh
|
||||
node main.js terra execute_governance_vaa <signed VAA (hex)> --rpc "https://lcd.terra.dev" --chain_id "columbus-5" --mnemonic "..." --token_bridge "terra10nmmwe8r3g99a9newtqa7a75xfgs2e8z87r2sf"
|
||||
```
|
||||
<!-- cspell:enable -->
|
||||
|
||||
### Testnet
|
||||
|
||||
|
|
@ -131,6 +133,8 @@ authority, so these don't have to go through governance.
|
|||
|
||||
For example, to migrate the token bridge to 59614, run in `tools/`:
|
||||
|
||||
<!-- cspell:disable -->
|
||||
```sh
|
||||
node migrate_testnet.js --code_id 59614 --contract terra1pseddrv0yfsn76u4zxrjmtf45kdlmalswdv39a --mnemonic "..."
|
||||
```
|
||||
<!-- cspell:enable -->
|
||||
|
|
|
|||
|
|
@ -0,0 +1,194 @@
|
|||
acala
|
||||
Acala
|
||||
Acks
|
||||
Alertmanager
|
||||
algod
|
||||
Algorand
|
||||
algosdk
|
||||
alist
|
||||
Aptos
|
||||
authorisation
|
||||
authorise
|
||||
authorised
|
||||
backdoors
|
||||
bech
|
||||
Bech
|
||||
behaviour
|
||||
bigset
|
||||
Bigtable
|
||||
borsh
|
||||
bscscan
|
||||
BUILDKIT
|
||||
bytecodes
|
||||
callstack
|
||||
CCTP
|
||||
celestia
|
||||
Celestia
|
||||
certusone
|
||||
Chainlink
|
||||
Coinspect
|
||||
collateralization
|
||||
colour
|
||||
Concat
|
||||
conftest
|
||||
Cosm
|
||||
cosmoshub
|
||||
cosmwasm
|
||||
Cosmwasm
|
||||
counterparty
|
||||
cpus
|
||||
crosschain
|
||||
Cyfrin
|
||||
datagram
|
||||
denoms
|
||||
devnet
|
||||
dymension
|
||||
Dymension
|
||||
ethcrypto
|
||||
ethersproject
|
||||
ETHRPC
|
||||
evmos
|
||||
forgeable
|
||||
FQTs
|
||||
frontends
|
||||
funder
|
||||
gogoproto
|
||||
goimports
|
||||
gossipv
|
||||
guardiand
|
||||
GUARDIAND
|
||||
guardiand's
|
||||
Hacken
|
||||
hashdump
|
||||
hexdump
|
||||
holesky
|
||||
Holesky
|
||||
ICCO
|
||||
incentivized
|
||||
incentivizing
|
||||
initialisation
|
||||
initialised
|
||||
initialiser
|
||||
injective
|
||||
Injective
|
||||
inotify
|
||||
intcblock
|
||||
ints
|
||||
Ints
|
||||
IPFS
|
||||
journalctl
|
||||
karura
|
||||
Karura
|
||||
Keccak
|
||||
kevm
|
||||
KEVM
|
||||
keymap
|
||||
keytool
|
||||
klaytn
|
||||
Klaytn
|
||||
kompiled
|
||||
kompiles
|
||||
Kudelski
|
||||
kujira
|
||||
Kujira
|
||||
lamports
|
||||
lastrun
|
||||
libp
|
||||
localterra
|
||||
lockfiles
|
||||
merkle
|
||||
Metaplex
|
||||
mindshare
|
||||
mlock
|
||||
moby
|
||||
moonscan
|
||||
moretags
|
||||
Neodyme
|
||||
nhooyr
|
||||
obsv
|
||||
Obsv
|
||||
optimisation
|
||||
optin
|
||||
Optin
|
||||
parachain
|
||||
pdas
|
||||
permissionless
|
||||
permissionlessly
|
||||
Polkachu
|
||||
Polkadot
|
||||
Positionals
|
||||
prefunded
|
||||
promauto
|
||||
proto
|
||||
Proto
|
||||
protobuf
|
||||
protos
|
||||
prototxt
|
||||
pubkey
|
||||
pushbytes
|
||||
pushint
|
||||
pytest
|
||||
Pytest
|
||||
pythnet
|
||||
QUIC
|
||||
ramfs
|
||||
readyz
|
||||
regen
|
||||
reinit
|
||||
reobservation
|
||||
repoint
|
||||
rustup
|
||||
satoshi
|
||||
secp
|
||||
seda
|
||||
serde
|
||||
setcap
|
||||
solana
|
||||
Solana
|
||||
Solana's
|
||||
spydk
|
||||
Starport
|
||||
statesync
|
||||
struct
|
||||
structs
|
||||
subdenom
|
||||
subdenoms
|
||||
Subdenoms
|
||||
supermajority
|
||||
superminority
|
||||
tendermint
|
||||
Tendermint
|
||||
terrad
|
||||
tokenbridge
|
||||
tokenfactory
|
||||
trustlessly
|
||||
tsig
|
||||
tsproto
|
||||
TWAP
|
||||
uatom
|
||||
uluna
|
||||
unbond
|
||||
Uncompromised
|
||||
undercollateralization
|
||||
unforgeable
|
||||
unnormalize
|
||||
untampered
|
||||
utest
|
||||
uusd
|
||||
uvarint
|
||||
varint
|
||||
varints
|
||||
vimdiff
|
||||
vphash
|
||||
wasmhooks
|
||||
wasms
|
||||
WORKDIR
|
||||
wormchain
|
||||
Wormchain
|
||||
wormchaind
|
||||
Wormholescan
|
||||
wormscan
|
||||
wormscanurl
|
||||
xpla
|
||||
XPLA
|
||||
Zellic
|
||||
|
|
@ -0,0 +1,24 @@
|
|||
---
|
||||
$schema: https://raw.githubusercontent.com/streetsidesoftware/cspell/main/cspell.schema.json
|
||||
version: '0.2'
|
||||
dictionaryDefinitions:
|
||||
- name: wormhole-dictionary
|
||||
path: './cspell-custom-words.txt'
|
||||
addWords: true
|
||||
dictionaries:
|
||||
- wormhole-dictionary
|
||||
ignorePaths:
|
||||
# go modules for the guardian node
|
||||
- '/pkg/mod/**'
|
||||
- '**/node_modules/**'
|
||||
- '**/requirements.txt'
|
||||
- '/cspell-custom-words.txt'
|
||||
# tilt extensions
|
||||
- '/tilt_modules/**'
|
||||
# build artifacts
|
||||
- '/clients/js/build/**'
|
||||
- '/wormchain/build/**'
|
||||
# cosmos* and cosmwasm* autogenerated
|
||||
- '/wormchain/ts-sdk/src/modules/cosm.*/**'
|
||||
# osmosis* autogenerated
|
||||
- '/wormchain/ts-sdk/src/modules/osmosis*/**'
|
||||
|
|
@ -75,7 +75,7 @@ strongly align with the Solana ecosystem - large token holders, ecosystem projec
|
|||
would risk damage to their reputation, token values, and ecosystem growth by attacking the network or neglecting their
|
||||
duties.
|
||||
|
||||
We assume that at the present time, such incentive alignment is easy to bootstrap and get right than a separate chain,
|
||||
We assume that, at the present time, such incentive alignment is easier to bootstrap and get right than a separate chain,
|
||||
which requires carefully-designed token economy and slashing criteria. In particular, it attracts operators who care
|
||||
about the ecosystem beyond short-term validation rewards, resulting in a high-quality, resilient guardian set.
|
||||
|
||||
|
|
@ -120,7 +120,7 @@ known for its robustness - and go-ethereum, both of which have been exhaustively
|
|||
|
||||
## Safe handling of crashes in the Solana eBPF VM
|
||||
|
||||
Due to the instruction count limitations in the Solana runtime, the Solana contracts makes liberal use of unsafe blocks
|
||||
Due to the instruction count limitations in the Solana runtime, the Solana contracts make liberal use of unsafe blocks
|
||||
to serialize and deserialize data without incurring the overhead of a memory-safe approach.
|
||||
|
||||
This follows current best practices for Solana contract development. It assumes that invalid operations or out-of-bounds
|
||||
|
|
|
|||
|
|
@ -1,5 +1,6 @@
|
|||
## Addresses
|
||||
|
||||
<!-- spell-checker: disable -->
|
||||
| Label | Network | Address | Note |
|
||||
| ------------------ | :-------: | ----------------------------------------------------------------------------------------------------: | :------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| Test Wallet | ETH | 0x90F8bf6A479f320ead074411a4B0e7944Ea8c9C1 | Key: `0x4f3edf983ac636a65a842ce7c78d9aa706d3b113bce9c46f30d7d21715b23b1d` Mnemonic `myth like bonus scare over problem client lizard pioneer submit female collect` |
|
||||
|
|
@ -29,6 +30,7 @@
|
|||
| Bridge Core | Terra2 | terra14hj2tavq8fpesdwxxcu44rty3hh90vhujrvcmstl4zr3txmfvw9ssrc8au | |
|
||||
| Token Bridge | Terra2 | terra1nc5tatafv6eyq7llkr2gv50ff9e22mnf70qgjlv737ktmt4eswrquka9l6 | |
|
||||
| Governance Emitter | Universal | 0x0000000000000000000000000000000000000000000000000000000000000004 / 11111111111111111111111111111115 | Emitter Chain: 0x01 |
|
||||
<!-- spell-checker: enable -->
|
||||
|
||||
### Terra
|
||||
|
||||
|
|
@ -38,19 +40,19 @@ The terra testnet can be used just like a normal localterra network (can be sele
|
|||
|
||||
The `admin.py` deployment tool can be used to generate a set of five prefunded accounts using the `--fundDevAccounts` option, with the following addresses and mnemonics:
|
||||
|
||||
DEV7AREMQSPWWDDFFJ3A5OIMMDCZN4YT5U2MQBN76Y4J5ERQQ3MWPIHUYA 800M ALGO
|
||||
DEV7AREMQSPWWDDFFJ3A5OIMMDCZN4YT5U2MQBN76Y4J5ERQQ3MWPIHUYA 800M ALGO <!-- cspell:disable-line -->
|
||||
provide warfare better filter glory civil help jacket alpha penalty van fiber code upgrade web more curve sauce merit bike satoshi blame orphan absorb modify
|
||||
|
||||
DEVBE5BIDJV6SWV7E3XPLB5DXZG2JYCWHGXBAQH6WNBZA3G7SQQ5HUJQII
|
||||
DEVBE5BIDJV6SWV7E3XPLB5DXZG2JYCWHGXBAQH6WNBZA3G7SQQ5HUJQII <!-- cspell:disable-line -->
|
||||
album neglect very nasty input trick annual arctic spray task candy unfold letter drill glove sword flock omit dial rather session mesh slow abandon slab
|
||||
|
||||
DEV3AURNEWR5TRFXIOBP2VTCTZIS52Q3XJHNJ57M4IZLMNZ5ABQ6M7AL6E
|
||||
DEV3AURNEWR5TRFXIOBP2VTCTZIS52Q3XJHNJ57M4IZLMNZ5ABQ6M7AL6E <!-- cspell:disable-line -->
|
||||
blue spring teach silent cheap grace desk crack agree leave tray lady chair reopen midnight lottery glove congress lounge arrow fine junior mirror above purchase
|
||||
|
||||
DEVKKFRWGS4EX2GP5PLMFOXAH5TBBSWFD6G2D564FHVDXH55QSPXJKAHIU
|
||||
DEVKKFRWGS4EX2GP5PLMFOXAH5TBBSWFD6G2D564FHVDXH55QSPXJKAHIU <!-- cspell:disable-line -->
|
||||
front rifle urge write push dynamic oil vital section blast protect suffer shoulder base address teach sight trap trial august mechanic border leaf absorb attract
|
||||
|
||||
DEVKPY5JA6IJED3KBS7Z6J2ZXAUVWIJLABNAYVVLOXXIVSBH32FA2Z4BWY
|
||||
DEVKPY5JA6IJED3KBS7Z6J2ZXAUVWIJLABNAYVVLOXXIVSBH32FA2Z4BWY <!-- cspell:disable-line -->
|
||||
fat pet option agree father glue range ancient curtain pottery search raven club save crane sting gift seven butter decline image toward kidney above balance
|
||||
|
||||
### devnet guardian addresses
|
||||
|
|
|
|||
|
|
@ -52,6 +52,7 @@ Be aware that these require extra disk space!
|
|||
If you use the same RPC node for Wormhole v1, you also need the following additional parameters to speed up
|
||||
`getProgramAccount` queries:
|
||||
|
||||
<!-- cspell:disable -->
|
||||
```
|
||||
[... see above for other required parameters ...]
|
||||
|
||||
|
|
@ -59,6 +60,7 @@ If you use the same RPC node for Wormhole v1, you also need the following additi
|
|||
--account-index-include-key WormT3McKhFJ2RkiGpdw9GKvNCrB2aB54gb2uV9MfQC # for mainnet
|
||||
--account-index-include-key 5gQf5AUhAgWYgUCt9ouShm9H7dzzXUsLdssYwe5krKhg # for testnet
|
||||
```
|
||||
<!-- cspell:enable -->
|
||||
|
||||
Alternatively, if you want to run a general-purpose RPC node with indexes for all programs instead of only Wormhole,
|
||||
leave out the filtering:
|
||||
|
|
@ -69,10 +71,12 @@ leave out the filtering:
|
|||
|
||||
On mainnet, we strongly recommend blacklisting KIN and the token program to speed up catchup:
|
||||
|
||||
<!-- cspell:disable -->
|
||||
```
|
||||
--account-index-exclude-key kinXdEcpDQeHPEuQnqmUgtYykqKGVFq6CeVX5iAHJq6 # Mainnet only
|
||||
--account-index-exclude-key TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA # Mainnet only
|
||||
```
|
||||
<!-- cspell:enable -->
|
||||
|
||||
Note that these indexes require extra disk space and may slow down catchup. The first startup after
|
||||
adding these parameters will be slow since Solana needs to recreate all indexes.
|
||||
|
|
@ -261,19 +265,23 @@ The following bootstrap peers are available in each environment.
|
|||
|
||||
### Mainnet
|
||||
|
||||
<!-- cspell:disable -->
|
||||
```bash
|
||||
--bootstrap "/dns4/wormhole-v2-mainnet-bootstrap.xlabs.xyz/udp/8999/quic/p2p/12D3KooWNQ9tVrcb64tw6bNs2CaNrUGPM7yRrKvBBheQ5yCyPHKC,/dns4/wormhole.mcf.rocks/udp/8999/quic/p2p/12D3KooWDZVv7BhZ8yFLkarNdaSWaB43D6UbQwExJ8nnGAEmfHcU,/dns4/wormhole-v2-mainnet-bootstrap.staking.fund/udp/8999/quic/p2p/12D3KooWG8obDX9DNi1KUwZNu9xkGwfKqTp2GFwuuHpWZ3nQruS1"
|
||||
|
||||
--ccqP2pBootstrap "/dns4/wormhole-v2-mainnet-bootstrap.xlabs.xyz/udp/8996/quic/p2p/12D3KooWNQ9tVrcb64tw6bNs2CaNrUGPM7yRrKvBBheQ5yCyPHKC,/dns4/wormhole.mcf.rocks/udp/8996/quic/p2p/12D3KooWDZVv7BhZ8yFLkarNdaSWaB43D6UbQwExJ8nnGAEmfHcU,/dns4/wormhole-v2-mainnet-bootstrap.staking.fund/udp/8996/quic/p2p/12D3KooWG8obDX9DNi1KUwZNu9xkGwfKqTp2GFwuuHpWZ3nQruS1"
|
||||
```
|
||||
<!-- cspell:enable -->
|
||||
|
||||
### Testnet
|
||||
|
||||
<!-- cspell:disable -->
|
||||
```bash
|
||||
--bootstrap "/dns4/t-guardian-01.nodes.stable.io/udp/8999/quic/p2p/12D3KooWCW3LGUtkCVkHZmVSZHzL3C4WRKWfqAiJPz1NR7dT9Bxh,/dns4/t-guardian-02.nodes.stable.io/udp/8999/quic/p2p/12D3KooWJXA6goBCiWM8ucjzc4jVUBSqL9Rri6UpjHbkMPErz5zK,/dns4/p2p-guardian-testnet-1.solana.p2p.org/udp/8999/quic/p2p/12D3KooWE4dmZwxhfjCKHLUqSaww96Cf7kmq1ZuKmzPz3MrJgZxp"
|
||||
|
||||
--ccqP2pBootstrap "/dns4/t-guardian-01.nodes.stable.io/udp/8996/quic/p2p/12D3KooWCW3LGUtkCVkHZmVSZHzL3C4WRKWfqAiJPz1NR7dT9Bxh,/dns4/t-guardian-02.nodes.stable.io/udp/8996/quic/p2p/12D3KooWJXA6goBCiWM8ucjzc4jVUBSqL9Rri6UpjHbkMPErz5zK,/dns4/p2p-guardian-testnet-1.solana.p2p.org/udp/8996/quic/p2p/12D3KooWE4dmZwxhfjCKHLUqSaww96Cf7kmq1ZuKmzPz3MrJgZxp"
|
||||
```
|
||||
<!-- cspell:enable -->
|
||||
|
||||
## Run the Guardian Spy
|
||||
|
||||
|
|
@ -281,6 +289,7 @@ The spy connects to the wormhole guardian peer to peer network and listens for n
|
|||
|
||||
Start the spy against the testnet wormhole guardian:
|
||||
|
||||
<!-- cspell:disable -->
|
||||
```bash
|
||||
docker run \
|
||||
--platform=linux/amd64 \
|
||||
|
|
@ -289,9 +298,11 @@ docker run \
|
|||
ghcr.io/wormhole-foundation/guardiand:latest \
|
||||
spy --nodeKey /node.key --spyRPC "[::]:7073" --network /wormhole/testnet/2/1 --bootstrap "/dns4/t-guardian-01.nodes.stable.io/udp/8999/quic/p2p/12D3KooWCW3LGUtkCVkHZmVSZHzL3C4WRKWfqAiJPz1NR7dT9Bxh,/dns4/t-guardian-02.nodes.stable.io/udp/8999/quic/p2p/12D3KooWJXA6goBCiWM8ucjzc4jVUBSqL9Rri6UpjHbkMPErz5zK,/dns4/p2p-guardian-testnet-1.solana.p2p.org/udp/8999/quic/p2p/12D3KooWE4dmZwxhfjCKHLUqSaww96Cf7kmq1ZuKmzPz3MrJgZxp"
|
||||
```
|
||||
<!-- cspell:enable -->
|
||||
|
||||
To run the spy against mainnet:
|
||||
|
||||
<!-- cspell:disable -->
|
||||
```bash
|
||||
docker run \
|
||||
--platform=linux/amd64 \
|
||||
|
|
@ -300,6 +311,7 @@ docker run \
|
|||
ghcr.io/wormhole-foundation/guardiand:latest \
|
||||
spy --nodeKey /node.key --spyRPC "[::]:7073" --network /wormhole/mainnet/2 --bootstrap /dns4/wormhole-v2-mainnet-bootstrap.xlabs.xyz/udp/8999/quic/p2p/12D3KooWNQ9tVrcb64tw6bNs2CaNrUGPM7yRrKvBBheQ5yCyPHKC,/dns4/wormhole.mcf.rocks/udp/8999/quic/p2p/12D3KooWDZVv7BhZ8yFLkarNdaSWaB43D6UbQwExJ8nnGAEmfHcU,/dns4/wormhole-v2-mainnet-bootstrap.staking.fund/udp/8999/quic/p2p/12D3KooWG8obDX9DNi1KUwZNu9xkGwfKqTp2GFwuuHpWZ3nQruS1
|
||||
```
|
||||
<!-- cspell:enable -->
|
||||
|
||||
## Guardian Configurations
|
||||
|
||||
|
|
@ -313,12 +325,14 @@ Configuration files, environment variables and flags are all supported.
|
|||
|
||||
**Example**:
|
||||
|
||||
<!-- cspell:disable -->
|
||||
```yaml
|
||||
ethRPC: "ws://eth-devnet:8545"
|
||||
ethContract: "0xC89Ce4735882C9F0f0FE26686c53074E09B0D550"
|
||||
solanaRPC: "http://solana-devnet:8899"
|
||||
solanaContract: "Bridge1p5gheXUvJ6jGWGeCsgPKgnE3YgdGKRVCMY9o"
|
||||
```
|
||||
<!-- cspell:enable -->
|
||||
|
||||
### Environment Variables
|
||||
|
||||
|
|
|
|||
|
|
@ -47,9 +47,11 @@ cd cosmwasm
|
|||
node deployment/terra2/tools/deploy_single.js --network testnet --artifact artifacts/cw_token_bridge.wasm --mnemonic "<testnetDeployerSeedPhrase>"
|
||||
```
|
||||
2. The admin of the Terra2 token bridge in testnet has not been transferred to the contract itself, so you cannot use the standard contract upgrade VAA to complete the upgrade. Instead, do the following:
|
||||
<!-- cspell:disable -->
|
||||
```bash
|
||||
node deployment/terra2/tools/migrate_testnet.js --network testnet --code_id <codeIdFromDeploy> --contract terra1c02vds4uhgtrmcw7ldlg75zumdqxr8hwf7npseuf2h58jzhpgjxsgmwkvk --mnemonic "<testnetDeployerSeedPhrase>"
|
||||
```
|
||||
<!-- cspell:enable -->
|
||||
|
||||
### Resetting the Registration on XPLA
|
||||
1. Deploy the new code to XPLA by doing the following. This should give you the `code_id`.
|
||||
|
|
@ -80,4 +82,4 @@ worm submit $VAA --network testnet --chain <chainName>
|
|||
To verify that the registrations are all correct for a given chain, you can do the following. This command currently works for Solana, EVM, Terra2, XPLA, Aptos, Sui and Sei.
|
||||
```bash
|
||||
worm info registrations testnet acala TokenBridge --verify
|
||||
```
|
||||
```
|
||||
|
|
|
|||
|
|
@ -7,8 +7,8 @@ that's actually deployed. This enables the explorer to properly parse the
|
|||
transaction payloads according to the contract ABI.
|
||||
|
||||
This document outlines the process of verification. In general, you will need an
|
||||
API key for the relevant explorer (this can be obtained by creating an account),
|
||||
and also know which address the contract code lives. The API key is expected to
|
||||
API key for the relevant explorer (this can be obtained by creating an account)
|
||||
and to know at which address the contract code lives. The API key is expected to
|
||||
be set in the `ETHERSCAN_KEY` environment variable for all APIs (not just
|
||||
etherscan, bit of a misnomer).
|
||||
|
||||
|
|
|
|||
|
|
@ -36,4 +36,4 @@ ENV=tilt ts-node ./ts-scripts/relayer/deliveryProvider/upgradeDeliveryProvider.t
|
|||
|
||||
The ./shell directory contains shell scripts which combine commonly chained actions together.
|
||||
|
||||
For example, ./shell/deployConfigureTest.sh will deploy the DeliveryProvider, WormholeRelayer, and MockIntegration contracts. Configure them all to point at eachother, and then run messageTest to test that everything worked. Note: useLastRun in contracts.json needs to be set to "true" in order for this script to work.
|
||||
For example, ./shell/deployConfigureTest.sh will deploy the DeliveryProvider, WormholeRelayer, and MockIntegration contracts. Configure them all to point at each other, and then run messageTest to test that everything worked. Note: useLastRun in contracts.json needs to be set to "true" in order for this script to work.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,6 @@
|
|||
# first build the image
|
||||
|
||||
<!-- cspell:disable-next-line -->
|
||||
DOCKER_BUILDKIT=1 docker build -f Dockerfile.base -t near .
|
||||
|
||||
# tag the image with the appropriate version
|
||||
|
|
|
|||
|
|
@ -82,6 +82,7 @@ The Run function is what is called by the guardian to start this watcher. It sho
|
|||
|
||||
The following is an outline in go. Notice that each go routine is encapsulated by RunWithScissors(). What this function does is wrap the go routine to make sure that any panic or error gets reported to an error channel. Other go routines use this as a mechanism to determine degraded performance of the watcher and exit.
|
||||
|
||||
<!-- cspell:disable -->
|
||||
```go
|
||||
func (e *Watcher) Run(ctx context.Context) error {
|
||||
// Setup a logger
|
||||
|
|
@ -178,6 +179,7 @@ func (e *Watcher) Run(ctx context.Context) error {
|
|||
} // end select
|
||||
} // end Run()
|
||||
```
|
||||
<!-- cspell:enable -->
|
||||
|
||||
### Other thoughts / directions:
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ There are multiple supervised runners:
|
|||
* *BlockPoll*: Polls the NEAR RPC API for finalized blocks and generates transactionProcessingJobs for every single transaction
|
||||
* *ChunkFetcher*: Fetches chunks for each block in parallel
|
||||
* *TxProcessor*: Processes `transactionProcessingJob`, going through all receipt outcomes, searching for Wormhole messages, and checking that they have been finalized. If there are Wormhole messages in any receipts from this transaction but those receipts are not in finalized blocks, the `transactionProcessingJob` will be put in the back of the queue.
|
||||
* *ObsvReqProcessor*: Process observation requests. An observation request is a way of kindly asking the Guardian to go back in time and look at a particular transaction and try to identify wormhole events in it. Observation requests are received from other Guardians or injected through the admin API. Eventhough they are signed, they should not be trusted.
|
||||
* *ObsvReqProcessor*: Process observation requests. An observation request is a way of kindly asking the Guardian to go back in time and look at a particular transaction and try to identify wormhole events in it. Observation requests are received from other Guardians or injected through the admin API. Even though they are signed, they should not be trusted.
|
||||
|
||||
|
||||
* chunkProcessingQueue gets new chunk hashes.
|
||||
|
|
@ -52,7 +52,7 @@ There is a RPC API EXPERIMENTAL_changes_in_block which would tell you if the blo
|
|||
* tx_hash: Transaction hash
|
||||
* error_type (enum)
|
||||
* invalid_hash: Program encountered a hash that is not well-formed, i.e. not 32 bytes long.
|
||||
* nearapi_inconsistent: NEAR RPC returned data that doesn't make sense.
|
||||
* nearapi_inconsistent: NEAR RPC returned data that doesn't make sense.<!-- cspell:disable-line -->
|
||||
* malformed_wormhole_event: The wormhole log emission is malformed. This should never happen. If it does, that'd be indicative of a big problem.
|
||||
* startup_fail: Something went wrong during watcher startup.
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ wormhole.
|
|||
# Directory Structure
|
||||
|
||||
* [sdk/](./): Go SDK. This package must live in this directory so that clients can use the
|
||||
`gitub.com/wormhole-foundation/wormhole/sdk` import path.
|
||||
`github.com/wormhole-foundation/wormhole/sdk` import path.
|
||||
* [vaa/](./vaa/): Go package for using VAAs (Verifiable Action Approval).
|
||||
* [js/](./js/README.md): Javascript SDK.
|
||||
* [js-proto-node/](./js-proto-node/README.md): NodeJS client protobuf.
|
||||
|
|
|
|||
|
|
@ -6,14 +6,14 @@ This readme describes the steps for building, verifying, and deploying Solana sm
|
|||
|
||||
## Verify Tilt
|
||||
|
||||
Before building Solana contracts, ensure that the specific commit you will be building from passes in tilt. This that ensures basic functionality of the Solana smart contracts that you are about to build and deploy.
|
||||
Before building Solana contracts, ensure that the specific commit you will be building from passes in tilt. This ensures the basic functionality of the Solana smart contracts that you are about to build and deploy.
|
||||
|
||||
|
||||
## Build Contracts
|
||||
|
||||
The following command can be used to build contracts for Solana contracts via Docker.
|
||||
|
||||
Build Target Options: [`mainnet`|`testnet`|`devnet`|
|
||||
Build Target Options: [`mainnet`|`testnet`|`devnet`]
|
||||
|
||||
These network names correspond to the naming convention used by wormhole
|
||||
elsewhere. This means that `mainnet` corresponds to Solana `mainnet-beta`,
|
||||
|
|
@ -77,22 +77,27 @@ Now that you have deployed one or more contracts on-chain, you can verify the on
|
|||
For each contract you wish to verify on-chain, you will need the following elements:
|
||||
|
||||
- Path to the contracts bytecode (eg. `artifacts-testnet/bridge.so`)
|
||||
<!-- cspell:disable-next-line -->
|
||||
- Solana account address for the relevant contract (eg. `9GRbmSbdrWGNf9z27YrhPbWnL7zZ3doeQAq2LrkmCB4Y`)
|
||||
- A network to verify on (`mainnet`, `testnet`, or `devnet`)
|
||||
|
||||
Below is how to verify all three contracts on testnet:
|
||||
|
||||
<!-- cspell:disable -->
|
||||
```console
|
||||
wormhole/solana $ verify -n testnet artifacts-testnet/bridge.so NEW_BRIDGE_ACCOUNT_ADDRESS
|
||||
wormhole/solana $ verify -n testnet artifacts-testnet/token_bridge.so NEW_TOKEN_BRIDGE_ACCOUNT_ADDRESS
|
||||
wormhole/solana $ verify -n testnet artifacts-testnet/nft_bridge.so NEW_NFT_BRIDGE_ACCOUNT_ADDRESS
|
||||
```
|
||||
Example: `verify -n testnet artifacts-testnet/bridge.so 9GRbmSbdrWGNf9z27YrhPbWnL7zZ3doeQAq2LrkmCB4Y`
|
||||
<!-- cspell:enable -->
|
||||
|
||||
Again, if you have the NETWORK environment variable set, then the `-n` flag is optional:
|
||||
<!-- cspell:disable -->
|
||||
```console
|
||||
verify artifacts-testnet/bridge.so 9GRbmSbdrWGNf9z27YrhPbWnL7zZ3doeQAq2LrkmCB4Y
|
||||
```
|
||||
<!-- cspell:enable -->
|
||||
|
||||
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).
|
||||
|
||||
|
|
|
|||
|
|
@ -7,14 +7,14 @@ This readme describes the steps for building, verifying, and deploying Terra sma
|
|||
## 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
|
||||
building from passes in tilt. This ensures the 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`|
|
||||
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`,
|
||||
|
|
@ -141,6 +141,8 @@ authority, so these don't have to go through governance.
|
|||
|
||||
For example, to migrate the token bridge to 59614, run in `tools/`:
|
||||
|
||||
<!-- cspell:disable -->
|
||||
``` sh
|
||||
node migrate_testnet.js --code_id 59614 --contract terra1pseddrv0yfsn76u4zxrjmtf45kdlmalswdv39a --mnemonic "..."
|
||||
```
|
||||
<!-- cspell:enable -->
|
||||
|
|
|
|||
|
|
@ -80,7 +80,7 @@ Proposed bridge interface:
|
|||
|
||||
`setFees(VAA fee_payload)` - Update the fees using a `SetMessageFee` VAA
|
||||
|
||||
`transferFees(VAA transfer_payload)` - Transfer fees using a `TransderFees` VAA
|
||||
`transferFees(VAA transfer_payload)` - Transfer fees using a `TransferFees` VAA
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ Limit the impact of certain exploits by giving Guardians the option to delay Wor
|
|||
|
||||
## Background
|
||||
|
||||
A single integrity failure of the core messaging bridge can have disastrous consequences for users of token bridges built ontop of Wormhole, if no additional safety mitigations are in place. For example, on Feb 2, 2022 [a vulnerability in the Solana core smart contract was exploited](https://wormholecrypto.medium.com/wormhole-incident-report-02-02-22-ad9b8f21eec6) to maliciously mint wETH on Solana and it was subsequently bridged back to Ethereum.
|
||||
A single integrity failure of the core messaging bridge can have disastrous consequences for users of token bridges built on top of Wormhole, if no additional safety mitigations are in place. For example, on Feb 2, 2022 [a vulnerability in the Solana core smart contract was exploited](https://wormholecrypto.medium.com/wormhole-incident-report-02-02-22-ad9b8f21eec6) to maliciously mint wETH on Solana and it was subsequently bridged back to Ethereum.
|
||||
|
||||
There are multiple potential failure modes of the bridge:
|
||||
* In scope of the Wormhole security program:
|
||||
|
|
|
|||
|
|
@ -64,7 +64,7 @@ in the new guardian set are already registered.
|
|||
|
||||
At present, Guardian Set upgrade VAAs are signed by the Guardians off-chain. This can stay off-chain for as long as needed, but should eventually be moved on-chain.
|
||||
|
||||
## TODO Bootstraping the PoA Network
|
||||
## TODO Bootstrapping the PoA Network
|
||||
|
||||
At time of writing, the Guardian Network is currently at Guardian Set 2, but will possibly be at set 3 or 4 by the time of launch.
|
||||
|
||||
|
|
|
|||
|
|
@ -5,5 +5,5 @@ This folder contains config for running `wormchaind` against the devnet (Tilt) w
|
|||
### examples
|
||||
|
||||
transfer `utest` from the account used by `wormchain-0` to the account used by `wormchain-1`, to smoke-test wormchain - make sure we can connect to the RPC port, the accounts exist, and wormchain is producing blocks.
|
||||
|
||||
<!-- cspell:disable-next-line -->
|
||||
./build/wormchaind --home build tx bank send wormhole1cyyzpxplxdzkeea7kwsydadg87357qna3zg3tq wormhole1wqwywkce50mg6077huy4j9y8lt80943ks5udzr 1utest --from wormchain-0 --yes --broadcast-mode block --keyring-backend test
|
||||
|
|
|
|||
|
|
@ -2,9 +2,11 @@
|
|||
|
||||
The wormhole (core module) address is:
|
||||
|
||||
<!-- cspell:disable -->
|
||||
```
|
||||
wormhole1ap5vgur5zlgys8whugfegnn43emka567dtq0jl
|
||||
```
|
||||
<!-- cspell:enable -->
|
||||
|
||||
This is deterministically generated from the module.
|
||||
|
||||
|
|
|
|||
|
|
@ -3,8 +3,8 @@
|
|||
## Wasm Hooks
|
||||
|
||||
The wasm hook is an IBC middleware which is used to allow ICS-20 token transfers to initiate contract calls.
|
||||
This allows cross-chain contract calls, that involve token movement.
|
||||
This is useful for a variety of usecases.
|
||||
This allows cross-chain contract calls, that involve token movement.
|
||||
This is useful for a variety of use cases.
|
||||
One of primary importance is cross-chain swaps, which is an extremely powerful primitive.
|
||||
|
||||
The mechanism enabling this is a `memo` field on every ICS20 transfer packet as of [IBC v3.4.0](https://medium.com/the-interchain-foundation/moving-beyond-simple-token-transfers-d42b2b1dc29b).
|
||||
|
|
@ -31,10 +31,10 @@ type MsgExecuteContract struct {
|
|||
|
||||
So we detail where we want to get each of these fields from:
|
||||
|
||||
* Sender: We cannot trust the sender of an IBC packet, the counterparty chain has full ability to lie about it.
|
||||
* Sender: We cannot trust the sender of an IBC packet, the counterparty chain has full ability to lie about it.
|
||||
We cannot risk this sender being confused for a particular user or module address on Osmosis.
|
||||
So we replace the sender with an account to represent the sender prefixed by the channel and a wasm module prefix.
|
||||
This is done by setting the sender to `Bech32(Hash("ibc-wasm-hook-intermediary" || channelID || sender))`, where the channelId is the channel id on the local chain.
|
||||
This is done by setting the sender to `Bech32(Hash("ibc-wasm-hook-intermediary" || channelID || sender))`, where the channelId is the channel id on the local chain.
|
||||
* Contract: This field should be directly obtained from the ICS-20 packet metadata
|
||||
* Msg: This field should be directly obtained from the ICS-20 packet metadata.
|
||||
* Funds: This field is set to the amount of funds being sent over in the ICS 20 packet. One detail is that the denom in the packet is the counterparty chains representation of the denom, so we have to translate it to Osmosis' representation.
|
||||
|
|
@ -58,7 +58,7 @@ msg := MsgExecuteContract{
|
|||
So given the details above, we propagate the implied ICS20 packet data structure.
|
||||
ICS20 is JSON native, so we use JSON for the memo format.
|
||||
|
||||
```json
|
||||
```json
|
||||
{
|
||||
//... other ibc fields that we don't care about
|
||||
"data":{
|
||||
|
|
@ -94,13 +94,13 @@ We consider an ICS20 packet as directed towards wasmhooks iff all of the followi
|
|||
* `memo` has at least one key, with name `"wasm"`
|
||||
|
||||
If an ICS20 packet is not directed towards wasmhooks, wasmhooks doesn't do anything.
|
||||
If an ICS20 packet is directed towards wasmhooks, and is formated incorrectly, then wasmhooks returns an error.
|
||||
If an ICS20 packet is directed towards wasmhooks, and is formatted incorrectly, then wasmhooks returns an error.
|
||||
|
||||
### Execution flow
|
||||
|
||||
Pre wasm hooks:
|
||||
|
||||
* Ensure the incoming IBC packet is cryptogaphically valid
|
||||
* Ensure the incoming IBC packet is cryptographically valid
|
||||
* Ensure the incoming IBC packet is not timed out.
|
||||
|
||||
In Wasm hooks, pre packet execution:
|
||||
|
|
@ -118,20 +118,20 @@ In wasm hooks, post packet execution:
|
|||
## Ack callbacks
|
||||
|
||||
A contract that sends an IBC transfer, may need to listen for the ACK from that packet. To allow
|
||||
contracts to listen on the ack of specific packets, we provide Ack callbacks.
|
||||
contracts to listen on the ack of specific packets, we provide Ack callbacks.
|
||||
|
||||
### Design
|
||||
|
||||
The sender of an IBC transfer packet may specify a callback for when the ack of that packet is received in the memo
|
||||
field of the transfer packet.
|
||||
The sender of an IBC transfer packet may specify a callback for when the ack of that packet is received in the memo
|
||||
field of the transfer packet.
|
||||
|
||||
Crucially, _only_ the IBC packet sender can set the callback.
|
||||
|
||||
### Use case
|
||||
|
||||
The crosschain swaps implementation sends an IBC transfer. If the transfer were to fail, we want to allow the sender
|
||||
to be able to retrieve their funds (which would otherwise be stuck in the contract). To do this, we allow users to
|
||||
retrieve the funds after the timeout has passed, but without the ack information, we cannot guarantee that the send
|
||||
to be able to retrieve their funds (which would otherwise be stuck in the contract). To do this, we allow users to
|
||||
retrieve the funds after the timeout has passed, but without the ack information, we cannot guarantee that the send
|
||||
hasn't failed (i.e.: returned an error ack notifying that the receiving change didn't accept it)
|
||||
|
||||
### Implementation
|
||||
|
|
@ -182,4 +182,4 @@ pub enum SudoMsg {
|
|||
|
||||
# Testing strategy
|
||||
|
||||
See go tests.
|
||||
See go tests.
|
||||
|
|
|
|||
Loading…
Reference in New Issue