Note: Validators should not configure connections with the BDN Gateway until they have successfully configured the relay proxy and are explicitly advised to proceed with the BDN Gateway setup.
Last updated
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.
You have two options to connect Gateway with the Consensus Layer:
Initiate connection by the Gateway. The easest way. Recommended to add Gateway as trusted peer if supported, otherwise connection will be not stable.
Initiate connection by the Consensus Layer. This approach recommended for Consensus Layer clients like prysm, nimbus and teku which are not supporting trusteed peers but instead treat outgoing connection as trusted.
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
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 .
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.
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.
Verify Lighthouse has the private key file beacon/network/key within the datadir.
--multiaddr argumentAs its name suggests, multiaddr supports multiple addresses. When adding your consensus layer client to this argument, it should look like the below:
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.
You need to specify --beacon-port flag for the Gateway with any port number you want to use. Make sure this port is opened by firewall and port exposed by the docker.
You can restrict incoming connections by the public key. In order to do this you need create file with public keys on new line each and then use --beacon-trusted-peers-file to specify the file. You can change the file without restart and Gateway would pick up changes. Don't forget to include the file via volumes(-v flag) into the docker container. This option is handy if you want to be 100% sure that no random nodes connected, but in reality since Gateway is not using discovery protocol there is not much chance anybody else will know about your Gateway.
When you starting Gateway you will see something like this in the logs:
You need this public key to add it to the Consensus Layer.
Replace your IP and port and pubkey. If you are running Gateway on same machine with the Consensus layer your IP probably would be 127.0.0.1. Port here is port from the --beacon-port. Peer ID can be taken from the gateway logs.