Smart transactions with gas price ramp-up

[abstractpoint]

Currently specifying gas price and gas limit has many uncertainties. Specifying gas price that is too low results in not mined transaction, while setting price too high rewards miners unnecessarily.

Network congestion can change suddenly, so a transaction submitted with one gas price can suddenly become stuck. Furthermore, in more complex scenarios (ex. MakerDAO loans) when it is necessary to execute a series of transactions one after another, a stuck transaction can result in a failure of the whole sequence from which it is not so easy to automatically recover.

My idea is to be able to give user a choice of how soon do they absolutely require the transaction to be mined by, and what is the maximum they are willing to pay to guarantee it.

This can be done using a ramp up curve. Each transaction can have 2 optional values: maximum gas price, and ramp-up. The transaction starts with a low value, and if it isn't mined it automatically increases in price, all the way until the maximum value. This can happen in steps or more gradually.

I believe this is something that should be built into the core protocol and not be required for Dapps to do manually, this way achieving better developer experience (DX) leading to better UX. Looking forward to hear thoughts from the community.

[maxsam4]

I see two problems with this. First is the consensus between nodes that a transaction has not been mined for X time and hence the gas price should be Y.

Secondly, Miners can opt to include lower pricr transactions in the block so they might come to an agreement to let transactions age and reach highest gas price before mining them.

[abstractpoint]

I think the first problem could be solved by instead opting for #599 As a wallet/dapp developer I can create a transaction batch, that going to expire after certain numbers of blocks. Not sure if this would require "valid_from" as well, as otherwise what prevents miners picking the highest transactions.

[github-actions]

There has been no activity on this issue 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.

[github-actions]

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.