Merge pull request #204 from DataHighway-DHX/updated_runtime_version

upgraded spec version and cargo file

.github/workflows/docker.yml

@@ -5,15 +5,16 @@ on:
   push:
     branches:
       - master
-      - develop
 jobs:
   build:
     runs-on: ubuntu-latest
     steps:
     - uses: actions/checkout@master
     - name: Publish to Registry
+      pre: echo ::save-state name=RELEASE_VERSION::$(echo ${GITHUB_REF:10})
       uses: elgohr/Publish-Docker-Github-Action@master
       with:
         name: dhxdocker/datahighway
         username: ${{ secrets.DOCKER_USERNAME }}
         password: ${{ secrets.DOCKER_PASSWORD }}
+        tags: "latest,${{ env.STATE_RELEASE_VERSION }}"

CONTRIBUTING.md

@@ -356,6 +356,44 @@ cargo +nightly-2021-03-10-aarch64-apple-darwin fmt --all -- --check
 * Question: What is the Peer ID and the `--node-key`?
     * Ans: See the documentation here https://substrate.dev/docs/en/knowledgebase/integrate/subkey#generating-node-keys. Run the command `subkey generate-node-key --file node-key` to generate and output to the screen a Peer ID for that you may share publicly to the list of bootnodes that validators may connect to. It also generates a file 'node-key' that contains the node's libp2p key that you provide as the value of `--node-key` when starting that validator bootnode, but you should keep the `--node-key` private because if someone else starts their node with the same `--node-key` that you're using then you might get slashed.
 
+* Question: Why do I get this error when trying to run a node on chain "local" `Error: Service(Network(The same bootnode (`/ip4/127.0.0.1/tcp/30333`) is registered with two different peer ids: 12D3KooWKS7jU8ti7S5PDqCNWEj692eUSK3DLssHNwTQsto9ynVo and 12D3KooWC92KaQrzxLa3xk7yVJwCCs9vMGndt23dZAtMoR1aQc3V))`?
+    * Ans: It is likely that you have run the first node with the following Node Key, where chain_def_local.json was build on your local machine, and the 2nd node was run as shown below and tries to connect to `QmWYmZrHFPkgX8PgMgUpHJsK6Q6vWbeVXrKhciunJdRvKZ`, which is actually the Peer ID for DataHighway Harbour Testnet, when you should instead be using the Peer ID of `12D3KooWKS7jU8ti7S5PDqCNWEj692eUSK3DLssHNwTQsto9ynVo` for DataHighway Local Testnet that has already been included in chain_spec.rs genesis configuration such that the `--bootnodes` flag does not need to be specified.
+
+First node
+```
+./target/release/datahighway --validator \
+  ...
+  --node-key 88dc3417d5058ec4b4503e0c12ea1a0a89be200fe98922423d4334014fa6b0ee
+  --chain ./node/src/chain-built/chain_def_local.json \
+  --name "Local Validator Node 1" \
+  --port 30333 \
+  --ws-port 9944 \
+  --rpc-port 9933 \
+  ...
+```
+
+Second node
+
+```
+./target/release/datahighway --validator \
+  ...
+  --bootnodes /ip4/127.0.0.1/tcp/30333/p2p/12D3KooWKS7jU8ti7S5PDqCNWEj692eUSK3DLssHNwTQsto9ynVo \
+  --chain ./node/src/chain-built/chain_def_local.json \
+  --name "Local Validator Node 2" \
+  --port 30334 \
+  --ws-port 9945 \
+  --rpc-port 9934 \
+  ...
+```
+
+* Question: Why do I get this error when trying to run a node on chain "local"
+```
+ERROR tokio-runtime-worker sync: Bootnode with peer id `12D3KooWKS7jU8ti7S5PDqCNWEj692eUSK3DLssHNwTQsto9ynVo` is on a different chain (our genesis: 0x0aa8…cdf9 theirs: 0x7787…87ed)
+```
+    * Ans: Check that you have added all necessary flags in your command, and if you've used multiple lines make sure there are no missing newline characters `\` so that it recognises the `--chain ...` that you've provided
+
+* Question: When I run a local network using chain "local" by connecting the peer nodes using `--chain local`, why doesn't it generate blocks like it does when using `--chain ./node/src/chain-built/chain_def_local.json` and finalise blocks after running at least five nodes, where the chain_def_local.json file that is used was built on the same machine we are running the command from?
+    * Ans: Check that you have added all necessary flags in your command, and if you've used multiple lines make sure there are no missing newline characters `\` so that it recognises the `--chain ...` that you've provided
 
 ## Technical Support <a id="chapter-c00ab7"></a>
 

EXAMPLES.md

@@ -112,13 +112,15 @@ In each terminal we will connect using the "local" chain specification
 
 Run Alice's bootnode using the raw chain definition file that was generated
 
+Note that it should work whether you use `--chain local \` or `--chain ./node/src/chain-built/chain_def_local.json \` below. See section "Create custom blockchain configuration" and https://substrate.dev/docs/en/tutorials/start-a-private-network/customspec for when we would generate the chain spec and definition .json file when we have a custom chain (e.g. brickable, harbour and westlake)
+
 ```bash
 ./target/release/datahighway --validator \
   --unsafe-ws-external \
   --unsafe-rpc-external \
   --rpc-cors=all \
   --base-path /tmp/polkadot-chains/alice \
-  --chain ./node/src/chain-built/chain_def_local.json \
+  --chain local \
   --node-key 88dc3417d5058ec4b4503e0c12ea1a0a89be200fe98922423d4334014fa6b0ee \
   --alice \
   --port 30333 \
@@ -135,7 +137,7 @@ When the node has started, copy the libp2p local node identity of the node, and
 * Notes:
   * Alice's Substrate-based node on default TCP port 30333
   * Her chain database stored locally at `/tmp/polkadot-chains/alice`
-  * In this example, Bootnode ID of her node is `Local node identity is: QmWYmZrHFPkgX8PgMgUpHJsK6Q6vWbeVXrKhciunJdRvKZ` (peer id), which is generated from the `--node-key` value specified below and shown when the node is running. In **production** you should NOT share the `--node-key` as other nodes could use it and you might get slashed. Note that `--alice` provides Alice's session key that is shown when you run `subkey inspect --scheme ed25519 "//Alice"`, alternatively you could provide the private key that is necessary to produce blocks with `--key "bottom drive obey lake curtain smoke basket hold race lonely fit walk//Alice"`. In production the session keys are provided to the node using RPC calls `author_insertKey` and `author_rotateKeys`. If you explicitly specify a `--node-key` (i.e. `--node-key 88dc3417d5058ec4b4503e0c12ea1a0a89be200fe98922423d4334014fa6b0ee`) when you start your validator node, the logs will still display your peer id with `Local node identity is: Qxxxxxx`, and you could then include it in the chain_spec_local.json file under "bootNodes". Also the peer id is listed when you go to view the list of full nodes and authority nodes at Polkadot.js Apps https://polkadot.js.org/apps/#/explorer/datahighway
+  * In this example, Bootnode ID of her node is `Local node identity is: 12D3KooWKS7jU8ti7S5PDqCNWEj692eUSK3DLssHNwTQsto9ynVo` (peer id), which is generated from the `--node-key` value specified below and shown when the node is running. In **production** you should NOT share the `--node-key` as other nodes could use it and you might get slashed. Note that `--alice` provides Alice's session key that is shown when you run `subkey inspect --scheme ed25519 "//Alice"`, alternatively you could provide the private key that is necessary to produce blocks with `--key "bottom drive obey lake curtain smoke basket hold race lonely fit walk//Alice"`. In production the session keys are provided to the node using RPC calls `author_insertKey` and `author_rotateKeys`. If you explicitly specify a `--node-key` (i.e. `--node-key 88dc3417d5058ec4b4503e0c12ea1a0a89be200fe98922423d4334014fa6b0ee`) when you start your validator node, the logs will still display your peer id with `Local node identity is: Qxxxxxx`, and you could then include it in the chain_spec_local.json file under "bootNodes". Also the peer id is listed when you go to view the list of full nodes and authority nodes at Polkadot.js Apps https://polkadot.js.org/apps/#/explorer/datahighway
 
 #### Terminal 2
 
@@ -147,8 +149,8 @@ Run Bob's Substrate-based node on a different TCP port of 30334, and with his ch
   --unsafe-rpc-external \
   --rpc-cors=all \
   --base-path /tmp/polkadot-chains/bob \
-  --bootnodes /ip4/127.0.0.1/tcp/30333/p2p/QmWYmZrHFPkgX8PgMgUpHJsK6Q6vWbeVXrKhciunJdRvKZ \
-  --chain ./node/src/chain-built/chain_def_local.json \
+  --bootnodes /ip4/127.0.0.1/tcp/30333/p2p/12D3KooWKS7jU8ti7S5PDqCNWEj692eUSK3DLssHNwTQsto9ynVo \
+  --chain local \
   --bob \
   --port 30334 \
   --ws-port 9945 \
@@ -171,8 +173,8 @@ Run Charlie's Substrate-based node on a different TCP port of 30335, and with hi
   --unsafe-rpc-external \
   --rpc-cors=all \
   --base-path /tmp/polkadot-chains/charlie \
-  --bootnodes /ip4/127.0.0.1/tcp/30333/p2p/QmWYmZrHFPkgX8PgMgUpHJsK6Q6vWbeVXrKhciunJdRvKZ \
-  --chain ./node/src/chain-built/chain_def_local.json \
+  --bootnodes /ip4/127.0.0.1/tcp/30333/p2p/12D3KooWKS7jU8ti7S5PDqCNWEj692eUSK3DLssHNwTQsto9ynVo \
+  --chain local \
   --charlie \
   --port 30335 \
   --ws-port 9946 \
@@ -196,8 +198,8 @@ Run Dave's node using different ports.
   --unsafe-rpc-external \
   --rpc-cors=all \
   --base-path /tmp/polkadot-chains/dave \
-  --bootnodes /ip4/127.0.0.1/tcp/30333/p2p/QmWYmZrHFPkgX8PgMgUpHJsK6Q6vWbeVXrKhciunJdRvKZ \
-  --chain ./node/src/chain-built/chain_def_local.json \
+  --bootnodes /ip4/127.0.0.1/tcp/30333/p2p/12D3KooWKS7jU8ti7S5PDqCNWEj692eUSK3DLssHNwTQsto9ynVo \
+  --chain local \
   --dave \
   --port 30336 \
   --ws-port 9947 \
@@ -218,8 +220,8 @@ Run Eve's node using different ports.
   --unsafe-rpc-external \
   --rpc-cors=all \
   --base-path /tmp/polkadot-chains/eve \
-  --bootnodes /ip4/127.0.0.1/tcp/30333/p2p/QmWYmZrHFPkgX8PgMgUpHJsK6Q6vWbeVXrKhciunJdRvKZ \
-  --chain ./node/src/chain-built/chain_def_local.json \
+  --bootnodes /ip4/127.0.0.1/tcp/30333/p2p/12D3KooWKS7jU8ti7S5PDqCNWEj692eUSK3DLssHNwTQsto9ynVo \
+  --chain local \
   --eve \
   --port 30337 \
   --ws-port 9948 \
@@ -230,6 +232,8 @@ Run Eve's node using different ports.
   --rpc-methods=Unsafe
 ```
 
+* Note: On DataHighway Harbour Testnet, the peer bootnode ID (node ID) that should be included in the .env file is different since a different node-key is used. On DataHighway Local Testnet we use node ID of `12D3KooWKS7jU8ti7S5PDqCNWEj692eUSK3DLssHNwTQsto9ynVo`, which is included in the chain_spec.rs
+
 * Check that the chain is finalizing blocks (i.e. finalized is non-zero `main-tokio- INFO substrate  Idle (2 peers), best: #3 (0xaede…b8d9), finalized #1 (0x4c69…f605), ⬇ 3.3kiB/s ⬆ 3.7kiB/s`)
 
 * Note that in this [commit](https://github.com/DataHighway-DHX/node/pull/140/commits/63f81c4e00e360c6df8549b6c870a17f9719f58b) we added ImOnline and AuthorityDiscovery, as well as added Dave, Eve, and Ferdie

node/Cargo.toml

@@ -3,7 +3,7 @@ authors = ['MXC Foundation gGmbH <https://t.me/mxcfoundation>', 'Luke Schoen <lu
 build = 'build.rs'
 edition = '2018'
 name = 'datahighway'
-version = '3.0.4'
+version = '3.0.5'
 
 [[bin]]
 name = 'datahighway'
@@ -22,12 +22,12 @@ structopt = '0.3.8'
 hex-literal = '0.3.1'
 
 # local node-specific dependencies
-datahighway-runtime = { version = '3.0.4', path = '../runtime' }
+datahighway-runtime = { version = '3.0.5', path = '../runtime' }
 
 # Substrate dependencies
 frame-benchmarking = '3.1.0'
 frame-benchmarking-cli = '3.0.0'
-module-primitives = { version = '3.0.4', default-features = false, path = '../pallets/primitives' }
+module-primitives = { version = '3.0.5', default-features = false, path = '../pallets/primitives' }
 pallet-authority-discovery = '3.0.0'
 pallet-democracy = '3.0.0'
 pallet-im-online = '3.0.0'