execution-apis VS besu

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

Daily Goerli: I've been testing this PR for besu for the past several days, and the stability of nimbus-besu has improved substantially. Looking forward to it getting merged into main.

Check out the Layered TX pool PR for more details and benchmarks - https://github.com/hyperledger/besu/pull/5290

you can check this spreadsheet for a comparison https://github.com/hyperledger/besu/files/11137473/Layered.Transaction.Pool.metrics.ods

Yes, it's gotten better. I don't recommend pairing with nimbus until this issue gets fixed or prysm until something is done to reduce the amount of time it takes to recover from being offline for a day or more.

Daily Goerli: On Friday, I reported a RocksDB issue that was causing besu to error and exit immediately. The bad commit has been identified and a fix has been issued. lodestar-nethermind somehow ended up on an invalid fork which isn't resolved by restarting either client. Waiting to see how each client team responds and if they need more info, but might need to do a resync.

https://github.com/hyperledger/besu 148 contributors

Download links and release notes here: https://github.com/hyperledger/besu/releases/tag/23.1.2

Now running into this error on my freshly synced Besu 23.1.0. 😔️