Connecting Your Gateway to the Consensus Layer

The consensus layer serves as the backend infrastructure for the Ethereum blockchain, hosting and verifying the efficacy of validators.

Several consensus layer clients exist including Lighthouse, Prysm, Nimbus, and Teku.

As mentioned previously, the bloXroute Gateway connects to your node as a peer. To connect your gateway as a peer to your Consensus Layer client, you should

1. Include your Consensus Layer client in the --multiaddr startup argument. Consensus Layer client's identity is available from the output of /eth/v1/node/identity Beacon API endpoint.

2. Add your gateway peer ID as a “trusted peer”.

This is similar to the requirements for connecting to the Execution Layer client, but the execution is a bit different.

1. Make sure Beacon node uses private key.

Strictly speaking, this step is not required. If your node does not have a private key, then every time you restart it it will generate a new public key. This public key is part of the multiaddr argument, which means every time you restart your node you will need to update the gateway startup argument.

Lighthouse

Verify Lighthouse has the private key file beacon/network/key within the datadir.

Prysm

Verify the Prysm node started with --p2p-priv-key. This will ensure the beacon node peer ID will not change if the Prysm node restarts.

The value is a path to a file that has a private key. The file should include the private key in hex format, similar to 6375297bde61c2e30537d..........4165971cf6698cc8d2ec2a421202b8601.

Nimbus

Verify the Nimbus node starts with the following values :

--discv5=true /

--nat:extip:<PublicIPAddressOfNode> /

--netkey-file=<pathToFile> / <-nimbus will generate key

--direct-peer=/ip4/<IPaddressOfGateway>/tcp/13000/p2p/<GatewayPeerID>

Note: The value --netkey-file will ensure the beacon node peer ID will not change if the nimbus node restarts. This file should have the private key in hex format, similar to:

{"crypto":{"kdf":{"function":"..........b71133496dc1","version":1}

Teku

In order to start a Teku node with a private key, the user must manually create one first. To create a compatible private key:

1. Use teku command to create a new set of public/private keys with - teku peer generate --number=1 --output-file key-details.txt

2. Open key-details.txt and copy the Private Key(Hex) it should look like 0x0802122100de1b920d44aa73a10a ... 0fff3e0b417bb6d3

3. Create a new private key file with echo -n '0x0802122100de1b920d44aa73a10a ... 0fff3e0b417bb6d3' > key.txt <-this ensures there is no EOL included

4. You now have a compatible private key: key.txt

Verify the Teku node starts with the following values:

--p2p-advertised-ip=<IpAddress>

--p2p-private-key-file me/home/key.txt

--p2p-static-peers=/ip4/<IPaddressOfGateway>/tcp/13000/p2p/<GatewayPeerID>

2. Add your Consensus Layer client to the --multiaddr argument

As its name suggests, multiaddr supports multiple addresses. When adding your consensus layer client to this argument, it should look like the below:

/ip4/<IP_address>/tcp/<port>/p2p/<Peer_ID>

3. Add the Gateway peer ID as a trusted peer

Lighthouse

The Lighthouse implementation supports adding beacon nodes as trusted peers by running with --trusted-peers <Gateway peer id> as a parameter.

During the startup process, you can look up the peerID string from the Gateway log by grep-ing for the phrase, “Starting P2P beacon node:”. Below is an example of the log reporting the peer ID.

time="2022-09-14T18:43:25.145480" level=info msg="Starting P2P beacon node: [/ip4/172.17.0.2/tcp/13000 /ip4/<PublicIpAddres>/tcp/13000], peer ID: 16Uiu2HAmM4ZMcMknZMnQQucupVq5TgPG93cbCWjthaX91hkupWg4" connType=beacon

Prysm

The Prysm client doesn't have this 'trusted peer' feature; you may always restart Prysm to clear all peer slots.