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.

Logs

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.

To get the last 24h of logs as a file, use the following command: docker logs --since 24h <your_nodes_name> > file.log 2>&1

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.

Endpoints

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.

RPC

To check whether RPC calls work execute

curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "rpc_methods"}' https://example.com:9944

using your own address instead of example.com, 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"}' https://example.com:9944

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 9944:127.0.0.1:9945 example.com

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:9944

This should return a huge JSON response for validators and at most an error for archivists.

WebSocket

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. https://test.azero.dev/ for testnet and https://azero.dev/ 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:

wss://example.com:9944

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.