From 2239cc170da0ea30e6d498b9eb20a79b3991bbcb Mon Sep 17 00:00:00 2001 From: Csongor Kiss Date: Mon, 23 May 2022 16:27:47 +0200 Subject: [PATCH] fix a bunch of typos --- src/development/messages/registration/overview.md | 4 ++-- src/development/messages/sending/evm.md | 8 ++++---- src/development/messages/sending/overview.md | 4 ++-- src/development/scaffold/overview.md | 4 ++-- src/development/tilt/linux.md | 6 +++--- src/development/tilt/mac.md | 6 +++--- src/development/tilt/overview.md | 8 ++++---- src/introduction/introduction.md | 4 ++-- 8 files changed, 22 insertions(+), 22 deletions(-) diff --git a/src/development/messages/registration/overview.md b/src/development/messages/registration/overview.md index aec0bcc..93ba0e5 100644 --- a/src/development/messages/registration/overview.md +++ b/src/development/messages/registration/overview.md @@ -2,6 +2,6 @@ This is not strictly required, but when writing xDapps, you want to listen for messages from *specific* apps on other chains, otherwise attacks could create fake applications that emit messages that *look* like what we expect, but have fake payloads. -To do this, we register the sending contract's addresses with the receving contracts. Because each VAA has the contract address asked the core bridge to *emit* the VAA, we call the sending contracts *emitters*. Also, the emitters you're listening too, *do not* need to be your own contracts. You might want to listen to the emits of a different xDapp, in which case you'd register it's address in your code. +To do this, we register the sending contract's addresses with the receiving contracts. Because each VAA has the contract address asked the core bridge to *emit* the VAA, we call the sending contracts *emitters*. Also, the emitters you're listening too, *do not* need to be your own contracts. You might want to listen to the emits of a different xDapp, in which case you'd register it's address in your code. -Then, when receving messages, we can check the VAA being submitted, and make sure that the VAA being submitted came from one of the contracts we were expecting and *from the chain* we were expecting. \ No newline at end of file +Then, when receiving messages, we can check the VAA being submitted, and make sure that the VAA being submitted came from one of the contracts we were expecting and *from the chain* we were expecting. diff --git a/src/development/messages/sending/evm.md b/src/development/messages/sending/evm.md index 0a1b6c6..dc0db55 100644 --- a/src/development/messages/sending/evm.md +++ b/src/development/messages/sending/evm.md @@ -27,9 +27,9 @@ import "./Structs.sol"; ``` -Now, let's create a new contract in our src/ folder `Messenger.sol`. In this contract, we also create a uint32 nonce. You can think of this nonce like a message id, it's just a number that let's the receing contract know if it's already processed a message. +Now, let's create a new contract in our src/ folder `Messenger.sol`. In this contract, we also create a uint32 nonce. You can think of this nonce like a message id, it's just a number that let's the receiving contract know if it's already processed a message. -Also we'll set the consistency level here to 1, because we're just testing and want the Gaurdians to sign this VAA as soon as they see it, but if we were deploying to production, we might want to match this level to the deploy'd chain's finality gaurantees. +Also we'll set the consistency level here to 1, because we're just testing and want the Guardians to sign this VAA as soon as they see it, but if we were deploying to production, we might want to match this level to the deployed chain's finality guarantees. ```solidity @@ -40,7 +40,7 @@ import "./Wormhole/IWormhole.sol"; contract Messenger { //This is the Tilt Devnet address constant. - //Replace this address with revelant testnet or mainnet address of the chain you're deploying too. + //Replace this address with relevant testnet or mainnet address of the chain you're deploying too. address private wormhole_core_bridge_address = address(0xC89Ce4735882C9F0f0FE26686c53074E09B0D550); IWormhole core_bridge = IWormhole(wormhole_core_bridge_address); @@ -57,4 +57,4 @@ contract Messenger { } -``` \ No newline at end of file +``` diff --git a/src/development/messages/sending/overview.md b/src/development/messages/sending/overview.md index d09cb9c..4838538 100644 --- a/src/development/messages/sending/overview.md +++ b/src/development/messages/sending/overview.md @@ -5,8 +5,8 @@ While the specific code varies chain by chain, the basic flow of sending a messa To emit a VAA requires three pieces of information: 1. Nonce (u32) - - The nonce is a random number assigned to each message. This allows the receving contract a way to make sure it doesn't double process messages. + - The nonce is a random number assigned to each message. This allows the receiving contract a way to make sure it doesn't double process messages. 2. Consistency (u8) - - This is the number of blocks for Gaurdians to wait before they sign the message. Higher consistencies mean more security against blockchain reorgs. For example, if this is set too low, and the block you're emitting from reorgs, then it's possible that even though the message was emitted and signed by the Gaurdians and processed on the receving chain, no record of it exists on the emitting chain. If you were sending tokens across, this would allow for double spend attacks. + - This is the number of blocks for Guardians to wait before they sign the message. Higher consistencies mean more security against blockchain reorgs. For example, if this is set too low, and the block you're emitting from reorgs, then it's possible that even though the message was emitted and signed by the Guardians and processed on the receiving chain, no record of it exists on the emitting chain. If you were sending tokens across, this would allow for double spend attacks. 3. Payload (bytes[]) - This is a payload of raw bytes that you want to emit. It's up to the receiving contract to know how to parse it. diff --git a/src/development/scaffold/overview.md b/src/development/scaffold/overview.md index 92c2ad3..58d7d8d 100644 --- a/src/development/scaffold/overview.md +++ b/src/development/scaffold/overview.md @@ -2,7 +2,7 @@ To help you get started with cross chain development, we've provided a template project in `projects/xdapp-starter`. All the sample projects will be made using this template, so check them out if you want to get a feel for how the various modules interact with each other. -The template uses npm workspaces to setup a main project with subdirectories for each chain you want to interact with. This allows you to initalize each subdirectory using whatever scaffolding tool you want for each individual chain, and orchestration code in a common directory. +The template uses npm workspaces to setup a main project with subdirectories for each chain you want to interact with. This allows you to initialize each subdirectory using whatever scaffolding tool you want for each individual chain, and orchestration code in a common directory. Let's break down what's in the `xdapp-starter` project: @@ -18,4 +18,4 @@ They all take in a context object that's made up of the This file parses command line args and filters calls to chain management handlers. ### xdapp.config.json -The config file contains all the information about the network rpc nodes, accounts, and other constants used to communicate with contracts deployed to the selected chains. \ No newline at end of file +The config file contains all the information about the network rpc nodes, accounts, and other constants used to communicate with contracts deployed to the selected chains. diff --git a/src/development/tilt/linux.md b/src/development/tilt/linux.md index f838e28..6f40fc4 100644 --- a/src/development/tilt/linux.md +++ b/src/development/tilt/linux.md @@ -1,7 +1,7 @@ # Linux Devnet Setup ### Experimental Setup Script -There's an experimental one command setup script that should install dependencies for you on Linux and configure everything properly. This is only reccomended if you're running headless Linux and unable to use Docker Desktop, as with Docker Desktop you don't need `minikube` and can just enable Kubernetes from Docker. +There's an experimental one command setup script that should install dependencies for you on Linux and configure everything properly. This is only recommended if you're running headless Linux and unable to use Docker Desktop, as with Docker Desktop you don't need `minikube` and can just enable Kubernetes from Docker. ```sh curl $URL | sh install_linux.sh @@ -18,7 +18,7 @@ rm -rf /usr/local/go && tar -C /usr/local -xzf go1.18.1.linux-amd64.tar.gz ``` ### 2. Install Docker -If you're using Linxu with a window manager, consider getting Docker Desktop instead of the following command. It comes with Kubernetes built in and you won't need to download `minikube`. It's reccomended to have atleast 4 CPUs and 16GB RAM dedicated to Docker. +If you're using Linux with a window manager, consider getting Docker Desktop instead of the following command. It comes with Kubernetes built in and you won't need to download `minikube`. It's recommended to have at least 4 CPUs and 16GB RAM dedicated to Docker. Also make sure that you set up docker as a NON ROOT USER! @@ -65,4 +65,4 @@ tilt up --host=0.0.0.0 -- --webHost=0.0.0.0 You can now access the Tilt UI at either your `localhost:10350` or `vm_external_ip:10350`. -If the VM's external IP doesn't work, check firewall and port settings to make sure your VM allows incoming traffic. \ No newline at end of file +If the VM's external IP doesn't work, check firewall and port settings to make sure your VM allows incoming traffic. diff --git a/src/development/tilt/mac.md b/src/development/tilt/mac.md index 25587bd..908b697 100644 --- a/src/development/tilt/mac.md +++ b/src/development/tilt/mac.md @@ -1,6 +1,6 @@ -# MacOS Setup +# macOS Setup -## Prerequistes +## Prerequisites You'll need to have `homebrew` on your system if you don't already. You can grab it with: ```sh /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" @@ -35,4 +35,4 @@ tilt up ``` You'll be able to access the Tilt UI at -`localhost:10350` \ No newline at end of file +`localhost:10350` diff --git a/src/development/tilt/overview.md b/src/development/tilt/overview.md index 6cdbc48..1c9afa9 100644 --- a/src/development/tilt/overview.md +++ b/src/development/tilt/overview.md @@ -4,7 +4,7 @@ For a quicker development cycle, specially when developing your own blockchain p Tilt is a kubernetes and docker orchestration tool that will spin up all the Wormhole supported chains in containers, alongside a Guardian node that will observe and store VAAs. -This devnet environment can be setup on your computer or in a Linux VM that has atleast 4 CPU cores and 16GB of RAM. +This devnet environment can be set up on your computer or in a Linux VM that has at least 4 CPU cores and 16GB of RAM. If you do decide to host the devnet in a remote VM, remember to pass in the host and webHost flags during the tilt up step and allow incoming traffic on your VM to be able to access the various RPC endpoints on the Pods. @@ -14,7 +14,7 @@ tilt up --host=0.0.0.0 -- --webHost=0.0.0.0 While the exact commands for each environment might differ, the basic setup process for tilt is the following: -1. Insall Go +1. Install Go 2. Install Docker Desktop (Or Docker CE) a. Install Minikube if Docker CE 3. Install Tilt @@ -26,10 +26,10 @@ While the exact commands for each environment might differ, the basic setup proc For all chains that support EVM the smart contract development environment is effectively the same. For changes in gas costs and transaction times, consider testing contract logic on devnet and then using testnet environments to get chain specific answers. ### Solana is taking forever! -Unforetunely, due to Solana's architecture, it often takes 25-40min to build the Solana pod. Consider increasing CPU cores assigned to devnet for a faster build. +Unfortunately, due to Solana's architecture, it often takes 25-40min to build the Solana pod. Consider increasing CPU cores assigned to devnet for a faster build. ### Solana program deploy doesn't work -Kubernetes doesn't currently allow port forwarding for UDP ports, which is what Solana uses for `solana program deploy`. Instead, we reccomend using [Solana Deployer](https://github.com/acheroncrypto/solana-deployer). Not only does this deploy programs over regular RPC thus bypassing UDP port requirements, it's also much faster than `solana program deploy`. +Kubernetes doesn't currently allow port forwarding for UDP ports, which is what Solana uses for `solana program deploy`. Instead, we recommend using [Solana Deployer](https://github.com/acheroncrypto/solana-deployer). Not only does this deploy programs over regular RPC thus bypassing UDP port requirements, it's also much faster than `solana program deploy`. ### Reset state for a pod If you want to quickly iterate and don't want to bring tilt down and back up, you can reset state for a pod by clicking the 🔄 button next to the pod name in Tilt UI. diff --git a/src/introduction/introduction.md b/src/introduction/introduction.md index f2569ae..ed47e78 100644 --- a/src/introduction/introduction.md +++ b/src/introduction/introduction.md @@ -2,10 +2,10 @@ Welcome to the xDapp Book and beginning your journey to be a cross-chain developer. As crypto ecosystems mature, more and more applications will need to interact with programs outside the infrastructure they are deployed on. In Web2 we see this every day, as infrastructure like Azure, GCP, and AWS is abstracted away from the everyday user and applications can freely talk to each other over HTTP. -For blockchain applications to unlock their true potential, they too must be able to talk to applications on various infrastructure using a common language. These cross chain applications (xDapps) give rise to cross chain data (xData) and cross chain assets (xAssets). With these powerful primitives, blockchain applications can deliver on thier promise of interoperability and composability. +For blockchain applications to unlock their true potential, they too must be able to talk to applications on various infrastructure using a common language. These cross chain applications (xDapps) give rise to cross chain data (xData) and cross chain assets (xAssets). With these powerful primitives, blockchain applications can deliver on their promise of interoperability and composability. Ready to step *into the wormhole*? --- -Check out the [github respoitory](https://www.github.com/certusone/xdapp-book) of these docs to find the accompaning code in the projects/ directory. +Check out the [github repository](https://www.github.com/certusone/xdapp-book) of these docs to find the accompanying code in the projects/ directory.