Ethereum beacon chain nodes (Lighthouse, Prysm, others) provide Beacon Chain API in the port 5052.
How does one securely expose this API over Internet?
Ethereum beacon chain nodes (Lighthouse, Prysm, others) provide Beacon Chain API in the port 5052.
How does one securely expose this API over Internet?
A beacon chain node port 5052 offers HTTP API with JSON and SSZ payloads.
Any Internet facing port should have some sort of authentication, otherwise you will get a lot of knocking and random traffic. This might not be harmful, but may be annoying and also a denial-of-service attack vector.
You can use your node internal authentication settings to protect the port. But because the traffic is HTTP, you can use any HTTP web server (Caddy, Nginx, Apache, Node.js based, Python based) as a reverse proxy that adds authentication to the traffic.
Here is an example running Lighthouse using Docker and then adding the API authentication using Caddy. We use HTTP Basic Auth which is a basic username/password scheme any web browser and client supports.
We assume you use domain beacon.example.com
that is set point to your Caddy web server.
Example docker-compose.yml section:
version: '3'
services:
#
# Ethereum mainnet geth
#
# https://hub.docker.com/r/ethereum/client-go
# https://githwcat ub.com/Capgemini-AIE/ethereum-docker/blob/master/docker-compose-standalone.yml
#
# Beacon chain node using Lighthouse.
lighthouse:
container_name: lighthouse
image: sigp/lighthouse:v3.3.0
restart: always
# Privleged needed because of how Lighthouse is setting file system permissions.
privileged: true
# Infura is used to bootstrap the sync
# https://ethereum.stackexchange.com/questions/135163/checkpoint-sync-source-for-ethereum-beacon-chain-node/135164#135164
# See .env for infura URL
# TODO: Disabled for now
command: >
lighthouse
--network
mainnet
beacon
--http
--http-address=0.0.0.0
--http-port=5052
--http-allow-origin=*
--execution-endpoint=http://vitalik2.tradingstrategy.ai:8553
--execution-jwt=/jwtsecret
--checkpoint-sync-url=$INFURA_URL
ports:
- 9000:9000/tcp
- 9000:9000/udp
# Expose API port for Caddy to bind on localhost,
# but not for general Internet
- 127.0.0.1:5052:5052
environment:
# Do a full backtrace when lighthouse crashes
- RUST_BACKTRACE=full
volumes:
- ./data/lighthouse:/root/.lighthouse
- ./jwtsecret:/jwtsecret
To see the full Lighthouse command line options you can run docker run sigp/lighthouse:v3.3.0 lighthouse beacon_node --help
.
Caddyfile:
# Beacon chain API exposed from Lighthouse port 5052
beacon.example.com {
# See https://caddyserver.com/docs/caddyfile/directives/basicauth
# how to set the password hash
basicauth {
user xxxxxxxxxx
}
# Upstream to Lighthouse
reverse_proxy 127.0.0.1:5052
# Set the default 404 page
# https://caddyserver.com/docs/caddyfile/directives/handle_errors
handle_errors {
respond "{http.error.status_code} {http.error.status_text}"
}
log {
output file /var/log/caddy/vitalik2-beacon.log
format json
}
}
This example Caddyfile does not discuss how to terminate HTTPS traffic. You can use Caddy with Let's Encrypt or Cloudflare as further security proxy. If your HTTPS is terminated by Cloudflare you need to use configuration http://beacon.example.com {
instead of beacon.example.com
, as otherwise there is a redirect loop.
You can visit beacon.example.com
with your web browser and it should pop up the password dialog:
After setup you can do an API test using curl:
curl -H 'accept: application/json' 'https://user:[email protected]/eth/v1/node/version'
And it replies:
{"data":{"version":"Lighthouse/v3.3.0-bf533c8/x86_64-linux"}}
To get the latest "block" or slot as it is called in the consensus chain you can do:
curl -H 'accept: application/json' 'https://user:[email protected]/eth/v1/node/syncing'