Deploy an AppChain#

Deploying a chain on the testnet takes four Hub transactions and a running collator. tog-collator tx writes each transaction unsigned, and tog-cli send signs and sends it with your key, so the key that pays never has to sit on the collator.

Keys#

Key	Made with	What it does
Manager key	`head -c 32 /dev/urandom > manager.key`	Pays for and signs the code upload, the registration and coretime
Author key	`tog-collator new-author-key --out author.key`	Seals the chain's blocks. Its account is the collator on the Hub and holds its bond
Network key	Created by `tog-collator` on first start	The collator's peer-to-peer identity

new-author-key prints the author's account. Use it as --authority in the chain spec (Build an AppChain), and fund it from the faucet: registering a collator bonds 100 test-TOG.

The collator's config#

collator.toml:

chain_id = <CHAIN_ID>
network_id = 2
runtime = "spec/runtime.wasm"
genesis = "spec/genesis.bin"
network_key = "keys/network.key"
author_key = "keys/author.key"
data_dir = "chain"
listen = ["/ip4/0.0.0.0/tcp/30700"]
peers = []
rpc = "127.0.0.1:9944"

[hub]
era_length = 1800
session_length = <SESSION_LENGTH>
genesis = "genesis.borsh"
peers = [
  { addr = "<BOOTNODE_1>", asn = <ASN_1> },
  { addr = "<BOOTNODE_2>", asn = <ASN_2> },
]

The collator follows the Hub with a light client. List Hub bootnodes from at least two different networks (ASNs); the Networks page gives them with their ASN.

Check what the Hub holds for your chain at any time:

tog-collator --config collator.toml status
# code_status=…  next_chain_id=…  chain_registered=…  pending/final heads  collator=…

Steps#

<MANAGER> is the manager key's address. Read its nonce with tog-cli account <MANAGER> -c client.toml; each transaction below uses the next one.

Upload the code.
```
tog-collator --config collator.toml tx --signer <MANAGER> --nonce N --out code.borsh upload-code
for f in code.borsh code.borsh.*; do [ -f "$f" ] && tog-cli send "$f" --key manager.key -c client.toml; done
```
Large code is split into several transactions with consecutive nonces (code.borsh, code.borsh.1, …); send them in order. Then wait until status shows code_status=accepted: the validators pre-check the code before it can be used.

Register the chain.

tog-collator --config collator.toml tx --signer <MANAGER> --nonce N --out register.borsh \
  register-appchain --spec spec/chain-spec.toml
tog-cli send register.borsh --key manager.key -c client.toml

chain_id in the config must be the Hub's next_chain_id at this moment.

Buy coretime. An AppChain pays for the Hub to validate its blocks. On the testnet, prepay on-demand coretime:

tog-collator --config collator.toml tx --signer <MANAGER> --nonce N --out fund.borsh \
  fund-on-demand --amount <BASE_UNITS>
tog-cli send fund.borsh --key manager.key -c client.toml

Wait for chain_registered=true.

Register the collator. This one is signed by the author key and sent by the collator itself:
```
tog-collator --config collator.toml send register-collator
```
Run the collator.
```
tog-collator --config collator.toml run
```
status shows collator=ok once it may collate, and the chain's final block advances.

Upgrading the runtime#

Before you upgrade, try the new code against the chain's current state. The collator must run with rpc_unsafe = true for this, so do it on a node whose RPC only you can reach:

tog-cli try-upgrade target/tog/runtime.wasm --rpc http://127.0.0.1:9944

It builds the upgrade block and the migration blocks after it without keeping them, and exits non-zero if the upgrade would not fit the Hub's limits.

Running a full node#

Leave out author_key and the node follows the chain without authoring. Set rpc to serve JSON-RPC to your application, and indexer to a file the node appends the chain's changes to.