So here is another digestible and useful bit of information relating to the merge, that uses the latest language the Ethereum core dev team are using.
If you have any questions or want more information on what is below, please feel free to reach out to me. Or if you challenge if this is useful information that feedback is also welcome.
What is the Inclusion Fee or Priority Fee?
These are “miner tips or fees” that are paid to validator’s execution layer accounts when they propose blocks after the merge.
How does the block creation process work post-merge?
There are multiple requests involved in creating a block. At startup and then every couple of epochs, the validator client sends a call to /eth/v1/validator/prepare_beacon_proposer which tells the beacon node which validators it should expect to produce blocks for and what fee recipient to use for them.
The beacon node then watches for when one of those validators is scheduled to prepare a block and a little before the block’s slot starts, sends a engine_forkChoiceUpdated call to the execution layer client containing the details required for the execution client to begin preparing a block – including the fee recipient to use. The execution client returns a payloadId which the beacon node keeps track of.
Then when the block is actually due to be produced, the validator client sends a request to eth/v2/validator/blocks/:slot asking the beacon node to actually produce the block. The beacon node uses the payload ID it already has from the execution client to request the execution payload, bundles it all up and sends it back to the validator client to sign.
Finally the validator client sends the signed block back to the beacon node to import and publish out onto the libp2p gossip network.
Who will Collect the Inclusion Fee?
Today and everyday before the merge, miners collect the transactions fees when they propose a block. After the merge validator nodes and their operators will replace the miners in collecting these transaction fees. This means increased rewards for those people who are actually running their own nodes like all Launchnodes customers, as now validators will be responsible for proposing blocks.
To earn this additional reward in the way Launchnodes customers do, you will have to run your own local execution layer client for example geth. You will also need to specify a “fee recipient” which is basically any ETH address you choose.
Note re not getting too excited too quickly:This is all currently being tested/implemented and as development finalises prior to the merge there will be documentation/announcements in the prysm discord channel for what you will have to do in order to make sure your validator is collecting these transactions fees.
For all Launchnodes customers we will hold your hand to whatever level you need us to, to support you maximising your inclusion fees and making sure you get them. We do not take any of your inclusion fees and our view is that nor should any other staking provider.
Can we run one execution client and connect multiple Beacon nodes to it after the merge?
Sadly we don’t know yet, it’s being worked on. As soon as we do, we will write an explainer.
Using Launchnodes products you will be able to build staking infrastructures with Validaor & Beacon nodes and the execution layer client that you own that run in your AWS or Azure account which are truly independent and that reflect isolation and redundancy levels that you/institutions choose and are in complete control of.
Happy staking, folks!
Visit our AWS page to get started!