forked from DecentralizedClimateFoundation/DCIPs
132 lines
15 KiB
Markdown
132 lines
15 KiB
Markdown
---
|
|
eip: 2593
|
|
title: Escalator fee market change for ETH 1.0 chain
|
|
author: Dan Finlay <dan@danfinlay.com>
|
|
discussions-to: https://ethresear.ch/t/another-simple-gas-fee-model-the-escalator-algorithm-from-the-agoric-papers/6399
|
|
status: Stagnant
|
|
type: Standards Track
|
|
category: Core
|
|
created: 2020-03-13
|
|
---
|
|
|
|
## Simple Summary
|
|
The current "first price auction" fee model in Ethereum is inefficient and needlessly costly to users. This EIP proposes a way to replace this with a mechanism that allows dynamically priced transaction fees and efficient transaction price discovery.
|
|
|
|
## Abstract
|
|
|
|
Based on [The Agoric Papers](https://agoric.com/papers/incentive-engineering-for-computational-resource-management/full-text/).
|
|
|
|
Each transaction would have the option of providing parameters that specify an "escalating" bid, creating a time-based auction for validators to include that transaction.
|
|
|
|
This creates highly efficient price discovery, where the price will always immediately fall to the highest bid price, which is not necessarily that user's highest price they would pay.
|
|
|
|
|
|
|
|
## Motivation
|
|
Ethereum currently prices transaction fees using a simple first-price auction, which leads to well documented inefficiencies (some of which are documented in [EIP-1559](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1559.md)) when users are trying to estimate what price will get a transaction included in a block, especially during times of price volatility and full blocks.
|
|
|
|
EIP 1559 is currently being championed as an improvement for the Ethereum protocol, and while I agree that the gas market is very inefficient, since a change like this will affect all client and wallet implementations, the Ethereum community should make sure to make a selection based on solid reasoning and justifications, which I believe 1559 is currently lacking.
|
|
|
|
To facilitate a more productive and concrete discussion about the gas fee market, I felt it was important to present an alternative that is clearly superior to the status quo, so that any claimed properties of EIP-1559 can be compared to a plausible alternative improvement.
|
|
|
|
I suggest the three gas payment algorithms be compared under all combinations of these conditions:
|
|
|
|
- Blocks that are regularly half full, Blocks that are regularly less than half full, and blocks that repeatedly full in a surprising ("black swan") series.
|
|
- Users that are willing to wait for a price that may be below the market rate, vs users who value inclusion urgently and are willing to pay above market rate.
|
|
|
|
We should then ask:
|
|
- Is the user willing to pay the most in a given scenario also likely to have their transaction processed in a time period they find acceptable?
|
|
- Are users who want a good price likely to get included in a reasonable period of time? (Ideally within one block)
|
|
|
|
I believe that under this analysis we will find that the escalator algorithm outperforms EIP-1559 in both normal and volatile conditions, for both high-stakes transactions and more casual users looking for a good price.
|
|
|
|
While I think a deeper simulation/analysis should be completed, I will share my expected results under these conditions.
|
|
|
|
Furthermore, by introducing tx fee payment related to the current time, we create an incentive for miners to more honestly report the current time.
|
|
|
|
### User Strategies Under Various Conditions and Algorithms
|
|
|
|
First I will suggest a likely optimal strategy for different players under the conditions of the different algorithms being considered.
|
|
|
|
| Gas Strategy | Current Single-Price | EIP 1559 | Escalator |
|
|
|---------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| Blocks regularly half full, user wants urgent inclusion. | User bids within the range of prices that have been recently accepted, likely over-pays slightly. | User bids one price tier over the current rate, and is likely included. | User bids a range from the low end of recently included to the high end, and is likely included at the lowest rate possible. |
|
|
| Blocks regularly half full, user willing to wait for a good price. | User bids below or near the low end of the recently accepted prices, may need to wait for a while. If waiting too long, user may need to re-submit with a higher price. | User bids under or at the current price tier, and may wait for the price to fall. If waiting too long, user may need to re-submit with a higher price. | User bids as low as they'd like, but set an upper bound on how long they're willing to wait before increasing price. |
|
|
| Blocks regularly full, user wants urgent inclusion. | User bids over the price of all recently accepted transactions, almost definitely over-paying significantly. | User bids over the current price tier, and needs to increase their `tip` parameter to be competitive on the next block, recreating the single-price auction price problem. | User bids over a price that has been accepted consistently, with an escalating price in case that price is not high enough. |
|
|
| Blocks regularly full, user willing to wait for a good price. | User bids below the low end of the recently accepted prices, may need to wait for a while. If waiting too long, user may need to re-submit with a higher price. | User bids under or at the current price tier, and may wait for the price to fall. If waiting too long, user may need to re-submit with a higher price. | User bids as low as they'd like, but set an upper bound on how long they're willing to wait before increasing price. |
|
|
| Blocks regularly under-full, user wants urgent inclusion. | User bids within or over the range of prices that have been recently accepted, likely over-pays slightly, and is likely included in the next block. | User bids at or over the current price tier, and is likely included in the next block. | User submits bid starting within recently accepted prices, is likely accepted in the next block. |
|
|
| Blocks regularly under-full, user willing to wait for a good price. | User bids below the low end of the recently accepted prices, may need to wait for a while. If waiting too long, user may need to re-submit with a higher price. | User bids at or under the current price tier, and is likely included in the next block. If bidding under and waiting too long, user may need to re-submit with a higher price. | User bids as low as they'd like, but set an upper bound on how long they're willing to wait before increasing price, is likely included in the next few blocks at the lowest possible price. |
|
|
|
|
### User Results Under Various Conditions and Algorithms
|
|
|
|
Now I will consider the ultimate results of the strategies listed above. Are users happy under these conditions? Did we save users money? Were users who wanted urgent inclusion able to secure it?
|
|
|
|
| Gas Strategy | Current Single-Price | EIP 1559 | Escalator |
|
|
|---------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------|
|
|
| Blocks regularly half full, user wants urgent inclusion. | User pays an expected amount, and gets transaction mined reliably. | User pays an expected amount, and gets transaction mined reliably. | User pays an expected amount, and gets transaction mined reliably. |
|
|
| Blocks regularly half full, user willing to wait for a good price. | User can wait for a better price, but may need to resubmit re-signed transactions. | User can wait for a better price, but may need to resubmit re-signed transactions. | User can discover the lowest price within their time preference with a single signature. |
|
|
| Blocks regularly full, user wants urgent inclusion. | User over-pays, but reliably gets transaction included. | Due to `tip` parameter "breaking tie" within a block, user over-pays for reliable inclusion. | User is able to balance the amount of overpayment they risk with the urgency they require. |
|
|
| Blocks regularly full, user willing to wait for a good price. | User chooses their price, and waits for it, or manually re-submits. | User chooses their price, and waits for it, or manually re-submits. | User chooses their lowest price, but also their highest price and maximum wait time, so no resubmission is needed. |
|
|
| Blocks regularly under-full, user wants urgent inclusion. | User over-pays, but reliably gets transaction included. | User bids at or over current price tier, gets transaction mined reliably. | User pays an expected amount, and gets transaction mined reliably. |
|
|
| Blocks regularly under-full, user willing to wait for a good price. | User bids below the low end of the recently accepted prices, may need to wait for a while. If waiting too long, user may need to re-submit with a higher price. | User chooses their price, and waits for it, or manually re-submits. | User chooses their lowest price, but also their highest price and maximum wait time, so no resubmission is needed. |
|
|
|
|
In all cases, the escalator algorithm as I have described is able to perform optimally.
|
|
|
|
The current gas auction model works well under half-full and less conditions, but for users with urgent needs, has the downside of overpayment. For users seeking a low price, the current model has the downside of requiring re-submission, but has the benefit of always giving users a path towards reliable block inclusion.
|
|
|
|
EIP-1559 also performs well under normal conditions, but under conditions where blocks are regularly full, the price discovery mechanism breaks, and miners will fall back to the `TIP` parameter to choose the transactions to include, meaning that under network congestion, EIP-1559 forces users to _either_ choose efficient prices or certainty of next-block inclusion.
|
|
|
|
EIP-1559 also has all the re-submission issues of the current model in situations where a user would like to pay under the current market rate, but has certain time constraints limiting their patience. The Escalator algorithm is the only strategy listed here that allows users to discover the lowest possible price given the network conditions and their time constraints.
|
|
|
|
## Specification
|
|
**Client-Wide Parameters**
|
|
* `INITIAL_FORK_BLKNUM`: TBD
|
|
|
|
**Transaction Parameters**
|
|
The transaction `gasPrice` parameter is now optional, and if excluded can be replaced by these parameters instead:
|
|
|
|
* `START_PRICE`: The lowest price that the user would like to pay for the transaction.
|
|
* `START_TIME`: The first time that this transaction is valid at.
|
|
* `MAX_PRICE`: The maximum price the sender would be willing to pay to have this transaction processed.
|
|
* `MAX_TIME`: The time at which point the user's `MAX_PRICE` is achieved. The transaction remains valid after this time at that price.
|
|
|
|
**Proposal**
|
|
|
|
For all blocks where `block.number >= INITIAL_FORK_BLKNUM`:
|
|
|
|
When processing a transaction with the new pricing parameters, miners now receive a fee based off of the following linear function, where `BLOCK` is the current block number:
|
|
|
|
* IF `BLOCK > MAX_TIME` then `TX_FEE = MAX_PRICE`.
|
|
* `TX_FEE = START_PRICE + ((MAX_PRICE - START_PRICE) / (MAX_TIME - START_TIME) * (BLOCK - START_TIME))`
|
|
|
|
As a JavaScript function:
|
|
```javascript
|
|
function txFee (startTime, startPrice, maxTime, maxPrice, currentTime) {
|
|
|
|
if (currentTime >= maxTime) return maxPrice
|
|
|
|
const priceRange = maxPrice - startPrice
|
|
const blockRange = maxTime - startTime
|
|
const slope = priceRange / blockRange
|
|
|
|
return startPrice + (slope * (currentTime - startTime))
|
|
}
|
|
```
|
|
|
|
## Backwards Compatibility
|
|
|
|
Since a current `gasPrice` transaction is effectively a flat-escalated transaction bid, it is entirely compatible with this model, and so there is no concrete requirement to deprecate current transaction processing logic, allowing cold wallets and hardware wallets to continue working for the foreseeable future.
|
|
|
|
## Test Cases
|
|
TBD
|
|
|
|
## Implementation
|
|
TBD
|
|
|
|
## Security Considerations
|
|
The security considerations for this EIP are:
|
|
- None currently known.
|
|
|
|
## Copyright
|
|
Copyright and related rights waived via [CC0](../LICENSE.md).
|