What a network needs besides nodes
A network with only participating nodes has no way for a new one to find it, nothing to sync from, and no endpoint for applications that will not run a node themselves. Those roles are usually assembled from separate projects. Here they are run modes.
Bootnodes
The first peer everyone else finds.
- Bootnode run mode, no separate binary
- discv4 and discv5 with ENR records
- DNS-based peer lists for rotating a set without redeploying
State serving
Somewhere for new nodes to sync from.
- SNAP serving as a role, not just SNAP receiving
- Bounded by response size and wall clock so serving cannot exhaust the node
- Off by default, on for server, archival and bootnode roles
RPC relay
A public endpoint in front of the network.
- Relay deployment profile with the read surface exposed
- A gRPC bridge for aggregation gateways upstream of it
- Pruned storage, because a relay does not need full history
Dashboards and a faucet
The parts a network needs to be usable.
- Grafana dashboards and alerting rules that ship with the client
- A faucet for distributing test funds on a network you originated
- Nothing to assemble from third-party pieces
Consuming discovery, and serving it
Every client consumes discovery. It dials peers it was told about, resolves a list published over DNS, and reads the records other nodes publish describing themselves. That is all it takes to join a network somebody else is already running.
Originating one needs the other side. A node has to answer discovery rather than only ask it, and something has to author and publish the records that describe the network before anyone can look it up: a signed node record carrying the chain identity and fork position, and a DNS tree that lets the peer set be rotated without touching anything that points at it.
Fukuii does both, which is what turns a network's identity into data you publish rather than a list of addresses each participant has to be handed out of band.
Keeping the wrong peers out
A new network shares its wire protocol with every other network using the same one, so discovery's first job is to not waste effort on peers from somewhere else. The checks run in order before a dial is attempted: the network identifier, then the genesis hash, then the fork position. A peer failing any of them is rejected before a connection is opened rather than after a handshake reveals the mismatch. On a network you have just originated, that is what stops its peer set filling with nodes that were never going to agree with it.
One binary, several jobs
A role is not a separate build or a different download. It selects a composition: which sync path the node takes, whether it answers state requests from others, and how much history it keeps. Each role covers one way a node takes part in a network. Bootnode is listed apart, because serving discovery is infrastructure for the network rather than participation in it.
| Role | What it is for | Serves state | History kept |
|---|---|---|---|
| Archival | Deep history for applications and analytics | Yes | Full, from genesis |
| Tip server | Serving current data to other nodes | Yes | To the sync pivot |
| Mining pool | The node behind a pool | Yes | To the sync pivot |
| RPC relay | A public read endpoint, pruned | Optional | Bounded |
| Resource-light | A machine that is not a server | No | None below the anchor |
| Validator | Proof-of-Stake block production | Optional | To the sync pivot |
| Bootnode | Discovery infrastructure for the network | Yes | As configured |
Serving state is off unless the role asks for it. A node that serves is answering requests that cost it disk reads and bandwidth, so the capability is bounded by both response size and elapsed time: a request that would take too long or return too much is cut short rather than allowed to crowd out the node's own work.
From genesis to a usable network
The order matters more than the difficulty. Each step produces something the next one needs, and every one of them is the same binary under a different configuration.
The first step is the one most easily skipped. A network's initial accounts and node identities have to exist before the genesis file that references them can be written, and the client generates both: node keys, encrypted account keys, the addresses derived from them, and the allocation entries that carry those addresses into genesis. Getting this wrong is not recoverable by editing a config afterward, because the genesis hash it produces is the network's identity.
| Step | What it produces |
|---|---|
| Generate the identities | Node keys and accounts, and the genesis allocation entries they become |
| Define the network | A genesis file: chain identity, consensus algorithm, initial validators |
| Originate it | The first nodes, all starting from the genesis they agree on |
| Make it findable | Bootnodes answering discovery and publishing signed node records, optionally over DNS |
| Make it syncable | At least one node serving state, so a joining node has a source |
| Make it reachable | An RPC relay for applications that will not run their own node |
| Make it observable | Metrics, dashboards and alerts across the whole set |
This is how a development network, a testnet and a consortium chain all get built. They differ in who is allowed to join and how consensus is chosen, not in the infrastructure they need.
Permissioned and private networks →