Transaction deadlines and increasing gas prices for more efficient auctions

[moodysalem]

Summary

Allow user to be more expressive in setting the gas price they wish to pay for a transaction. This makes the auction for block space much more efficient, and will reduce overall gas paid by users. It also improves the user experience in high congestion scenarios.

Background

Currently we have a problem where network congestion makes it difficult for users to understand what gas price to set. Often they have to set an exorbitant gas price in these situations to make sure their transaction gets through in a reasonable amount of time, without having to sign an additional transaction with a higher gas price. Then they have to wait an arbitrary amount of time for their transaction to be included in the block, never knowing when it is dropped from the mempool or whether it's safe to retry the transaction.

Solution

To solve this, it would be advantageous if the user could specify a starting gas price, a min timestamp (or block number) for inclusion, a max timestamp (or block number) for inclusion, and a maximum gas price. The transaction would not be included unless the block timestamp (or block number) is between the min and max timestamp, and the gas price paid would be the the linear price, or some other curve, between the min and max timestamp. Linear is suggested in first implementation, but perhaps this logic could be customized into reusable a smart contract with an interface as such:

function getGasPrice(
  uint256 start_timestamp,
  uint256 end_timestamp,
  uint256 min_price,
  uint256 max_price) returns (uint256 gas_price);

When the transaction is included in the block, the gas price is determined by the block number/block timestamp (depending on the mechanism). Timestamp is more usable than block number, but block number is more specific and may interface better with other mechanisms.

The primary reason for the 'expiration timestamp' is to define the slope of the ramp up in gas price. Miners can prune these transactions from the mempool after the expiration timestamp. This also has the added benefit of allowing a user to know definitively when a transaction will never be included in a block (barring a re-org). Clients can more easily define logic about when a transaction should be attempted a second time.

A pseudo-transaction with these additional fields may look like such:

{
  "from": "0x...",
  "to": "0x...",
  "data": "0x...",
  "minGasPrice": "10 GWEI",
  "maxGasPrice": "100 GWEI",
  "minTimestamp": "*now*", 
  "maxTimestamp": "*now* + 10 minutes"
}

If the transaction is included at *now* + 5 minutes then the gas price paid is halfway between 10GWEI and 100GWEI or 55GWEI.

The current transaction blob is equivalent to setting the min price to the max price and omitting the start/end timestamps, and so the current transaction structure is backwards compatible with this one. This requires a hard fork though because this new format of transactions will not be compatible with a previous version.

Miner competition

Miners have incentive to include transactions earlier as soon as they exceed a threshold gas price, as they as they do not want other miners to include the transaction and collect a higher gas price. It naively seems the best approach for a miner is to sort all the transactions in the mempool by the gas price at the current block timestamp, and include them in that order.

Open Questions

One complication is miners have to constantly reevaluate the priority of transactions by their changing gas prices. This may add some CPU complexity to constructing a block. However in mining pools this work is mostly centralized.

Other work

Similar to #1441

[moodysalem]

Ah, I've literally just seen this #2593