certusone
/
xdapp-book
mirror of https://github.com/certusone/xdapp-book.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Update overview.md 

Updated copy for style and grammar.
This commit is contained in:
Ian Traas 2022-08-01 21:05:56 -05:00 committed by GitHub
parent e9ddc6674c
commit 3d23e02359
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 10 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
src/development/overview.md
View File

@ -1,21 +1,23 @@
# Wormhole Development Overview
To get started with cross chain development, first you're going to need a local environment to test your xdapp code on. The general flow for a cross chain message goes from an application deployed to chain A, to the Wormhole contract on chain A, to the Guardian network, then submitted to chain B.
The general flow for a cross-chain message goes from an application deployed to chain A, to the Wormhole contract on chain A, to the Guardian network, then submitted to chain B.
To simulate all of these things locally, we need to be able to deploy some chains, deploy the Wormhole contracts to these chains, and then run atleast one Wormhole validator to pick up messages. Later, we might even introduce a relayer to automatically submit messages, but that's currently only supported for Mainnet Token Bridge transfers for native and stable coins. Developers currently have to use either a manual relayer method or an app sepecific relayer (but more on that in the Relayer section).
To get started and simulate this flow locally, you'll need a local environment to test your xdapp code. To test, we need to be able to deploy some chains, deploy the Wormhole contracts to these chains, and then run at least one Wormhole validator to pick up messages.
First, before we setup an xdapp project, we'll need to choose a local environment to run the Wormhole Guardian Network. We can use either Wormhole Local Validator or Tilt.
Later, we can introduce a relayer to automatically submit messages, though that's currently supported for Mainnet Token Bridge native and stable coin transfers only. Developers currently have to use either a manual relayer method or an app-sepecific relayer (more on that in the Relayer section).
- [Wormhole Local Validator](./wormhole-local-validator.md): This is the simplest, custom environment. It's BYOB (Bring your own Blockchain), where you can run your own local validator nodes and connect them to a single guardian running on docker. Initial setup can take upwards of 500 seconds, but after the image is built, bringing it up and down is usually <1 minute. It requires installing the software for the validator nodes locally on your computer or somewhere to run them.
- [Tilt](./tilt/overview.md): A full fledged Kubernetes deployment of *every* chain connected to Wormhole, along with a Guardian node. Usually takes 30 min to spin up fully, but comes with all chains running out of the box.
Before we setup an xdapp project, we'll need to choose a local environment to run the Wormhole Guardian Network. We can use either Wormhole Local Validator or Tilt.
- [Wormhole Local Validator](./wormhole-local-validator.md): This is the simplest custom environment. It's BYOB (Bring your own Blockchain), where you can run your own local validator nodes and connect them to a single Guardian running on docker. Initial setup can take upwards of 500 seconds, but after the image is built, bringing it up and down is usually <1 minute. This environment requires installing the software for the validator nodes locally on your computer or somewhere to run them.
- [Tilt](./tilt/overview.md): A full-fledged Kubernetes deployment of *every* chain connected to Wormhole, along with a Guardian node. Usually takes 30 min to spin up fully, but comes with all chains running out of the box.
### Testnet
If you want to test on the various test and devnets of existing connected chains, there's a single guardian node watching for transactions on various test networks. You can find the contracts [here](../reference/contracts.md) and the rpc node [here](../reference/rpcnodes.md).
If you want to test on the various test and devnets of existing connected chains, there's a single Guardian node watching for transactions on various test networks. You can find the contracts [here](../reference/contracts.md) and the rpc node [here](../reference/rpcnodes.md).
One thing to watch out for is that because testnet only has a single guardian running, there's a small chance that your VAAs do not get processed. This rate is *not* indiciative of performance on mainnet, where there are 19 guardians watching for transactions.
Because testnet only has a single Guardian, there's a small chance that your VAAs will not be processed. This rate is *not* indiciative of performance on mainnet, where there are 19 Guardians watching for transactions.
### Mainnet
When you're ready to deploy to mainnet, you can find the mainnet contracts [here](../reference/contracts.md) and the mainnet rpc nodes [here](../reference/rpcnodes.md).
## Next Steps
To get started, first clone the a local host environment (WLV or Tilt), then proceed to the first project, the [evm-messenger]().
To lay the foundation for your xDapp project, clone a local host environment (WLV or Tilt), then proceed to [evm-messenger]().