Running a private network

A private network is a set of nodes that dial only each other and trust board keys of their own. Use it to try the ledger, the sporks and the commands before they are used on the real network.

Never give a private network the real board keys. A spork is signed over its content and nothing names the network, so a spork made on a private network with the real keys would be accepted on the real one.

Keep the network apart

What	How
No dialling of the seed nodes	--no-seeds
Board keys of your own	--network-keys <public>,<public>, on every node and on every signing command, two or more keys made with hedgehog util key-generate; the nodes and commands trust no other keys. These keys are also the root of the chain of board keys, so a change to them builds on this list and every node, cli and util command needs the same one
Ports that do not collide	-p for the peer-to-peer port and -r for the REST port, different for each node on a machine; with --preview also --no-s3, or a --s3port of its own, as each node then opens the S3 endpoint on 52885
A data directory of its own	On Linux, XDG_DATA_HOME, see Running Hedgehog

The nodes find each other only when told: start one with --no-seeds, then give each of the others the address of a node already running, hedgehog cli --restport <r> node-add <ip>:<p>.

A ledger on it

1. Make a key for each validator, hedgehog util ledger-key-generate <file>, and keep the public keys it prints.
2. Put a snapshot in the data directory of every node as bootstrap.dat. A node refuses a snapshot whose signature does not verify against a board key it knows, so the published snapshot, signed by the real keys, does not do. A node that holds no snapshot it can open downloads the one of the release at every start and refuses that too, after the whole transfer. It then tries again after 10 seconds, then twice as long each time up to 10 minutes, until it holds a snapshot it can open. Cut the signature off a copy of the published snapshot instead. A node uses an unsigned copy with a warning that it is not verified; to sign it, use hedgehog bootstrap sign, which judges its key by the longer of the chain the release ships and this machine’s record of the board keys; --spork-db <file> adds the chain of a spork database, when it holds more of the chain than this machine verified before. The genesis commits to the content, which stays the same.
3. Make the genesis from the snapshot and the public keys with hedgehog util ledger-genesis, see Running a ledger node, and give the same file to every node.
4. Start each node with --preview --no-s3 --ledger --ledger-genesis <file> --ledger-key <file>. The ledger is not part of the release, and --preview is the hidden switch that turns it on.
5. Propose the mint supply, mint storage, fee and blacklist sporks with gridspork-set and gridspork-grow, and co-sign them with the second board key. The ledger-fee and ledger-blacklist subcommands are hidden from --help. The signing commands take the same --network-keys as the nodes, and the board key from -k, --key-file or $HEDGEHOG_BOARD_KEY; it never leaves the machine. See Ledger sporks and Changing a spork. Until then hedgehog cli ledger info lists them as unset.
6. To change the board keys of the network, make and approve a change file with util board-keys, then send it with gridspork-set board-keys -D <change file> -k <key> and co-sign it; when the node holds no spork of the type, add --first-version to gridspork-set and --first-version BOARD_KEYS to gridspork-cosign. It builds on the same --network-keys list, see Changing the board keys.
7. Check that every node shows the same chain id, that it is running and that the validators sign.

rehearsal/ledger-rehearsal.sh in the source does all of this for four nodes on one machine: it takes the spork database of an earlier build through util spork-db sign and import, sends a mint and a transfer through the nodes, and changes the board keys while they run. Its README.md gives the ports and options.