We want to introduce the EIP to apply coinbase rewards at the end of the block.
Abstract:
The proposal suggests that instead of applying transaction fees to the coinbase account’s balance after each transaction, they should be added cumulatively at the end of the block.
Why this change?
The current mechanism introduces a subtle dependency between transactions within a block. By shifting the transaction reward to the end of the block, we can potentially allow for new and simpler abstractions around the parallel execution of transactions without having to handle the edge case of coinbase balance read within the block.
Implications and Considerations:
This change will have implications for block builders and transaction bundles. For instance, block builders must accumulate transaction fees when evaluating block value. Additionally, this EIP imposes a balance requirement on the builders to be able to pay for the built block in advance, before receiving the coinbase rewards. All implications have been outlined in the Backwards Compatibility and Security Considerations sections of the EIP.
I would like to see quantified how much of a difference this makes.
If the coinbase is an EOA, how often are transactions created or considered to be created when that EOA would show up in the same transaction
If the coinbase is a contract, how often is the contract called within the same block it receives fees?
for both of the above, how often do the fees received within the block make a difference?
Corollary, block building logic could act today as if this EIP were implemented and still produce valid blocks correct? Or are there occasion where the specific balance is queried and flushed out?
How much of this would influence future block builders if they couldn’t rely on fees being passed in immediately?
Couldn’t block builders just track balance deltas within the transactions they are making and assert sufficient balance while the TXes are assembled?
Clearly based on these questions I am skeptical. Furthermore, code would need to be written to handle both post tx and post block handling within the client software for as long as we want to re-execute previous blocks, so for some clients effectively forever. I would want to see a meaningful improvement to the ecosystem before such complexity is imposed. I don’t see this change in isolation being useful for anything beyond block builders and I don’t think the impact there is sufficient to change the downstream complexity. I may be wrong on this, which is where quantifying where it impacts or outlining other scenarios where it becomes valuable would be useful
@shemnon thanks for your feedback! All of your questions are valid and must be answered before proceeding with this EIP. collecting metrics for the first two questions will take some time. meanwhile, I will provide any immediate answers below.
Regarding block builders that participate in MEV boost auction, based on the available open-source implementations, I can say that the only required change is a modification to the calculation of the block value. I cannot answer for all MEV boost block builders due to the closed source code.
The impact was exhaustively described in the Block Building section under Security Considerations.
Correct, I believe that’s what most builders do today. The balance requirement only impacts the highest bid they can place in the auction.
Agree, the same as with most changes in the behavior of the protocol. Without arguing the complexity of keeping the client codebases backwards compatible, I would say that the implementation of this change and support of pre-EIP behavior is low effort.
A security consideration is not a motivation or rationale. Security considerations are what will/may happen if the EIP is adopted. Security considerations also describe bad things that may happen, and motivation as bad things that are happening that would be fixed. So I am quite confused by this analysis of the impact.
I also fail to see how this addresses the problem of builders with larger balance. The extra incremental Ether available to smaller and “honest” block builders is still available to larger (and presumably dishonest?) miners. Nothing about moving where the balance is accounted for alters this appeal against plutocracy as it is equally accessible regardless of balance, the builder would just need to adapt to the new accounting standard.
Absolutely agree. The Security Considerations section outlines the consequences (both intended and unintended) to various areas of the protocol as well as important protocol counterparts (MEV Boost in this case). This EIP is not different in that regard.
The EIP does not address the problem but rather introduces it in the context of MEV Boost auctions. Hence it is described under Security Considerations section. As an unintended consequence of EIP being adopted, the extra incremental Ether becomes unavailable to either of the builders.
Respectfully, I think some parts of the EIP or its impact on the builder market have been misunderstood, so I would be glad to answer any requests for clarifications you have regarding the EIP and modify the original proposal to reflect that.