Eth2 is a massive upgrade to the Ethereum blockchain, which will start off as a proof of stake chain that runs in parallel to the current proof of work chain. In order to become a validator in eth2, users have to do a one-way "burn" of their ETH into a smart contract on the proof of work chain. Eth2 beacon nodes will track the eth1 chain's logs to determine deposits and verify those deposits' data to onboard new, proof of stake validators.
As such, running a validator and a beacon node in eth2 entails also having a reliable connection to the eth1 chain. We recommend users to explore their own solutions such as those below:
Supported eth1 clients
Eth2 nodes can use any sort of eth1 mainnet node http endpoint as long as it supports reading smart contract logs. Users can choose either of the following eth1 clients.
Using a third-party eth1 provider
Instead of running your own eth1 node, it is a lot easier to use a third-party provider such as Infura, QuikNode, Chainstack, or Alchemy for this purpose. You can easily sign-up here for free and get an API key which then entitles you to use their respective eth1 endpoints. However, remember that using a third party provider is relying on their services, instead of your own node.
Once you have an API key, you can then run a Prysm eth2 beacon node by pointing the
--http-web3provider flag to your eth1 endpoint. For example, running an eth2 node connected to Infura's eth1 endpoint is as follows:
Running your own eth1 node
You can also run your own eth1 node in the full spirit of decentralization and use that for your eth2 Prysm beacon nodes. We'll be giving an example of running a go-ethereum node on mainnet.
First, install go-ethereum here.
You should wait for your node to sync and then will be able to access its endpoint via
http://localhost:8545 by default.
Next, in a separate terminal window, you can run a Prysm beacon node according to our installation instructions for your operating system:
- Using the Prysm installation script (Recommended)
- Using Docker
- Building from source with Bazel (Advanced)
then connect to your eth1 node with:
Adding fallback eth1 nodes
In case your eth1 node unexpectedly goes down, you can specify a list of fallback eth1 nodes that your beacon node can always reach out to. To use this functionality, you can add the following flag to the beacon node:
Using regular flags
You can specify your main provider and as many --fallback-web3provider as you need. Here's what a real setup could look like:
Where your main provider is your local go-ethereum node running on port 8545, then you can fallback to infura or alchemy as needed.
Prysm will automatically use your main provider always
In case your main provider comes back from the dead, Prysm will detect that and switch over to it for primary usage automatically. This will save you any costs on your fallback providers.
Using a config file
If you are running Prysm and specifying command line flags via a config.yaml file, you can do the following:
Authorizing connection to a third-party eth1 provider
In case you need to authorize to your eth1 node, both
--fallback-web3provider flags support the following HTTP authorization methods:
- Basic Authentication
- Bearer Authentication (Token Authentication)
In order to pass authorization data, append the authorization header to the flag's value, separating the URL and the authorization header with a comma. In the following example:
- the main endpoint is a custom node without authorization
- the first fallback endpoint is a Chainstack endpoint with Basic Authentication
- the second fallback endpoint is an Infura endpoint with Bearer Authentication using a JWT token
Note that you can specify multiple authorization values for the same endpoint by reusing the endpoint URL in
--fallback-web3provider and changing the value of the authorization header.