Gas price market change: Escalator Algorithm (alternative to 1559)

[danfinlay]

Submitting a draft of a version of the escalator algorithm applied to the Ethereum network, which I suspect has superior qualities to EIP-1559 in several regards.

Opening this PR so that the algorithms can more easily be compared side by side.

Full text available for easy reading here:
https://github.com/danfinlay/EIPs/blob/Escalator/EIPS/eip-x.md

You can read some previous discussion on it here:
https://ethresear.ch/t/another-simple-gas-fee-model-the-escalator-algorithm-from-the-agoric-papers/6399

[moodysalem]

Suggest this could be a smart contract that implements this function in the future, but by default linear?

[danfinlay]

That could be, I looked at some other EIPs and it seemed like pseudocode is fairly common for layer-1 proposals, but I'd gladly add specificity anywhere it's lacking.

[moodysalem]

Just to clarify, I mean that the EIP could specify that a linear 'escalator' algorithm is just one of a number of gas price functions, which could be implemented as smart contracts and then specified by the user in the transaction as an address, gasPriceContractAddress. E.g. the specified contract could produce gas prices as a step function, or decreasing gas prices to encourage immediate inclusion. This may be way out of scope for this EIP though, but just worth mentioning as a hint towards the extensibility of this feature

[MicahZoltu]

In order to prevent DoS attacks against the network, nodes need to be able to very quickly check to see if the caller can afford to submit the transaction, before executing arbitrary user-provided code. This ensures that someone can't waste node resources by submitting transactions to the network that are invalid.

[moodysalem]

I think the DoS consideration is fair, but there is an obvious solution: limit how much gas the computation requires and make it pure. You still have to look up the code, but that can be easily memoized.

[moodysalem]

The ideal behavior imo is that the transaction cannot be included after the MAX_BLOCK

[MicahZoltu]

Hmm, this wording conflicts with the wording above on MAX_BLOCK. I disagree with @moodysalem here and think that the ideal behavior (if we have to choose between two options) is to have it sit at MAX_PRICE forever once MAX_BLOCK is reached.

[moodysalem]

I see people complain about transactions pending for days, blocking new things they want to do, in basically every dapp's support chat. Cancelling transactions via resubmitting with different gas price is a horrible experience, and has non-deterministic results. If you really want to wait up to 3 days for a transaction, set the MAX_BLOCK to last 3 days.

[MicahZoltu]

The problem is that the fee algorithm is a function of MAX_BLOCK, START_BLOCK, so if you set MAX_BLOCK to 3 days in the future, your fee increase rate is really slow. I would not be opposed to adding yet-another-variable for TERMINATION_BLOCK, so you can escalate up to a target fee over say 5 minutes, but then sit in the pending queue for up to 24 hours at that fee.

In other words, I agree that there is a problem with never-expiring transactions. I just disagree that MAX_BLOCK in this specification is the right place to fix that. In fact, one could create a totally separate EIP that just adds in a NOT_AFTER field to transactions.

[AlexeyAkhunov]

How is the START_BLOCK actually defined? If a transaction could have been valid at block 1000, but it has been created at block 2000, what is the START_BLOCK in such case?

[MicahZoltu]

Similarly, what happens if START_BLOCK is in the future? Can this EIP also solve the problem of delayed transactions?

[AlexeyAkhunov]

My question was basically a hint that START_BLOCK probably cannot be suitably defined (so that it can be efficiently calculated from consensus values, and not just from subjective tx pool timestamps), and this could be the main thing that makes this EIP hard or impossible to implement

[moodysalem]

What do you mean suitably defined? The user or user's wallet specifies the START_BLOCK and MAX_BLOCK in the transaction, just like with gas price and gas limit. If the miner is working on a block with number BLOCK_NUMBER, the block is valid iff all transactions within the block have START_BLOCK <= BLOCK_NUMBER and MAX_BLOCK >= BLOCK_NUMBER

It's very easy for a wallet to set this parameter. Just choose the next block for START_BLOCK and the MAX_BLOCK to whatever delay the user is willing to tolerate divided by the 15 seconds average block times plus the start block.

This constraint can be cheaply validated by any node, and adds some compute time to ordering transactions into a block (must determine the gas price for each transaction for the given block, and whether it can be included) but also has the benefit that transactions can be dropped from the mempool as soon as the block number exceeds MAX_BLOCK by some threshold, and potentially if they are sent with a START_BLOCK too far in the future

[AlexeyAkhunov]

Ok, I misunderstood, now I see that START_BLOCK is suggested to be a new transaction parameter. Thank you

[MicahZoltu]

I'm not a fan of the transaction getting dropped when max-block is reached. In most cases I would want to escalate up to target price and then sit at that target price until mined or cancelled. I can also imagine situations where I want to "mine by this block or give up", so I can appreciate the desire but I don't think it is the common case.

[danfinlay]

Thanks for highlighting this distinction. I think I agree with you as the default case, especially since it resembles current behavior more, but I think there is a use case (for a future EIP, perhaps a new tx type) to allow TXs that become invalid over time or after some conditions. Making this change.

[MicahZoltu]

Consider changing this to START_TIME and MAX_TIME instead. Miners can only fudge the block timestamp a little, and it is very costly for them to fudge the timestamp into the future. Timestamps are much easier for humans, and also much more reliable (block times range from 1 second to 100 seconds) so using block numbers can result in very unexpected (for a human) wait times.

Also, by using timestamps here we will incentivize miners to more accurately set block timestamps than they do now. Right now, many miners set timestamps far (30+ seconds) in the past because there is a very marginal advantage for them to have their clocks be off by a bit. By having this be timestamp based, miners are strongly encouraged to set the timestamp as far forward as they can without risking significant profits. It turns out, that is just about now because they start taking on huge risk by setting block.timestamp to the future. This means that we can kill two birds with one stone with this PR by having gas price (or gas premium) be a function of time instead of block number.

[danfinlay]

This is an interesting point, and I have no objection, so I've made this change. I hope this doesn't greatly complicate any analyses that are currently in progress.

[moodysalem]

START_BLOCK/MAX_BLOCK is inconsistent, prefer MIN_BLOCK/MAX_BLOCK or START_BLOCK/END_BLOCK

[github-actions]

There has been no activity on this pull request for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[MicahZoltu]

I wasn't an editor back when this was proposed and so I never left actual editor feedback to get it merged as a draft.

This needs an EIP number to merge, and we have a new policy about leaving the comments in (it is to remove them) so I added suggestions for that as well. Otherwise, I think we can merge this as draft.

[MicahZoltu]

Good to merge as draft. I'll commit the spelling fix just to speed the process along, if the authors think this is incorrect please open a PR to change it back so we can discuss (we will need to add a custom rule to the bot in such a case).