Skip to main content

Configure for The Merge

DEPRECATION NOTICE: Ethereum is post merge, use our quickstart guide.

The contents of this document was to help validators using pre-Merge configuration to migrate post merge. This is no longer required as Etheruem is already post merge. see our Quickstart going forward.

Select a configuration​

Merge preparation checklist​

Prysm v5.1.2 supports post-Merge configuration.

If you've ever set the USE_PRYSM_VERSION environment variable to use a release candidate, either clear it via UNSET USE_PRYSM_VERSION (Linux/MacOS) or set USE_PRYSM_VERSION= (Windows).

Verify that you're running Prysm v5.1.2 by issuing the following command: prysm.sh beacon-chain --version (Linux) prysm.bat beacon-chain --version (Windows).

The Before and now section below gives you a high-level comparison between pre-Merge and post-Merge configuration. See the Ethereum.org Merge announcement and Merge readiness checklist for more detailed information.

Review the post-Merge system requirements section below. Note that a 2TB+ SSD is highly recommended.

Use geth version to check Geth's version. See Geth's releases page and join their Discord to stay up to date as we approach Mainnet Merge.

Geth 1.10.22 contains a regression. Update to v1.10.23+ if you haven't already.

If you're not using IPC to connect your beacon node and execution node, ensure that both your execution node and beacon node are configured to use JWT authentication. These instructions are included below, and are also available here: Configure JWT

If you're not using IPC to connect your beacon node and execution node, your beacon node will need to connect to its execution node on port 8551. Previously, port 8545 was used. If your beacon node and execution node are on different host machines, ensure that your firewall rules are updated accordingly, and refer to Configure ports and firewalls for improved network connectivity for general connectivity improvement tips.

If you're running a validator, configuring a fee recipient address will allow you to earn what were previously miners' transaction fee tips. Instructions are provided below, and also here: Configure a Fee Recipient address.

See Check node and validator status to learn how to check the status of your execution node, beacon node, and validator node.

The Merge: Before and now​

BeforeNow
You don't need to run a local execution client. You can use a service like Infura instead.You do need to run an execution client. You can't use Infura as an execution endpoint provider.
The HTTP connection between beacon node and execution node doesn't need to be authenticated using a JWT token.The HTTP connection between beacon node and execution node does need to be authenticated using a JWT token.
Beacon nodes connect to execution nodes on port 8545 by default when using HTTP.Beacon nodes connect to execution nodes on port 8551 by default when using HTTP.
Miners receive transaction fee tips.Validators receive transaction fee tips. The "fee" is now a base fee that's burned - block producers earn only transaction fee tips.
A fee recipient address does not need to be specified.A fee recipient address does need to be specified.
A 1TB hard drive is enough.A 2TB+ SSD is highly recommended.

Post-Merge system requirements​

TypeBenefitsRequirements
Execution + Beacon
  • Contributes to the security of Ethereum's ecosystem.
  • Lets you access the Ethereum network directly without having to trust a third party service.
  • Software: Execution node client, beacon node client (instructions for clients below), curl
  • OS: 64-bit Linux, Mac OS X 10.14+, Windows 10+ 64-bit
  • CPU: 4+ cores @ 2.8+ GHz
  • Memory: 16GB+ RAM
  • Storage: SSD with at least 2TB free space
  • Network: 8 MBit/sec broadband
Validator
  • Lets you stake ETH, propose + validate blocks, earn staking rewards + transaction fee tips.
  • Everything above, plus...
  • Software: Validator client, browser-based crypto wallet (instructions below)
  • Hardware: (Recommended) A new machine that has never been connected to the internet that you can use to securely generate your mnemonic phrase and keypair
  • 32 ETH (Mainnet)
  • 32 testnet ETH (Testnets)

Best practices​

Configure JWT authentication

The HTTP connection between your beacon node and execution node needs to be authenticated using a JWT token. There are several ways to generate this JWT token:

  • Use a utility like OpenSSL to create the token via command: openssl rand -hex 32 | tr -d "\n" > "jwt.hex".
  • Use an execution client to generate the jwt.hex file.
  • Use Prysm to generate the jwt.hex file:

Optional - This command is necessary only if you've previously configured USE_PRYSM_VERSION​

export USE_PRYSM_VERSION=v5.1.2

Required​

./prysm.sh beacon-chain generate-auth-secret

Prysm will output a jwt.hex file path.

Move your jwt.hex file in your ethereum directory:

📂ethereum
┣ 📂consensus
┣ 📂execution
┣ 📄jwt.hex
caution

Ensure that the script, user, or terminal window used to create and access your JWT token has the permissions it needs. Windows users may need to run command windows as Administrator.

Configure an execution node​

Your execution node needs to expose a new port and then use the JWT token to authenticate your beacon node's connection to that port.

Using the latest version of your execution client software, issue the following command to configure your execution node's JWT token and Engine API endpoint:

Download and run the latest 64-bit stable release of Geth for your operating system from the Geth downloads page.

Move the geth executable into your execution directory.

Navigate to your execution directory and run the following command to start your execution node by replacing <PATH_TO_JWT_FILE> by the path to the JWT file generated during the previous step:

./geth --mainnet --http --http.api eth,net,engine,admin --authrpc.jwtsecret=<PATH_TO_JWT_FILE>

The execution layer client cannot sync without an attached beacon node. We'll see how to setup a beacon node in the next step.

Configure beacon node​

Next, we'll configure your beacon node to consume your JWT token so it can form an authenticated HTTP connection with your execution node.

In this step, you'll run a beacon node using Prysm.

There is two main ways to sync a beacon node: from genesis, and from a checkpoint. It is safer and a considerably faster to sync from a checkpoint. When syncing from a checkpoint, the simplest is to connect to a checkpoint sync endpoint. A non exhaustive list of checkpoint sync endpoints is available.

In the following examples, we'll use the checkpoint sync endpoint provided by beaconstate.info. Feel free to use the one you want.

Navigate to your consensus directory and run the following command to start your beacon node that connects to your local execution node by replacing <PATH_TO_JWT_FILE> by the path to the JWT file generated during the previous step:

./prysm.sh beacon-chain --execution-endpoint=http://localhost:8551 --mainnet --jwt-secret=<PATH_TO_JWT_FILE> --checkpoint-sync-url=https://beaconstate.info --genesis-beacon-api-url=https://beaconstate.info

Syncing from a checkpoint usually takes a couple of minutes. See Sync from a checkpoint for more information about this feature.

If you wish to sync from genesis, you need to remove --checkpoint-sync-url and --genesis-beacon-api-url flags from the previous command. Syncing from genesis usually takes a couple days, but it can take longer depending on your network and hardware specs.

If you are planning to run a validator, it is strongly advised to use the --suggested-fee-recipient=<WALLET ADDRESS> option. When your validator proposes a block, it will allow you to earn block priority fees, also sometimes called "tips".

Congratulations - you’re now running a full Ethereum node. To check the status of your node, visit Check node and validator status.

Configure validator node​

Verify that your beacon node and execution node are both fully synced. If you're not fully synced, you risk being penalized and losing some of your staked ETH.

Other than ensuring that you're using the latest stable Prysm release, validator client configuration doesn't need to be updated for The Merge. A fee recipient address can optionally be configured on your validator node if you want redundancy or multiple fee recipient addresses. See Configure a Fee Recipient address to learn more.

Ensure that you're not running multiple instances of the same validator public key, especially if you're using scripts or other forms of automation. If the Ethereum network detects two instances of the same validator key submitting proposals, attestations, or votes, it may assume malicious intent and slash accordingly.

Congratulations!

You’re now running a post-Merge configuration. If you have any questions, feel free ask them on our Discord.

Frequently asked questions​

I'm currently running a validator on Ethereum Mainnet. When should I make changes?
You should make these changes now, regardless of the network you're running on.

Can I use IPC post-Merge?
Yes. You also won't have to worry about JWT if you use IPC. See our Quickstart for IPC instructions.

Can I use a light node with Prysm, or do I need to run a full execution node?
No - at this time, a full node is required.