EIP-1559 Go-ethereum implementation

EIPs
,
21

I’m thinking that it might be a good idea to introduce a check for monotonically increasing tx.gasprice in block validation along with this EIP.

While default miner software already orders the transactions of a block according to their gas price, there doesn’t seem to be any checks that miners running custom software adhere to this rule.

The assumption that higher gas price transactions will be executed before low gas price transactions is widespread in developing and interacting with contracts and is the default behaviour of client software. I don’t see any reason it why miners should be given the capability to order transactions as they see fit.

Transaction ordering is a highly sensitive matter, as demonstrated in Flash Boys 2.0 by Phil Daian et. al and I think we should limit miner privileges where we can. I think enforcing tx ordering by gas price would definitely increase the predictability of outcomes here.

1 Like
22

@MrChico thank you for bringing this up! My initial reaction is that this should be a separate EIP because while EIP1559 potentially exasperates this issue (I’ll get to that at the end) it’s not specific to EIP1559.

There are a few reasons why that assumption is already not safe to make even with standard miners/clients. I apologize and please correct me if I am wrong on any of these points or if I misunderstood you.

  1. Parity has a CLI flag --tx-queue-strategy that lets you customize how your miner prioritizes transactions (this might be for the miner pool only with standard sorting still done before committing, I’m not super familiar with Parity)

  2. Geth sorts and commits local and remote transactions separately, it commits all local transactions before moving to the remotes

  3. Within the local and remote batches the transactions are sorted by nonce and gas price, with nonce taking precedence. More specifically, in NewTransactionsByPriceAndNonce we iterate through a map of addresses to nonce-sorted transactions, taking only the lowest-nonce transaction for each address and adding it to a heap which is sorted by gas price. Transactions are read from the heap here and after they are committed they are replaced with the next lowest nonce transaction for that account and the heap is re-sorted.

E.g. let’s say we have 2 remote accounts A and B

A has three transactions with nonce n and gas price p: A(n:0, p:100), A(n:1, p:200), A(n:2, p:100)
B has three transactions: B(n:0, p:200), B(n:1, p:50), B(n:2, p:400)

And one local account C with a single tx: C(n:0, p:50)

The final ordering (as I understand it) will be: C(n:0, p:50), B(n:0, p:200), A(n:0, p:100), A(n:1, p:200), A(n:2, p:100), B(n:1, p:50), B(n:2, p:400)

As for how EIP1559 relates to this all…

This implementation currently retains the above ordering of transactions using either legacy or EIP1559 gas price. During the transition period during which both legacy and EIP1559 transactions are accepted, since EIP1559_GASPRICE = min(BASE_FEE + GAS_PREMIUM, FEE_CAP) and the BASE_FEE is always burned a miner will be rewarded more for a LEGACY_GASPRICE where LEGACY_GASPRICE < EIP1559_GASPRICE so long as LEGACY_GASPRICE > GAS_PREMIUM or LEGACY_GASPRICE > FEE_CAP - BASE_FEE if FEE_CAP < BASE_FEE + GAS_PREMIUM.

We can prescribe a new ordering based on LEGACY_GASPRICE and GAS_PREMIUM or FEE_CAP - BASE_FEE instead, that would remove the new incentive but then the standard itself would no longer be to order by gas price as it does now. The other way would be what you recommend and include tx ordering under consensus :slight_smile:

Curious what other people’s thoughts are. I can bring this up at the Core Dev’s call this Friday.