FYI this was mentioned in EIP-2929: Gas cost increases for state access opcodes - #52 by axic and @holiman answered it with EIP-2929: Gas cost increases for state access opcodes - #55 by holiman.

I agree that it was an oversight. I don’t think it provides meaningful simplification.

The status quo also incentivizes me to sign a different transaction per miner, which favors the top miners at the expense of smaller miners.

COINBASE transfers are overpriced because the access list is not initialized with COINBASE. We already include ORIGIN, recipient, and the set of all pre-compiles, but not COINBASE. The proposal is to include COINBASE.

The main impact of a Warm COINBASE would be for transactions that pay miners conditionally. Such transactions specify a minimal gas price but pay the COINBASE a much larger fee if some conditions are met. Among other things, this flexibility allows users to avoid paying for transactions that would revert, and specialized systems have been developed to process such transactions outside of the mempool. The first and most popular such system is Flashbots, which is available to the public, but there are others, and several apps are building on top of it. The main benefit so far of the advent of these systems has been an end to the chaotic priority gas auctions and backrunning spam that clogged the network last year. Most blocks this year have had at least one COINBASE transfer, while many have 2 or 3, and some have more. Their frequency has been increasing steadily over time.

Block validators should have the COINBASE account loaded already in order to update its balance with the block rewards, and these increasingly frequent conditional payments justify automatic inclusion into the default access list. If gas should reflect the burden of validation, COINBASE transfers are overpriced, and this proposal should be an easy fix.

How does this effect the cost of coinbase transfer when the coinbase address is a contract?


block.coinbase.call{value: _ethAmountToCoinbase}(new bytes(0));

Doesn’t matter if recipient is a contract. The first call to coinbase in a transaction will be cheaper.

1 Like

This is slated to be included in Shanghai, execution-specs/shanghai.md at master · ethereum/execution-specs · GitHub

1 Like

Hi @wjmelements thank you for this EIP. Look forward to its improvement to gas and chain efficiency.

Just to clarify, IIRC clients before and after this EIP calculated gas cost differently assuming all clients shall by default treat coinbase as cold, right?

If that’s correct understanding, could you

  1. Describe the differences of gas cost before and after
  2. Clarify if this EIP requires a hard-fork. My understanding is it does, and if so please consider add some wording like “Upon FORK_BLKNUM”

If my understanding is incorrect, please help me understand better.

The EIP intentionally does not specify any difference in gas.

All Core EIPs require a hard fork. The specification of when the hard fork happens is outside the scope of the EIP.
From EIP-1:

  - **Core**: improvements requiring a consensus fork (e.g. [EIP-5](./eip-5.md), [EIP-101](./eip-101.md)), as well as changes that are not necessarily consensus critical but may be relevant to [“core dev” discussions](https://github.com/ethereum/pm) (for example, [EIP-90], and the miner/node strategy changes 2, 3, and 4 of [EIP-86](./eip-86.md)).

Core EIPs don’t do that boilerplate anymore. It was never necessary or helpful.

1 Like

An overview of EIP-3651 by @wjmelements in PEEPanEIP #92: EIP-3651: Warm COINBASE with William Morriss