A sizeable number of home / solo stakers are using Infura execution client (“eth1”) right now, either as their only execution client or as fallback. A smaller number are using the Infura consensus client (“eth2”, “beacon”).
The merge fundamentally changes what the execution client needs to do. “Proof of Custody” means that the execution client has to be under the control of the consensus/validator client. In addition, priority fees get paid out by the execution client, and there’s the question of MEV.
Is there anything Infura can share yet about plans post-merge?
Execution client suitable for PoC - I am assuming “no”. I don’t see a way to share the access across multiple users, and offering a dedicated client is so niche it likely doesn’t fall into your business model. Also quite expensive, it’d be easier to just rent IaaS and run it there, for users.
Consensus client (with execution client behind) suitable for connection by validator client, like the beta offering now: I can see that. In that case, however, how are priority fees and MEV on block proposal going to be handled? This may again not be core to Infura’s business model and fall away - it’d be cool to know.
RPC connection: Core to Infura’s business, and no changes there. This would work exactly the way it does now, just that the execution client (Geth) that offers the service would now be “docked” to a consensus client behind the scenes. Presumably Teku.
Thank you for sharing this information with our Infura community. We are more than happy to answer these questions. I’ve raised this with our technical team and I kindly ask you to share with me your email address.
Thank you for your time. I hope to hear from you soon.
@Flaveeu I am keen to discuss this because I am a community-minded person. For my own use, I am running redundant execution and consensus clients, but I am also an active member of the eth-staker community and care about home stakers.
As a Lighthouse dev (and Discord admin ) I am also curious.
Proof of custody won’t be part of the initial merge fork, so I imagine it would be possible for Infura to continue providing load-balanced execution clients if some engineering work is done to make the engine API safe for use by multiple consensus clients. As far as I understand this would require carefully controlling the engine_forkchoiceUpdated RPC so that the EE can return payloads even if it doesn’t write the caller’s fork choice updates.
I can imagine a system where Infura maintains multiple canonical consensus clients behind the scenes paired to their execution engines, and then routes engine_forkchoiceUpdated to an appropriate engine with matching ForkchoiceStateV1. If no EE is already matching due to a write from one of the canonical CEs, then an error could be returned.
Have you started investigating this sort of approach @Flaveeu? I know it’s still early days and I understand if you don’t want to comment prematurely, but it would be great to get an update on this
So we had the call with Infura and Tim Beiko joined as well. What the discussion landed on was that Infura would not offer an Engine API, because they aren’t in the mining business now, and don’t want to be in the block production business come merge. Their business is query.
If that holds, and I see no reason it wouldn’t, then node operators will need to run their own CL/EL.
) I am also curious.