Update rococo-v1 (JoshOrndorff#62)

* update commits

* add new chain spec files, "chainspec" to "chain spec"

* update "README" links to "/"

* set long-lived base-path. Warn about collator DB deletion

* purge chain info

* type metadata UI note

* fix typo

* Comment on - Took active validator from set with wrong size - prompt

* update note on error

* Updating polkadot & parachain-template commits

Co-authored-by: al3mart <[email protected]>

en/1-prep/1-compiling.md

@@ -31,7 +31,7 @@ instructions at https://substrate.dev/docs/en/knowledgebase/getting-started/
 
 <!-- > You may skip this step if you prefer to use docker to run nodes. -->
 
-Clone the Polkadot repository, and build the node. We are using a [specific commit](../README#versions-of-software) for this workshop.
+Clone the Polkadot repository, and build the node. We are using a [specific commit](/#versions-of-software) for this workshop.
 Perform these steps in your typical workspace directory.
 
 ```bash
@@ -42,7 +42,7 @@ git clone https://github.com/paritytech/polkadot.git
 cd polkadot
 
 # Checkout the proper commit
-git checkout 943038a
+git checkout 127eb17a
 
 # Build the relay chain Node
 cargo build --release
@@ -76,7 +76,7 @@ git clone  https://github.com/substrate-developer-hub/substrate-parachain-templa
 cd substrate-parachain-template
 
 # Checkout the proper commit
-git checkout 40b8581
+git checkout 1e1e725
 
 # Build the parachain template collator
 cargo build --release

en/1-prep/2-chain-spec.md

@@ -9,14 +9,14 @@ with this workshop, or create your own.
 > **For example, if you want to connect two parachains,**
 >**you need *at least* three validators in the relay chain!**
 
-Whichever spec you choose to use we will refer to it simply as `spec.json` in the instructions below.
+Whichever spec you choose to use we will refer to it simply as `chain-spec.json` in the instructions below.
 You will need to supply the proper path to the spec file you are using. **These _conventionally_ live**
 **in a `/res` folder that is published in your node's codebase for others to use**. As an example:
 
-- Polkadot includes [these **relay chain** `chainspec` files](https://github.com/paritytech/polkadot/tree/master/node/service/res)
-- Cumulus includes [these **parachain** `chainspec` files](https://github.com/paritytech/cumulus/tree/master/rococo-parachains/res)
+- Polkadot includes [these **relay chain** `chain-spec.json` files](https://github.com/paritytech/polkadot/tree/master/node/service/res)
+- Cumulus includes [these **parachain** `chain-spec.json` files](https://github.com/paritytech/cumulus/tree/master/rococo-parachains/res)
 
-> If you intend to let other connect to your network **you must** have the genesis Wasm the associated and chainspec
+> If you intend to let other connect to your network **you must** have the genesis Wasm the associated and chain spec
 > for your network on _one machine_ and have a way for all other nodes to copy this _exact file_ on starting thier nodes.
 > This stems from [non-determinism](https://dev.to/gnunicorn/hunting-down-a-non-determinism-bug-in-our-rust-wasm-build-4fk1))
 > in the way Wasm runtimes are compiled, at least for now. Thus including it in your codebase is best practice!
@@ -38,15 +38,15 @@ local test network:
   chain with Alice and Bob as authorities. Useful for registering a single parachain. 
   **This is a direct export of the `rococo-local` spec that is**
   **[included in polkadot](https://github.com/paritytech/polkadot/tree/master/node/service/res).**
-  - Plain chainspec: <a href="shared/chainspecs/rococo-custom-plain.json" download>shared/chainspecs/rococo-custom-plain.json</a> 
+  - Plain chain spec: <a href="shared/chainspecs/rococo-custom-plain.json" download>shared/chainspecs/rococo-custom-plain.json</a> 
 
 - <a href="shared/chainspecs/rococo-custom-3.json" download>shared/chainspecs/rococo-local-3.json</a>: A three-validator relay chain
   identical to `rococo-custom.json` but with Charlie as a third validator.
-  - Plain chainspec:  <a href="shared/chainspecs/rococo-custom-plain-3.json" download>shared/chainspecs/rococo-custom-plain-3.json</a>  
+  - Plain chain spec:  <a href="shared/chainspecs/rococo-custom-plain-3.json" download>shared/chainspecs/rococo-custom-plain-3.json</a>  
 
 - <a href="shared/chainspecs/rococo-custom-4.json" download>shared/chainspecs/rococo-local-4.json</a>: A four-validator relay chain
   identical to `rococo-custom.json` but with Charlie and Dave as a third and fourth validator.s
-  - Plain chainspec: <a href="shared/chainspecs/rococo-custom-plain-4.json" download>shared/chainspecs/rococo-custom-plain-4.json</a> 
+  - Plain chain spec: <a href="shared/chainspecs/rococo-custom-plain-4.json" download>shared/chainspecs/rococo-custom-plain-4.json</a> 
 
 All `*plain.json` files included are used to inspect in a more human readable and modifiable format that can also be used to derive 
 a [new custom raw spec](#adjust-the-chain-spec).
@@ -185,27 +185,30 @@ case of ECDSA keys (see [the note below](#ss58-encoding-of-key-vs-address) on wh
 
 Now that you have all the keys you need, append them in the `palletSession` section of you *plain* spec file.
 You can either create new IDs or use other well known accounts following this same process.
-You can also proceed with the **raw** `spec.json` files [mentioned above](#using-a-prebuilt-chain-spec).
+You can also proceed with the **raw** `chain-spec.json` files [mentioned above](#using-a-prebuilt-chain-spec).
 
 ---
 
 ### 2. Convert to Raw Chain Spec
 
 Now that you've created your spec, you can generate the final raw spec file.
 
+> Your final spec _must_ start with the word `rococo` or the node will not know what runtime logic
+> it includes.
+
 ```bash
 polkadot build-spec --chain rococo-custom-plain.json --raw --disable-default-bootnode > rococo-custom.json
 ```
 
-> Your final spec _must_ start with the word `rococo` or the node will not know what runtime logic
-> it includes.
+You may get the output warning: `Took active validators from set with wrong size`.
+The resulting `chain-spec.json` will still be **perfectly usable**, you can ignore this safely.
 
 ## Further Resources
 
 This custom session key addition in the plain is not needed for **production chains** - as these 
 are generated for you from your `chain-spec.rs` file more simply and concretely. This exercise above is 
 used because you _must recompile your node_ for just adding authorities in this case!
-So if all you need to do is configure minor things off of a know base chainspec, as we did, you will want
+So if all you need to do is configure minor things off of a know base chain spec, as we did, you will want
 to set the information in `chain-spec.rs`, and generate the binary and finally use the CLI to generate 
 your custom chain spec. 
 
@@ -248,4 +251,4 @@ In case of ECDSA, we blake2 the public key to get the address (due to size diffe
 
 Default Ser/De implementation for public keys is using SS58 encoding, hence every time we use 
 public keys in encoded form we are going to need it's SS58 encoding. A notable case is 
-chain spec JSON file and encoding of session keys (most importantly BEEFY).
+chain spec JSON file and encoding of session keys (most importantly BEEFY).

en/2-relay-chain/1-launch.md

@@ -9,7 +9,7 @@ spec that ships with this workshop as well as general instructions for starting
 ```bash
 polkadot \
   --chain <path to spec json> \
-  --tmp \
+  --base-path /tmp/relay-alice \
   --ws-port 9944 \
   --port 30333 \
   --alice
@@ -39,14 +39,14 @@ https://polkadot.js.org/apps/#/?rpc=ws://localhost:9944
 > At time of writing, this demo works with the hosted version of Apps linked above. If something has
 > changed in the meantime, try to
 > [host the interface locally](https://github.com/polkadot-js/apps#development) using the commit
-> that is defined [the version compatablilty](../README#versions-of-software) noted.
+> that is defined [the version compatablilty](/#versions-of-software) noted.
 
 ## Start Bob's Node
 
 ```bash
 polkadot \
   --chain <path to spec json> \
-  --tmp \
+  --base-path /tmp/relay-bob \
   --ws-port 9955 \
   --port 30334 \
   --bob \
@@ -70,7 +70,7 @@ make sure that nodes on the same physical system do not have conflicting ports o
 ```bash
 polkadot \
   --chain <path to spec json> \
-  --tmp \
+  --base-path /tmp/relay-charlie \
   --ws-port 9966 \           # Any unused port
   --port 30335 \             # Any unused port
   --charlie                  # The appropriate key for your validator

en/3-parachains/1-launch.md

@@ -5,7 +5,7 @@ specifically for parachain id 200, however you can re-use these instructions wit
 by adjusting occurrences of the number 200 accordingly.
 
 Note that the `parachain-collator` command used below comes from the [substrate-parachain-template repo](https://github.com/substrate-developer-hub/substrate-parachain-template/)
-that we set up in the [Preparation/Compiling step]((../README#versions-of-software) at a _specific_ commit.
+that we set up in the [Preparation/Compiling step](/#versions-of-software) at a _specific_ commit.
 
 ## Generate Parachain Genesis State
 
@@ -42,7 +42,7 @@ relay chain spec we used when launching relay chain nodes.
 ```bash
 parachain-collator \
   --collator \
-  --tmp \
+  --base-path /tmp/parachain-alice \
   --parachain-id 200 \
   --port 40333 \
   --ws-port 9844 \
@@ -64,7 +64,7 @@ specify the parachain id.
 
 > Remember to change the collator-specific values if you are executing
 > these instructions a second time for a second parachain.
-> You will use the same relay chain chainspec, but need different ports exposed.
+> You will use the same relay chain chain spec, but need different ports exposed.
 
 > A Parachain node = (full) collator + (full) vallidator node.
 > _Eventually_, this will change to only need a minimal light client for the relay chain node.

en/3-parachains/2-register.md

@@ -17,6 +17,8 @@ The transaction can be submitted **on a relay chain node** from
 
 ![Registration screenshot](../../assets/img/registration-screenshot.png)
 
+This successful dispatch will emit the `sudo.Sudid` event, viewable in the relay chain explorer page.
+
 If you are running a network with more than two validators you can add more parachains through the
 same interface with the parameters adjusted accordingly. More important details on this in the
 [latter on in this tutorial](en/3-parachains/4-more-nodes).
@@ -26,7 +28,15 @@ same interface with the parameters adjusted accordingly. More important details
 ### Block Production
 
 The collator should start producing parachain blocks (aka collating) once the registration is
-successful. The collator should start producing log messages like the following:
+successful. **Look in the block explorer tab on the Apps ui for a `parasInherent.enter` event -**
+**this signals that the parachain is now active**.
+
+> This may take a while! be patient as you need to wait for a new session to begin first.
+> This is 10 blocks for the 
+> [included rococo `chain-spec.json`](en/1-prep/2-chain-spec?id=_1a-using-a-prebuilt-chain-spec) 
+> in this workshop's files.
+
+Finally, the collator should start producing log messages like the following:
 
 ```
 2021-01-14 16:09:54  [Relaychain] ✨ Imported #519 (0x7c22…71b8)
@@ -44,6 +54,27 @@ successful. The collator should start producing log messages like the following:
 2021-01-14 16:10:05  [Parachain] 💤 Idle (0 peers), best: #17 (0x4d77…20d0), finalized #16 (0xd7e0…ae67), ⬇ 605.2kiB/s ⬆ 595.0kiB/s
 ```
 
+#### Collator Data Base Corruption or Loss
+
+> NOTE: your sole collator is the _only home of all parachain data_ as there is only one node
+> on your entire network! Relay chains only store _header_ information! If the parachian DB is lost
+> (my using `--tmp` for you collator as an example) you will **NOT** be able to recover the chain!
+
+If you _must_ purge your chain, you need to deregister and re-register! It may be easier in testing
+to instead purge all the chains. To purge the collator DB run:
+
+```bash
+# Purge the collator(s)
+parachain-collator purge-chain\
+  --base-path <your collator DB path set above> \  # <-- set a proper path
+
+# Purge the validator(s)
+polkadot purge-chain\
+  --base-path <your collator DB path set above> \  # <-- set a proper path
+```
+
+Then register from a [blank slate](#registration-transaction) again.
+
 ### Parachian Block Finalization
 
 The relay chain tracks the latest blocks (the heads) of each parachain. When a relay chain block

en/3-parachains/3-interact.md

@@ -15,8 +15,16 @@ parachain node at https://polkadot.js.org/apps/#/?rpc=ws://localhost:9844
 You can make some simple token transfers to ensure that the parachain is operating normally. You can
 also make some on-chain remarks by submitting `Extrinsics` -> `System` -> `remark`.
 
-If transactions go through as expected, you have a working parachain!
-<!-- In the next section we'll learn about cross-chain transfers. -->
+If transactions go through as expected, you have a working parachain! If you get a UI error
+indicating "Could not convert parameter `tx` between node and runtime: No such variant in 
+enum MultiSignature", go into `Settings` -> `Developer` and add these metadata types:
+
+```json
+{
+  "Address": "MultiAddress",
+  "LookupSource": "MultiAddress"
+}
+```
 
 ## Cross-chain Message Passing (XCMP)
 

en/3-parachains/4-more-nodes.md

@@ -6,7 +6,7 @@ parachain.
 
 > You should have _at least_ 2 **validators** (relay chain nodes) running for every **collator**
 > (parachain nodes) on your network! This is why we have included a prebuilt 3 and 4 validator 
-> chainspec for you in [the workshop assets](../README#_1a-using-a-prebuilt-chain-spec), and you
+> chain spec for you in [the workshop assets](/#_1a-using-a-prebuilt-chain-spec), and you
 > can add more as needed, described there.
 
 ## Start the Second Collator
@@ -17,12 +17,12 @@ we used to start the first collator, but again we need to avoid conflicting port
 ```bash
 parachain-collator \
   --collator \
-  --tmp
+  --base-path /tmp/parachain-bob \         # <-- set a proper path
   --parachain-id <Your ID> \
   --port <Your chosen libp2p port> \
   --ws-port <Your chosen websocket port> \
   --bootnodes <Your first collator> \
-  --bob \
+  --bob \                                  # <-- set a proper authority
   -- \ # Any flags after this -- go to the embedded polkadot node
   --chain <relay chain spec json> \
   --port <Your chosen libp2p port> \
@@ -37,12 +37,12 @@ leave out the `--collator` flag.
 
 ```bash
 parachain-collator \
-  --tmp
+  --base-path <a DB base path> \           # <-- set a proper path
   --bootnodes <Your first collator> \
   --ws-port <Your chosen websocket port> \
   --port <Your chosen libp2p port> \
   --parachain-id <Your ID> \
   -- \ # Any flags after this -- go to the embedded polkadot node
-  --chain spec.json \
+  --chain <relay chain spec json> \
   --bootnodes <Alice, Bob, and other relay chain collators>
 ```

en/README.md

@@ -63,11 +63,11 @@ be sure that you are testing against the exact same build of that relay chainn.
 
 This workshop has been tested on commits:
 
-- **Polkadot @ [`943038a`](https://github.com/paritytech/polkadot/commit/943038a888bfaf736142642e2610b248f7af486c)**
-- **Parachain Template @ [`40b8581`](https://github.com/substrate-developer-hub/substrate-parachain-template/commit/40b858149b212e493da08d80e0fc5b06a6b0b72d)**
-- **Polkadot JS Apps @ [`e2b51e6 `](https://github.com/polkadot-js/apps/commit/e2b51e6033f0a0c25fffc037be18d1326e1e8f39)**
+- **Polkadot @ [`127eb17a`](https://github.com/paritytech/polkadot/commit/127eb17a25bbe2a9f2731ff11a65d7f8170f2373)**
+- **Parachain Template @ [`1e1e725`](https://github.com/substrate-developer-hub/substrate-parachain-template/commit/1e1e7257e4429e8413f5a27940d4941d220317a7)**
+- **Polkadot JS Apps @ [`35b238a `](https://github.com/polkadot-js/apps/commit/35b238a1bfb59a4c4e7488671a7261b54bf314c9)**
     - _It is generally expected that the [hosted Polkadot JS Apps](https://polkadot.js.org/apps/#/explorer)
-      _should work. If you have issues, build and host this yourself at this commit._
+      _should_ work. If you have issues, build and host this UI yourself, at this commit.
 
 > NOTE: you **must** use these commits exactly to ensure that you do not run into conflicts as parachain development
 > development is actively making breaking changes between commits on these repositories!