Run a node
A node is a computer running the chain software, keeping its own copy of every block. You need one before you can register a validator, and everything on this page comes before the form in Create your validator.
Two kinds of node
An RPC node follows the chain and answers questions about it. It produces nothing, holds no keys and risks nothing. This is what you run if you want your own endpoint instead of using ours, and it is the sensible thing to run first.
A validator node does the same and also produces and signs blocks. It holds keys, it earns, and it can be punished. Every validator node starts life as an RPC node that syncs; the validating part is what you switch on afterwards.
Run the first kind until it is boring. An operator who has never watched a node sync is not ready to have money depend on one.
What you need
A machine that is always on. Downtime is punished, and a validator that is offline long enough is jailed and slashed. A laptop is not a node.
A fast disk. The chain writes constantly and reads randomly. An SSD is not optional, and the volume needs room to keep growing.
A stable connection, with the peer-to-peer port reachable from the internet.
Somebody who watches it. The chain does not send you a message when your node stops. See Watch your node.
Sizing is deliberately not stated here, because a young chain grows and any number written today would be wrong within a year. Ask on a ticket at support.l2protocol.com for what is current, and size up rather than down.
What the software is
The node is a fork of geth, so the binary is called geth and everything you know about running an Ethereum node still applies. It ships as a container image:
ghcr.io/l2protocol/l2p:latest
Two files go with it, and neither is optional.
genesis.json describes the first block and the state the chain started from. A node that initialises with the wrong genesis is on a different chain and will never find a peer. Download it, do not write it:
curl -O https://static.l2protocol.com/config/geth/genesis.json
It should report chain id 12216, which is the quickest check that you have the right file:
python3 -c "import json;print(json.load(open('genesis.json'))['config']['chainId'])"
config.toml is your node's own configuration.
Starting from nothing
Initialise the data directory once with the genesis file, then run the node against your configuration. In the image those live at /l2p/config/genesis.json and /l2p/config/config.toml, and the entrypoint does the initialise step for you when the data directory is empty:
geth --datadir /path/to/data init genesis.json
geth --config config.toml
From there it syncs. The first sync takes as long as it takes, and it is finished when the block number your node reports matches the chain head on l2pscan.com.
The configuration that matters
Most of config.toml can stay as it comes. These are the parts worth understanding.
| Setting | Why it matters |
|---|---|
NetworkId |
12216. Wrong here means a node that talks to nobody |
[Node.P2P] ListenAddr |
The peer port, :31398 in our own configuration. It has to be reachable from outside |
MaxPeers |
How many nodes yours connects to. More peers means hearing about blocks sooner |
[Node] HTTPHost, HTTPPort |
Only if you want to serve RPC. Leave it closed to the internet unless you mean it |
[Ethstats] URL |
Reports your node to the network status page. See below |
Do not expose the RPC port to the internet unless serving RPC is the point of the node. An open RPC endpoint is scanned within hours of appearing.
The keys
A validator node signs with two different keys, and both live on the node.
The consensus account signs blocks. It is an ordinary account, created the usual way.
The BLS key signs finality votes. Its public half becomes your vote address, and you prove you hold the private half with a BLS proof.
Create your validator has the exact commands for creating the BLS key and generating the proof, in the order you need them.
Back up both, and their passwords, somewhere that is not the node. A node you can rebuild is an afternoon of work; a key you cannot is a validator you cannot restart.
Once it is running
Watch it. Add it to the network status page so you can see at a glance whether it is keeping up. See Watch your node.
Read the log. The node writes what it is doing. When something is wrong, the answer is nearly always in there before it is anywhere else.
Plan for maintenance. The chain allows a limited number of validators to be in maintenance at once, which is how you upgrade without being punished for the downtime. Overstaying it costs you.
Do not run two validator nodes on the same keys. Two nodes signing with the same consensus key is exactly what a double sign looks like to the chain, and it carries the heaviest punishment there is. This is the single most expensive mistake an operator can make, and it is usually made while trying to be careful about redundancy.
Then register
With the node synced and the keys in hand, the registration form is the last step. See Create your validator, and Run a validator for what the job pays and what it costs.