Verifying your setup
Some simple steps to make sure your node is running and is in fact to connect to the network correctly.
Before you can actually start validating, it is recommended that you make sure your node is connected to the network, sees other participants, is receiving updates and is able to respond to RPC calls.


First check the logs. Your node will likely start out by synchronizing with the general network, and after a while start getting blocks in real time. To get the logs out of docker, you will need to run:
docker logs <your_nodes_name> # or the container name you have chosen with `--container_name`
You can run docker logs --follow <your_nodes_name> to get the output in real time.
This should return some lines, including the initial ones starting with “Syncing” and later ones with “Idle”. Importantly either of these words should be followed by “(XX peers)” where “XX” is a number that should be positive. An example of a healthy result of this command follows.
2022-04-08 15:34:00 ⚙️ Syncing, target=#17456723 (16 peers), best: #17451334 (0x57d3…d0c8), finalized #17451333 (0xcb6f…df65), ⬇ 320.6kiB/s ⬆ 116.3kiB/s
2022-04-08 15:34:05 ⚙️ Syncing 100.4 bps, target=#17456728 (12 peers), best: #17451836 (0x2bdb…ce91), finalized #17451835 (0xdd54…8cb6), ⬇ 9.2kiB/s ⬆ 6.9kiB/s
2022-04-08 15:34:10 ⚙️ Syncing 86.4 bps, target=#17456733 (12 peers), best: #17452268 (0xb35f…1b74), finalized #17452268 (0xb35f…1b74), ⬇ 14.8kiB/s ⬆ 6.2kiB/s
2022-04-08 15:34:15 ⚙️ Syncing 111.4 bps, target=#17456738 (12 peers), best: #17452825 (0xfa16…0df8), finalized #17452822 (0xa567…b51b), ⬇ 166.8kiB/s ⬆ 8.9kiB/s
2022-04-08 15:34:20 ⚙️ Syncing 104.8 bps, target=#17456743 (13 peers), best: #17453349 (0x2e58…6dea), finalized #17453348 (0x566b…0bf1), ⬇ 7.8kiB/s ⬆ 7.5kiB/s
2022-04-08 15:34:25 ⚙️ Syncing 106.6 bps, target=#17456748 (13 peers), best: #17453882 (0x82d3…dbaa), finalized #17453879 (0xf3bb…c57a), ⬇ 7.4kiB/s ⬆ 6.7kiB/s
2022-04-08 15:34:30 💤 Idle (13 peers), best: #17454421 (0xc4c6…6538), finalized #17454418 (0x22eb…ef7d), ⬇ 119.7kiB/s ⬆ 7.5kiB/s
2022-04-08 15:34:35 💤 Idle (13 peers), best: #17454957 (0x898c…79be), finalized #17454956 (0xea9f…2cfa), ⬇ 9.3kiB/s ⬆ 7.4kiB/s
2022-04-08 15:34:40 💤 Idle (15 peers), best: #17455461 (0xaa11…094e), finalized #17455461 (0xaa11…094e), ⬇ 22.0kiB/s ⬆ 8.6kiB/s
2022-04-08 15:34:45 💤 Idle (15 peers), best: #17455499 (0x9f9a…43ee), finalized #17455499 (0x9f9a…43ee), ⬇ 10.0kiB/s ⬆ 8.0kiB/s
In some cases (if the node is already synced) the logs might look like this:
2022-05-23 13:49:38 💤 Idle (16 peers), best: #1040703 (0x1373…b629), finalized #1040697 (0x8b73…e9af), ⬇ 12.9kiB/s ⬆ 4.2kiB/s
2022-05-23 13:49:39 ✨ Imported #1040704 (0xd7bc…b4a3)
2022-05-23 13:49:40 ✨ Imported #1040705 (0xb7ff…3cc1)
2022-05-23 13:49:41 ✨ Imported #1040706 (0xd17f…852c)
2022-05-23 13:49:42 ✨ Imported #1040707 (0xe7b4…f1d1)
2022-05-23 13:49:43 ✨ Imported #1040708 (0xdd46…ab5e)
Which is also a sign of a healthy node.
If you see Failed to update handler: NoP2pAddresses in the logs don’t be alarmed: the node will get the P2P address soon.


Next you should check whether the RPC and WebSocket endpoints are externally accessible. They should be accessible for archivists and categorically should not be accessible for validators.
The tests should preferably be run on a machine outside of the local network containing the node, although many of them should give the same results as long as they are not run on the same machine.
To check whether RPC calls work execute
curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "rpc_methods"}'
using your own address instead of, obviously. For nodes without a DNS address you should omit the https://. This should return an extensive JSON response containing many RPC call names for archivists and some kind of error (depending on your exact setup) for validators.
Additionally check whether unsafe RPC call are possible to execute on externally available nodes:
curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "system_unstable_networkState"}'
This should return some kind of error on both archivists and validators.
Finally check whether you can perform unsafe operations on validators internally. There are multiple ways this could be done, for this one we assume you have ssh access to the machine:
ssh -L 9933:
In a separate terminal on the same machine run:
curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "system_unstable_networkState"}' localhost:9933
This should return a huge JSON response for validators and at most an error for archivists.
The easiest way of checking correct websocket accessibility is to attempt connecting using one of the polkadot.js instances. Any should work, but we recommend the appropriate wallet AlephZero is hosting, i.e. for testnet and for mainnet, to minimize confusion. Once there, click on the AlephZero logo, and then on the “Development” tab in the list that appears. In the “Custom endpoint” field fill your address in the form:
After a moment the usual view of a AlephZero connected wallet should appear, indistinguishable from any other archivist, for archivists. For validators this should get stuck on loading and never connect.
Copy link