eth2-ubuntu VS execution-apis

I followed Metanull's guide: https://github.com/metanull-operator/eth2-ubuntu/blob/master/v2/setup.md

- I guess for setting up the ETH node itself there are plenty of guides out there, can you recommend one? This is the one i have used and has been working without issues for over a year: https://github.com/metanull-operator/eth2-ubuntu

I follow this guide. I didn't get any errors. I'm double checking now to see if I messed up a config file. https://github.com/metanull-operator/eth2-ubuntu/blob/master/kiln.md

Devs agreed to make minor changes to execution api specifications so that users can retrieve blob gas price data. https://github.com/ethereum/execution-apis/pull/486

With this knowledge we only need to figure out how to read the value from the deployed contract. There is a JSON-RPC API implemented in each Ethereum node in order for applications to interact with Ethereum, more about the API can be found here. Thankfully we have access to the web3js library on the web application which enables us to use this API.

The clients are already built to conform to the execution API spec and beacon API spec, so building tools to interact with them is already client-agnostic to a great degree. If I add a custom ETH mainnet endpoint to Metamask, it doesn't care what client is providing the endpoint - only that it conforms to the spec.

The problem isn't about the execution client being able to see the reward value, it can. The problem is that it has no way of reporting it and so neither validator nor mev software can make any comparisons and "pick the bigger local block". This is still an open issue https://github.com/ethereum/execution-apis/issues/307

Correct, this would require a spec change. That discussion is here: https://github.com/ethereum/execution-apis/issues/307

Is this the API?

People who are smarter than me read the specs and dumbed it down for me lol. In this case it's all about the engine API for CL<->EL interop

After the merge, when it's time for a beacon client to produce a block, it will ask its execution client to build a block with certain characteristics. The communication between the two clients is defined by the Engine API. With this, the beacon client will notify the execution client that a certain execution layer payload was accepted by the beacon chain forkchoice rule via engine_forkchoiceUpdateV1, and it will include an additional parameter to the call PayloadAttributesV1 which will alert the execution client that it is about to propose a block and needs an execution payload to be built. In that extra parameter is a field suggestedFeeRecipient. This will be an execution layer address which will receive the priority fees from the block. The reason it is "suggested" is that it leaves open a design space for proposer-builder separation where it is not known who will actually construct the block that the execution client responds with.

Infura will probably not offer the Engine API required after the merge. See https://community.infura.io/t/infura-post-merge-from-a-staker-perspective/3889/6