Which client holds the state of the chain?

Question

I am interested in a (private) network where multiple consensus client (specifically Prysm clients) are connected to the same execution client (Geth).

Where, in this case, I want to know which chain keep the data finally in some cases or what would happenen with the copies copy in geth's data dir, two copies in each of the Prysm clients' data dirs for example.

It seems that Prysm is responsible for determining the head of the chain and therefore it should be it, and for that reason there are get_block endpoints in the web3.beacon API.

On the other hand, the execution node is the one executing the EVM TXs and therefore is the one holding state of the EVM (and then the chain too). Notwithstanding the web3.beacon's endpoints, web3.eth has always been (even before The Merge) the primary API for chain information, and non of the relevant pages mark it as deprecated or no longer relevant.

This answer argues that it's the execution node's responsibility.

But to be honest, all of this has made me very confused and now I am not certain which is the relevant client. More importantly about what would happen if the Prysm nodes diverge and then hold different heads, is Geth the responsible for storing the chain and information?

Thanks in advance.

Answer 1

Which client holds the state of the chain?

No single client holds the state of the chain.

For example, consensus layer rewards accrue in the validator's balance on the beacon chain, while transaction tips accrue in the fee recipient address on the execution layer.

Source, a developer of Lighthouse client: https://twitter.com/sproulM_/status/1589469129224126464

I run multiple Prysm nodes connected to one, single Geth node. What happens when the Prysm nodes diverge?

Running multiple Prysm nodes connected to one, single Geth node, is an unsupported configuration. A single Prysm node can handle multiple/all validators. If you want to "split", you should run a second EL node for the second Prysm node. In the unsupported configuration, when the CL nodes diverge, the behavior would be undefined/unspecified (and likely lead to loss). Basically, an EL is expected to only have one CL that is telling the EL what to do.

The point of only one CL per EL has perhaps not been widely or clearly written about yet. For now, adding some emphasis to parts from https://blog.ethereum.org/2022/08/24/mainnet-merge-announcement:

"each beacon node must be paired with an execution layer client."

"Note that multiple validators can still be paired to a single beacon node & execution layer client combo." See How many validators can run with single Consensus client?

Answer 2

Nodes in the Ethereum network, by default, communicate using 30303 port. But nodes are also free to listen on some other port numbers. The --datadir option is used to specify where to store the blockchain.

If Geth uses a datadir to store the blockchain, accounts and some additional information, this directory cannot be shared between running instances and this data structure does hold all those information, because it is not included in every BeaconBlock.

However, you can rebuild the BeaconState by re-executing/verifying all the TX included in the BeaconBlocks prior to the one that is currently considered the head of the chain.

The beacon state can be recomputed by public informations present in the blocks.

This basically mean that when you sync to the beacon chain, you rebuild the BeaconState, exactly the same as in the case of syncing on 'Ethereum 1.0 means rebuilding the 'Ethereum 1.0 global state'.

The jwtsecret file is required to create an authenticated connection between Geth and a consensus client. JWT stands for JSON Web Token and it is signed using a secret key. The signed token acts as a shared secret used to check that information is sent to and received from the correct peer, and everything precisely about API usage.

The Merge responsibility for consensus logic and block propagation were handed over to the consensus layer, but all of Geth’s other functionality remains intact (transactions, contract deployments and data queries can still be handled by Geth using the same methods as before).

This includes interacting with Geth via JSON_RPC_API directly using tools such as curl, third party libraries such as Web3.js and Web3.py in development frameworks, Truffle, Hardhat, Brownie, Foundry or using Web3.js in Geth’s built-in Javascript console.

Obviously you can dive deeper about Slots and Epochs and how to run multiple instances finding more details in the documentation geth.ethereum.org or ethereum developer docs.

About your comment, this behavior is unacceptable because it would allow a perpetrator to re-spend coins that have already been spent, a process commonly known as double spending.

The major reason this doesn’t happen or rather happens rarely, it is consensus rules and consensus mechanism. If full nodes start validating false transactions and passing around invalid blocks, they will be banned by other nodes (the banning process is usually automatized).

Since blockchain operates on a trustless basis, each node must reach conclusions on the validity of transactions and blocks on its own. This way, when the results are compared, unreliable nodes are quickly weeded out.

Answer 3

How about the case where a staker has a master (EC+BC+VC) and backup (EC+BC) setup where two computers are running their own EC and BC connecting on localhost? Can one stop the BC on the backup machine temporarily, point the master machine's BC to the redundant machine's EC, and revert it later back to the previous master / backup configuration without causing data integrity issues? This is what I need to do to prune Geth on my master machine without causing downtime.