As an Execution-Layer (EL) client, Geth supports the transition of Ethereum from proof-of-work (PoW) to proof-of-stake (PoS), a.k.a. The Merge.
What happens to Geth?
The merge changes Ethereum’s PoW consensus mechanism to PoS. At the moment of the merge, Geth switches off its mining algorithm and block gossip functions. Geth’s role after the merge is executing transactions and generating execution payloads using the EVM.
From a user’s perspective Geth will not change much at the merge. Responsibility for consensus logic and block propagation are handed over to the consensus layer, but all of Geth’s other functionality remains intact. This means transactions, contract deployments and data queries can still be handled by Geth using the same methods as before.
The transition from PoW to PoS will happen when a pre-announced total difficulty is reached by the chain. This is unlike usual forks which occur at a certain scheduled block number.
The total difficulty threshold that triggers the Merge is also known as the Terminal
Total Difficulty (TTD). In
case of an emergency delay, the TTD can be overriden using the
In advance of the Mainnet merge, several public testnets will transition from PoW to PoS. The first public testnet to merge will be Ropsten. As the Ropsten merge approaches, Geth users will need to prepare to ensure a smooth transition.
--override.terminaltotaldifficulty 50000000000000000when launching Geth for Ropsten.
After the merge, Geth will no longer be able to follow the head of the chain unless it is connected to a second piece of software known as a “consensus client” which handles all of Ethereum’s consensus logic.
The consensus client communicates with Geth using the
engine API over a local RPC connection. The consensus client
is responsible for gossiping blocks, block proposal, attestation and fork choice.
Geth must be connected to a consensus client in advance of the merge so that the two pieces of software can get in sync and transition smoothly by coordinating together. There are several choices of consensus client implementations.
Note that CL clients are equipped with two modes. One for following the beacon chain (Beacon node), and another mode used for validators. It is NOT required to run a validator or stake 32 ETH in order to follow the chain!
EL - CL communication
ELs and CLs communicate using a JSON-RPC API under the namespace
engine which is exposed by Geth.
engine API is authenticated via JWT. If a TTD is set for the given network, as is the
case for Ropsten, Geth will:
Generate a JWT secret under the path
<datadir>/geth/jwtsecret. This secret is needed both by Geth and the CL client.
Open HTTP and WS endpoints on the authenticated port 8551.
This is what it looks like by default:
geth --ropsten --datadir ~/.ropsten --override.terminaltotaldifficulty 50000000000000000
INFO [05-25|11:04:41.179] Starting Geth on Ropsten testnet... ... WARN [05-25|11:04:41.520] Catalyst mode enabled protocol=eth INFO [05-25|11:04:41.627] Generated JWT secret path=/home/user/.ropsten/geth/jwtsecret INFO [05-25|11:04:41.628] WebSocket enabled url=ws://127.0.0.1:8551 INFO [05-25|11:04:41.628] HTTP server started endpoint=127.0.0.1:8551 auth=true prefix= cors=localhost vhosts=localhost
Engine API Authentication
The listening address of the engine API is configurable. It is also possible to self-generate the JWT secret and feed the resulting file to Geth. To generate the secret, run:
openssl rand -hex 32 | tr -d "\n" > "/tmp/jwtsecret"
Now configure authentication using Geth flags:
geth --ropsten --datadir ~/.ropsten --authrpc.addr localhost --authrpc.port 8551 --authrpc.vhosts localhost --authrpc.jwtsecret /tmp/jwtsecret --override.terminaltotaldifficulty 50000000000000000