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_blockendpoints 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.
Best Answer
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?