environment additions
This commit is contained in:
chase-45
parent
52fde8dee3
commit
caa844bec8
|
|
@ -53,6 +53,18 @@ Express what a normal development stack looks like in Wormhole
|
|||
- additional components
|
||||
- contract dependency hell
|
||||
|
||||
## Basics
|
||||
# Environment Setup
|
||||
|
||||
Cross-chain development environments are inherently more complex than
|
||||
The bare minimum Wormhole environment is just a blockchain linked up to a Guardian node. There are quite a few ways of accomplishing this, and if you're just looking to get your feet wet, you should try whichever sounds easiest.
|
||||
|
||||
However, as you get deeper into cross-chain development you'll likely find you have a growing number of components, dependencies, and teammates in the picture making your development environment more complex. Here are some of the considerations you should have in mind when choosing a development environment, to make sure it will continue to work for you in the future.
|
||||
|
||||
### What components do I need now? What components will I need in the future?
|
||||
|
||||
- You may be able to get a lot done with just an EVM chain and a Guardian. However, as your application gets more sophisticated, components like relayers, frontends, automated tests, databases, explorers, and other blockchains are likely to get added in to the environment.
|
||||
|
||||
### What are my dependencies?
|
||||
|
||||
- If your smart contracts have no dependencies, it may be possible for you to develop in a vacuum. However, if you're working on a fledgling blockchain and trying to integrate with other applications being developed on that chain, you may have no choice but to work in testnet alongside other development teams.
|
||||
|
||||
- Just because you have dependencies doesn't mean you automatically have to develop in testnet or mainnet. Often times it's relatively trivial to redeploy your dependencies in Tilt, or to use something like [Foundry](https://github.com/foundry-rs/foundry) to create a development version of an existing testnet or mainnet.
|
||||
|
|
|
|||
|
|
@ -1,69 +1,32 @@
|
|||
# Wormhole Local Validator
|
||||
|
||||
- wormhole local validator is a development build of the guardian software
|
||||
- easy to run, easy to configure. Connect it to whatever blockchain you feel like using, and use some provided scripts to deploy the necessary wormhole contracts
|
||||
- Newer, still has features being added
|
||||
# Wormhole Local Validator
|
||||
|
||||
## What is Wormhole Local Validator (WLV)?
|
||||
|
||||
[Wormhole Local Validator](https://github.com/wormhole-foundation/xdapp-book/tree/main/projects/wormhole-local-validator) is a development build of the Guardian software and designed to be the simplest custom environment - there is a single Guardian running on docker and otherwise a BYOB (Bring Your Own Blockchain) setup.
|
||||
[Wormhole Local Validator](https://github.com/wormhole-foundation/xdapp-book/tree/main/projects/wormhole-local-validator) is meant to be the simplest custom environment. It consists only of a dockerized Guardian image, and some utility tooling to aid with contract management. This allows you to set it up with any blockchain you'd like.
|
||||
|
||||
## Is WLV Right for You?
|
||||
|
||||
Here's a succinct list of the pros and cons of the environment, so you can decide if it's the right fit for you.
|
||||
|
||||
- Pros
|
||||
- Lightweight, low system resource demand
|
||||
- Good iteration times
|
||||
- Can be added into an existing blockchain development setup
|
||||
|
||||
- Lightweight, low system resource demand.
|
||||
- Fast iteration times.
|
||||
- Can be added into an existing blockchain development setup.
|
||||
|
||||
- Cons
|
||||
- You may end up reinventing the tilt/testnet environment as you add more components
|
||||
- You may end up reinventing the tilt/testnet environment as you add more components.
|
||||
|
||||
## Setting up Wormhole Local Validator
|
||||
|
||||
You will **need** Docker running in order to set up WLV. If you're developing on your computer, you should get [Docker Desktop](https://docs.docker.com/get-docker/); if you're in a headless VM, you should install [Docker Engine](https://docs.docker.com/engine/).
|
||||
You will need Docker running in order to set up WLV. If you're on desktop, [Docker Desktop](https://docs.docker.com/get-docker/) is generally the best choice, though [Docker Engine](https://docs.docker.com/engine/) works fine too.
|
||||
|
||||
To simulate the blockchains that are of interest, you are required to install the software for the validator nodes locally on your comupter or somewhere else to run them. Code to spin up EVM and Solana local validators, as well as scripts to deploy the necessary Wormhole contracts to these local instances, are provided in the repo.
|
||||
From there, you just need nodes for the blockchains you're interested in developing on. There is code to spin up EVM and Solana local validators included in the WLV project repo, as well as scripts to deploy the necessary Wormhole contracts to your local instances.
|
||||
|
||||
---
|
||||
Further information can be found in the project's [README](https://github.com/wormhole-foundation/xdapp-book/blob/main/projects/wormhole-local-validator/README.md).
|
||||
|
||||
Below are instructions to set up a local EVM and Solana environment:
|
||||
## Troubleshooting
|
||||
|
||||
**EVM Chains**
|
||||
Q: Anvil isn't working
|
||||
|
||||
`npm run evm` will set up:
|
||||
- (2) EVM chains
|
||||
- Wormhole Chain ID 2 (like ETH)
|
||||
- Wormhole Chain ID 4 (like BSC)
|
||||
- (3) Wormhole contracts
|
||||
- Core Bridge at `0xC89Ce4735882C9F0f0FE26686c53074E09B0D550`
|
||||
- Token Bridge at `0x0290FB167208Af455bB137780163b7B7a9a10C16`
|
||||
- NFT Bridge at `0x26b4afb60d6c903165150c6f0aa14f8016be4aec`
|
||||
- (3) utility contracts
|
||||
- Test Token (TKN) at `0x2D8BE6BF0baA74e0A907016679CaE9190e80dD0A`
|
||||
- test NFT at `0x5b9b42d6e4B2e4Bf8d42Eba32D46918e10899B66`
|
||||
- WETH Contract at `0xDDb64fE46a91D46ee29420539FC25FD07c5FEa3E`
|
||||
|
||||
These contracts will use the standard Wormhole test mnemoic (`myth like bonus scare over problem client lizard pioneer submit female collect`) and use the first key for deployment and payment (Public Key: `0x90F8bf6A479f320ead074411a4B0e7944Ea8c9C1`, Private Key: `0x4f3edf983ac636a65a842ce7c78d9aa706d3b113bce9c46f30d7d21715b23b1d`)
|
||||
|
||||
**Solana Chains**
|
||||
|
||||
`npm run solana` will set up:
|
||||
- (1) Solana chain
|
||||
- (2) Wormhole contracts
|
||||
- Core bridge at `Bridge1p5gheXUvJ6jGWGeCsgPKgnE3YgdGKRVCMY9o`
|
||||
- Token bridge at `B6RHG3mfcckmrYN1UhmJzyS1XX3fZKbkeUcpJe9Sy3FE`
|
||||
|
||||
---
|
||||
|
||||
Once you have the dependencies for each blockchain installed and have the chains running, you can run Wormhole.
|
||||
|
||||
`npm run wormhole` will pull and run the Wormhole Guardian docker image.
|
||||
|
||||
The initial setup for Wormhole Local Validator can take upwards of 500 seconds but after the image is built, bringing it up and down usually takes less than 60 seconds.
|
||||
|
||||
## FAQ & Common Questions
|
||||
|
||||
- Q: Anvil isn't working
|
||||
- While we recommend Foundry's Forge tool for compiling and deploying code elsewhere in these docs, we do not at this time recommend using anvil for guardiand; this is because guardiand is spec'd against go-ethereum, and anvil is out of spec for how it reports block headers (non left padding to normalize length), which means go-ethereum reacts abnormally and can't read anvil headers.
|
||||
- While Foundry's 'forge' tool is the generally recommended tool for EVM contract compilation, anvil isn't currently compatible with guardiand. Anvil reports block headers in a way which is non-compliant with go-ethereum, which means the guardian node can't correctly read anvil headers.
|
||||
|
|
|
|||
Loading…
Reference in New Issue