With the merge fast approaching, all beacon chain nodes will need to run their own local execution layer client (e.g. Besu or Geth). For validators who have just been using Infura for eth1 data so far, that means some extra setup and potentially more hardware (mostly disk). To avoid this, some people are considering going the other direction and not running their own beacon node either, just running a validator client against a public beacon node API like Infura. While this is possible, it’s extremely likely to result in reduced rewards for a couple of reasons.

Note: This is about using a third party beacon node. A third party execution layer client doesn’t work at all.

The first reason is simple – a remote beacon node is likely to perform slightly worse because of the latency in making requests from the validator client to the beacon node. The difference isn’t huge but it does add up.

The bigger reason though is that you’re very likely to miss out on the transaction inclusion fees that will be paid to validator’s execution layer accounts when they proposed blocks post-merge. These are the “miner tips” that are currently paid to miners and while block proposals don’t come along often, they do pay particularly well because of these fees.

So why wouldn’t you get these fees? To explain that, we need to understand how the block creation process works post-merge.

There are multiple requests involved in creating a block. First, basically at startup and then every couple of epochs, the validator client sends a call to /eth/v1/validator/prepare_beacon_proposer which tells the beacon node which validators it should expect to produce blocks for and what fee recipient to use for them.

The beacon node then watches for when one of those validators is scheduled to prepare a block and a little before the block’s slot starts, sends a engine_forkChoiceUpdated call to the execution layer client containing the details required for the execution client to begin preparing a block – including the fee recipient to use. The execution client returns a payloadId which the beacon node keeps track of.

Then when the block is actually due to be produced, the validator client sends a request to eth/v2/validator/blocks/:slot asking the beacon node to actually produce the block. The beacon node uses the payload ID it already has from the execution client to request the execution payload, bundles it all up and sends it back to the validator client to sign.

Finally the validator client sends the signed block back to the beacon node to import and publish out onto the libp2p gossip network.

So if I wanted to steal inclusion fees from anyone using a public beacon node, I’d just send regular calls to /eth/v1/validator/prepare_beacon_proposer with every validator ID and specifying my account as the fee recipient. There’s no requirement to prove I have the validator keys because the system is designed around validators running their own beacon node. That makes sense because the job of a validator is to run their own node and independently track and verify the state of the chain. That’s literally what they’re paid to do. It would be reasonably easy to add a requirement to the prepare_beacon_proposer API that the request is signed by the validator key to stop this interference but that would add extra overhead for the majority of validators doing the right thing and running their own node to benefit validators doing the wrong thing and shirking their responsibilities.

If that sounds harsh, remember that Ethereum is not here to make validators rich – quite the opposite, validators are here to provide a service to Ethereum (securing the chain) and are paid appropriately for that service.

There are future plans to further strengthen the requirement for validators to run their own node by introducing proof of execution so validators could potentially be slashed if they don’t run their own execution client to properly validate payloads before attesting to them. Otherwise there’s a potential tragedy of the commons where every validator assumes the other validators are executing payloads and so doesn’t do it themselves. Taken to the extreme payloads may not get validated at all and that would be a major problem for Ethereum security.

So bite the bullet today and get an execution client up and running. While you’re at it, do your bit for client diversity and run something other than Geth – Besu with its new bonsai trees storage is fantastic.