EIP-1559: Fee market change for ETH 1.0 chain

EIPs
,
#56

Update:

We commissioned a study from Matt Slipper on Implementation of 1559, including the specific changes required within Geth and a more complete fork strategy. All changes included are additive. Here are a few main points.

Fork 1:

  • Add new transaction type
  • Both run in parallel
  • A transition function that overtime reduces gas available on the the old type and increases gas available for the 1559 transaction type

Fork 2:

  • Clean up
  • Unlock any remaining of the total 16 million gas for the new type.

Incentives to adopt the 1559 transaction type
We already have a “stick” in the form of reducing the gas available to the original transaction type. To introduce a “carrot” to encourage adoption by users and wallets we suggest that any gas cost reductions, or gas price updates only be available for the new 1559 transaction type. The implementation study includes how this is possible from a code perspective, and this approach simplifies a lot of the game theory around the transition to the new type.

Starkware recently championed an EIP for reducing gas costs for Istanbul. I have worked closely with them, and there is plenty of room for additional decreases in gas cost in subsequent forks for incentives. Also, any gas updates to individual op_codes are available to us as well.

Looking forward to your comments, questions, and feedback.
James

1 Like
#57

Hello Magicians,

We’ve put together a brief that outlines the status of the EIP-1559 working group.

Please feel free to circulate with whomever you deem relevant.

Right now, we’re still in the process of soliciting bids. In particular, we want to make sure we get the simulation and modeling pieces right per @AFDudley 's comments earlier, so that analysis can provide guidance on parameters for the community to discuss.

In particular, we are looking for

  1. economists to help with a formal assessment of the fee market proposal
  2. simulation experts that will be able to work with us to derive agent profiles
  3. software development firms which have extensive experience working on geth and Ethereum code bases.

Any leads would be appreciated, and this document may be a good starting point to share.

In addition, we now have an email address!
Feel free to publicly post or DM us here on the forum, but we can also be reached for inquiries at
1559@vulcanize.io

Thank you.

1 Like
#58

I would really like this EIP to be implemented.

I’ve started gathering data on gas fees - I don’t know if somebody has similar charts already

00
Screenshot 2019-09-23 at 11.37.00.png1000×724 121 KB

What could ETH user with some basic python / data analysis skills could do to push it further?
Is it possible to donate money for people working on this?

3 Likes
#59

What is the time frame for this?
My main problem for this EIP is that there is no clear champion taking leadership around this change.
The only one to be hurt by the current situation are end users.

1 Like
#60

Further preliminary data: minimum gas fee “safe low” is gravitating towards multiplies of 5:
The histogram looks gaussian around 10 gwei but also like exponential decay at around 1+

It suggest that there is very large demand for getting sub 1 gwei transactions cleared - but question is what’s the limit of ETH network in this regard?

What’s the optimal gas fee that’s a compromise between UX and maximising the security of the network and network value?

57
Screenshot 2019-09-24 at 01.41.57.png1446×972 74.7 KB

1 Like
#61

@guthlStarkware we’re targeting Berlin currently.
@kwikiel thanks for these analyses. I’ve seen this graph which may be relevant https://gitcoin.co/gas/history
how are you defining safe low/standard/fast here?
with regards to donating money, we are coordinating partners and budgets at the moment.
we should have updates shortly.

1 Like
#62

Why would the miners ever raise baseFee?

#63
#65

Great! One solid way to do this would be to set TARGET_GASUSED as a hardcoded value, especially for Ethereum Classic.

Incentives

The full-nodes are the ones that have no input, output, or incentive no matter what you do to this market (it is between miners and users alone). Full-nodes are essentially volunteers so hard coding the TARGET_GASUSED low enough, such that anyone interested in running a full-node can do so without significant cost. Of course “significant” is a matter of debate but having users or miners affect this value is worse than developers, as their incentives are known to be different than full-nodes, however there is no way to get a sybil-proof opinion from them so as a consolation the devs (having less of a conflict-of-interest) decide. Ethereum of course has different security tradeoffs so I would love to know if you have a different variation. link?

#66

Making things better for full nodes should be addressed other ways. the purpose of the gas price is not to make things easier on full node operators, a different mechanism should be used.

#67

look for champions soon (hopefully)

#68

For the existing proof-of-work system it may actually make more sense, instead of just burning everything collected in BASEFEE, to put some or all of it in a fee pool to be distributed equally among the miners of the following x blocks. That way you preserve the current incentive structure for miners as a collective where they want total fees collected to be high, and you should be able to also keep the current system where miner voting controls the network’s capacity.

If you burn all the base fees, the next step seems to be to say, “OK, we can’t trust miners to control this so we need to replace the miner voting mechanism”, and you end up potentially shaving a lot of yaks unrelated to the original fee market improvements.

1 Like
#69

The only comment I have on this magical idea: call it the Ether Bonfire

Provincetown-Bonfire-Guide-1080x600
Provincetown-Bonfire-Guide-1080x6001080×600 142 KB

1 Like
#70

I should probably post this in here, shouldn’t I :sweat_smile:

#71

Cross-posted from here:

If we imagine a large backlog of transactions whose submitters have widely varying preferences of the highest price they would pay, then I think it should be simple to prove that:

Under 1779:

  • The very highest bidders’ transactions may wait a number of blocks until the BASEFEE increases to a level that excludes other transactions, making the tip a sort of single-price auction within each block that reproduces all the problems of the current market but with the additional complexity of this one.
  • Once the price has increased to a point where the highest price transactions are cleared, and the BASEFEE is going to lower again, the lower-priced transactions remaining will need to wait additional blocks for the price to fall to be eligible for inclusion.

Under the Escalator algorithm:

  • The highest bidders’ transactions would be cleared as quickly as possible, and then the lower-priced transactions would be processed. No block lag to discover price, no unfull-blocks-with-pending-transactions, and only one or two parameters would need to ever be shown to the user (cap and max_duration).
#72

I would like to see time-to-return-to-normal-fee mapped against volume-of-tratsient-congestion-spike to get a better idea of whether this is something I would care about.

I suppose it depends on how long the congestion lasts (how long does the system have to increase the fee rate)… does that mean we need a 3 dimensional graph?

#73

A huge spike of transactions of size k*L (assuming gaslimit L) in non-EIP-1559 land would last k blocks. In EIP 1559 land, there would be a “full blocks and increasing fee” phase that lasts k/2 blocks (assuming max_gas/target_gas = 2) and then a “decreasing fee” phase that lasts another k/2 blocks because the decrease would be the same as the increase. The difference though is that in EIP 1559 land, during the decreasing fee phase transactions willing to pay a temporarily increased fee would be able to immediately get in, whereas currently they would still have to compete with the transaction spike. If max_gas/target_gas > 2, then things are even more favorable for the EIP 1559 case, though that could lead to unacceptably high burst load for clients in the network.

2 Likes
#74

Just looking back over this thread I noticed that quite an important aspect hasn’t really been discussed, namely: Does paying fees to miners (beyond the minimal amount they’d get in tips) help secure the network?

I guess this isn’t attracting a lot of attention right now because fees are pretty low compared to the block reward (something like 3% on average) so any contribution they’re making is fairly insignificant and hardly worth wasting pixels over.

However, already there are some times when fees become significant - the recent case was when ETH crashed and there was a spike in defi activity. It strikes me that times like this are currently the security worst-case for Ethereum: Security spend is abruptly dropping (because ETH crashed) but at the same time the value transacted on-chain is very high. High value transacted on-chain makes attacks - whether rolling back the chain to change transaction order or censoring transactions - more profitable, so we need more security spend to disincentivize them. If there was nothing of value being transacted then there would be nothing to gain by messing with the transaction history, but if there’s a lot of value being transacted then there’s a lot of money to be made.

If this is right then fees paid to miners act as a kind of automatic stabilizer where the security requirement is (at least somewhat) correlated with value transacted, and value transacted is (at least somewhat) correlated with fees paid.

You can then look at this from either end: Either we hold our desired level of security constant and think about the block reward we’d need to get that amount of security, or we look at the amount we’re spending and try to work out how much security we’re getting. If we hold the block reward constant, we’re looking at a loss of least the 3% or so that is currently going to miners, but also some amount potentially much greater than 3% in the low-ETH-value high-transacted-value worst-case. Or if we hold the desired security level constant, we need to raise the block reward not only by the 3% or so that covers the average fees, but also by some additional margin to cover the worst-case. This seems particularly relevant as this EIP is being sold in other venues (not here) as something that will reduce net ETH issuance and thus benefit holders, when in fact it seems to do the opposite.

If we want to keep the proposed fee market mechanism without this effect on network security (or inflation, as you prefer) the alternative would be to put basefees into a fee pool, where they’re spread among all miners mining blocks at about the same time, rather than paying them all to the miner who mines that particular block.

#75

Figured I should post this here: we are having a 1559 implementers’ call this week. https://github.com/ethereum/pm/issues/167

#76

Great to see the fee market instability being addressed. This proposal is strictly better than the current first price fee mechanism being used in Ethereum today.

However, this proposal does not maximize social welfare. Additionally, this proposal is missing formal proofs for the nonmanipulation claims. In practical terms, while we don’t know of a concrete attack on this mechanism right now, such miner manipulation attacks may exist and would be discovered in production.

These issues were brought up and addressed in StableFees, an alternate auction mechanism that maximizes social welfare and has provable non-manipulation guarantees. In a nutshell, StableFees starts with a generalized second price auction and then adds a few rules to provably deter misbehaviors that occur in the decentralized setting that do not occur in traditional auctions.

If you are curious to learn more, a more detailed overview of StableFees is given in this blog post: https://hackingdistributed.com/2019/01/22/doing-fees-right/. For more gory details and proofs, the full paper can be found here: https://arxiv.org/pdf/1901.06830.pdf. Note that StableFees does not rule out colluding behaviors.