[forkless upgrades] Spelling, verbiage and other minor tweaks

tuts/perform-a-runtime-upgrade/v2.0.0-alpha.6/code.md

@@ -20,7 +20,7 @@ If you have completed that tutorial, but your chain is no longer currently runni
 
 ## Make a Change to the Code
 
-Runtime upgrades are necessary when you want to change the code of a live chain. While it is generally advisale to complete the code as much as possible before launching the chain, changes after launch become necessary to do things like fix bugs or add features.
+Runtime upgrades are necessary when you want to change the code of a live chain. While it is generally advisable to complete the code as much as possible before launching the chain, changes after launch become necessary to do things like fix bugs or add features.
 
 ### Primary Logic Change
 
@@ -55,7 +55,7 @@ substrate-node-template
 +-- ...
 ```
 
-In this file you will see this block of code where the two extrinsics to set the value and increment the value are written.
+In this file you will see this block of code containing two extrinsics used to set and increment the value.
 
 ```rust
 decl_module! {
@@ -94,7 +94,7 @@ pub fn clear_value(origin) -> dispatch::DispatchResult {
 }
 ```
 
-Confirm that your changes are correct so far by running `cargo check -p pallet-template`. If this command completes successfully, you're ready to move on. If not, stop and solve your errors or ask for help before continuing.
+Confirm that your changes are correct so far by running `cargo check -p pallet-template`. If this command completes successfully, you're ready to move on. If not, stop and fix your errors or ask for help before continuing.
 
 ### Bumping the Spec Version
 
@@ -105,7 +105,7 @@ We've already made all of the logic changes we intend to make to our code, and o
 Open the file
 `runtime/src/lib.rs`
 
-```
+```text
 substrate-node-template
 |
 +-- runtime

tuts/perform-a-runtime-upgrade/v2.0.0-alpha.6/migrations.md

@@ -4,11 +4,12 @@ lang: en
 title: Storage Migrations
 ---
 
-The runtime upgrade we just performed completed successfully simply by adding our new feature and incrementing our `spec_version`. In may simple and moderately complex cases this is all that's necessary. In other cases, you may restructure the way data is stored in the blockchain as well as modifying the logic. In these cases, it is necessary to include a migration path for the existing data. In this section we'll explore data migrations.
+The runtime upgrade we just performed completed successfully simply by adding our new feature and incrementing our `spec_version`. In many simple and moderately complex cases this is all that's necessary. In other cases, you may restructure the way data is stored in the blockchain as well as modifying the logic. In these cases, it is necessary to include a migration path for the existing data. In this section we'll explore data migrations.
 
 ## Primary Code Change
 
 For this example we will rename our storage struct from `TemplateModule` to `UpgradedTemplateModule`. To begin we open the `pallets/template/src/lib.rs` file and modify the the following line
+
 ```rust
 trait Store for Module<T: Trait> as TemplateModule {
 ```
@@ -22,6 +23,7 @@ trait Store for Module<T: Trait> as UpgradedTemplateModule {
 ## Bumping the Spec Version
 
 As before, we will open the `runtime/src/lib.rs` file and change our `spec_version`. This time we change it to 3.
+
 ```rust
 /// This runtime version.
 pub const VERSION: RuntimeVersion = RuntimeVersion {
@@ -40,20 +42,20 @@ Any time you change the storage struct, the name of a storage item, or the way a
 
 As you can see from the `decl_storage!` block of our template pallet, we are only dealing with a single storage item that was, and still is called `Something`.
 
-The complete code for our migration looks like this, and can be inserted at the bottom of the `decl_module!` block, just like the dispatchable call we aded in the previous upgrade.
+The complete code for our migration looks like this, and can be inserted at the bottom of the `decl_module!` block, just like the dispatchable call we added in the previous upgrade.
 
 ```rust
 fn on_runtime_upgrade() -> frame_support::weights::Weight {
-			use frame_support::storage::migration::{get_storage_value, put_storage_value};
+		use frame_support::storage::migration::{get_storage_value, put_storage_value};
 
-			let value_to_migrate: Option<u32> = get_storage_value(b"TempalteModule", b"Something", &[]);
-			put_storage_value(b"UpgradedTemplateModule", b"Something", &[], value_to_migrate);
+		let value_to_migrate: Option<u32> = get_storage_value(b"TempalteModule", b"Something", &[]);
+		put_storage_value(b"UpgradedTemplateModule", b"Something", &[], value_to_migrate);
 
-			1_000 // In reality the weight of migration should be determined by benchmarking
-		}
+		1_000 // In reality the weight of a migration should be determined by benchmarking
+	}
 ```
 
-First, his code `use`s two helper functions from frame support that are designed specifically for storage migrations. You will always need to do this.
+First, this code `use`s two helper functions from frame support that are designed specifically for storage migrations. You will always need to do this.
 
 Next, it grabs the value out of the old storage location. Notice that we need an explicit type annotation when grabbing the old data. This will always be necessary, and if you are unsure, just check the `decl_storage!` block to learn the type. As parameters, we have supplied the _old_ storage struct name, the storage item name, and an empty array. The third parameter will be necessary when working with storage maps, but we are using a plain storage value, so we leave it blank.
 

tuts/perform-a-runtime-upgrade/v2.0.0-alpha.6/transaction.md

@@ -8,7 +8,9 @@ In this section we will perform the on-chain runtime upgrading by submitting the
 
 ## Locating the Wasm Build Artifact
 
-At the end of the last section we compiled our runtime. Substrate Runtimes are always compiles to Web Assembly (or Wasm) as well as native code so that the Wasm can be stored on the blockchain and facilitate this forkless upgrade process. Our freshly compiled runtime is stored at `./target/release/wbuild/node-template-runtime/node-template-runtime.compact.wasm`. Ensure this file exists and that it was modified recently.
+At the end of the last section we compiled our runtime. Substrate Runtimes are always compiled to both Web Assembly (or Wasm) and native code so that the Wasm can be stored on the blockchain and facilitate this forkless upgrade process. Our freshly compiled runtime is stored at `./target/release/wbuild/node-template-runtime/node-template-runtime.compact.wasm`. Ensure this file exists and that it was modified recently.
+
+> Read more about forkless upgrades and Wasm vs native runtimes in the [executor](/kb/advanced/executor) article.
 
 ## Starting the User Interface
 
@@ -20,16 +22,16 @@ On the `Settings` tab ensure that you are connected to a `Local Node` or `ws://1
 
 > Some browsers, notably Firefox, will not connect to a local node from an https website. An easy work around is to try another browser, like Chromium. Another option is to [host this interface locally](https://github.com/polkadot-js/apps#development).
 
-## Submit the Transaction
+## Submit the Extrinsic
 
-As you can imagine, in a real-world blockchain, we don't want just anyone to be able to change the runtime logic. There is a special transaction for performing these upgrades called, `system::set_code`. This special transaction cannot be called by an ordinary user, and must be called from within the blockchain itself. Substrate provides many useful pallets to provide limited access to this sensitive function as well as others like it. In a real-world blockchain you might use the Democracy or Collective pallets. Our blockchain has a very simple governance mechanism called sudo which allows a privileged user to call sensitive functions like `system::set_code`. In our case, the privileged user is the `Alice` account, so we will submit the upgrade transaction as her.
+As you can imagine, in a real-world blockchain, we don't want just anyone to be able to change the runtime logic. There is a special extrinsic for performing these upgrades called, `system::set_code`. This special transaction cannot be called by an ordinary user, and must be called from within the blockchain itself. Substrate provides many useful pallets to provide limited access to this sensitive function as well as others like it. In a real-world blockchain you might use the Democracy or Collective pallets. Our blockchain has a very simple governance mechanism called "sudo" which allows a privileged user to call sensitive functions like `system::set_code`. In our case, the privileged user is the `Alice` account, so we will submit the upgrade transaction as her.
 
 Navigate to the Sudo tab in the interface, and select `system` and `set_code` from the dropdowns. Upload the `node-template-runtime.compact.wasm` file we saw previously, and submit the transaction.
 
 TODO screenshot
 
 ## Try out the Results
 
-Once the upgrade transaction is included in a block, you should see a notification in the UI saying the a runtime upgrade has been performed, and the UI will need to be refreshed. Once you've refreshed, you can navigate to the "Extrinsics" tab, select "Template Module" from the dropdown, and see that our new extrinsic, `clear_value` is now available.
+Once the upgrade transaction is included in a block, you should see a notification in the UI saying that a runtime upgrade has been performed, and the UI will need to be refreshed. Once you've refreshed you can navigate to the "Extrinsics" tab, select "Template Module" from the dropdown, and see that our new extrinsic, `clear_value` is now available.
 
 Congratulations, you've upgraded your blockchain's runtime! Traditionally the process of upgrading a blockchain would have required a coordinated effort from all (or at least most) of the node operators in the network. But in this case, you have performed the upgrade in a single transaction without even causing a fork!