EIP-1559: Fee market change for ETH 1.0 chain

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).
1 Like

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?

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

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.

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

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.

Currently, EIP-1559 changes the block sizing strategy from miner-voted to core-dev-asserted. While this change may be reasonable in its own right, I believe it should be discussed on its own merits and included in a separate EIP. For that reason, I have submitted https://github.com/ethereum/EIPs/pull/2635 which removes the core-dev-asserted block sizing and updates EIP-1559 to retain miner-voted block sizing.

If the authors believe that miner-voted block sizing is bad and should be removed, I support submitting an EIP to do that and including arguments as to why it should be done. :slight_smile:

1 Like

IIUC, the current planned strategy is to enable a slow migration from legacy gas pool to EIP-1559 gas pool to allow dapps time to update to the new model. I think this is a good idea, but we need to consider the fact that during this transition, the max transaction size will be significantly reduced from block-size to about half of block size at the start of the transition. This may cause some contracts that depend on large transactions to break until the migration is far enough along that they can once again issue their large transactions.

As an example, some Augur transactions can get pretty hefty, as well as some 0x transactions (batch fills though, which may be splittable).

At the least, I think this should be mentioned in the backward compatibility section of the EIP.

4 Likes

I half agree with you. Rather, in the abstract I completely agree with your logic, but my practical experience in working with this EIP leads me to believe that separating it out along the lines you’re suggesting would do both of the EIPs a disservice. I don’t see a good way of navigating the politics, the current EIP is difficult enough :slight_smile:

Can you elaborate on the problems you see with the PR I submitted? To me, it seemed pretty simple to disconnect the change in block sizing from 1559. The only impacted section was the slow migration from old gas pool to new gas pool, but that ended up not being very hard to modify to achieve the goal of no change to miner-voted block sizing.

2 Likes

I have published a new EIP for Typed Transaction Envelope (https://eips.ethereum.org/EIPS/eip-2718) which enables us to add new transaction types to Ethereum without having to carefully tip-toe around backward compatibility. If that EIP finalizes before this one, then I recommend updating this to use it.

Transaction Type 0 will be a wrapper for legacy transactions, and EIP-2711 is tentatively going to be using type 1, so we can make this type 2 (we can choose any number, though < 55 saves us some bytes on the wire due to the nature of RLP encoding).

2 Likes

Can someone tell me why miners would include transactions without a tip if the fee gets burned and larger blocks will just slightly up orphans? It looks to me like most miners wouldnt need to actually put transactions into blocks and would only do ones with tips. If enough miners do this then most transactions would just be prioritised by gas price and as usage goes up the fee market will just be the same as now as only tip transactions get pushed.

Answered in Discord, but for continuity answering here as well:
Miners won’t accept transactions without a tip (at least not profit seeking rational ones that aren’t getting paid some other way).

1 Like

My issue is just that it slows down the process. If you want to break EIP-1559 into smaller chunks, that’s great, but given the current political climate that seems like it would slow the deployment. I would be elated if I was proven wrong about this by someone else trying it out. :slight_smile:

Usually splitting things up into smaller more manageable chunks facilitates moving things through more quickly because people can focus their efforts on the pieces they care about, and you don’t end up with one contentious piece holding everything else up. Do you believe that isn’t the case for Ethereum hard fork inclusion stuff? If not, do you have any idea why that isn’t the case?

Just saw your comment @vbuterin

Could you lay out the thought how eip-1559 helps with the attack described in the paper? I was thinking about the impact myself but concluded that because the anticipated equilibrium in https://www.cs.princeton.edu/~arvindn/publications/mining_CCS.pdf has only half filled blocks it would keep the MINFEE at 0 and hence not change anything on the problem.

There was another paper proposing payout of the transaction fee in a sliding average window of the last 10 blocks. That might fix the risk of the petty miner scheme and could be quick follow of 1559.

I’ll let someone else give the more complete response, but the gist of it is that 1559 burns congestion-related fees, thus miners would not profit from reorgs for fees.

If MINFEE is 0 then the system either is broken or demand for using Ethereum is legitimately low (which we haven’t seen for quite a while and seems unlikely to happen soon). Equilibrium for 1559 is half full blocks, but under the assumption of raw demand for Ethereum block space being greater than supply of block space. It is the fee going above 0 that drives final demand down to equal with 50% of block space supply.

1 Like

Yes problably broken is the right description or at least manipulated. I’m quoting from the mining_CCS.pdf paper, highlights by me:

Once any non-zero fraction of miners is PettyCompliant, it enables various strategies that are more aggressive and harmful to Bitcoin consensus. We call this the undercut-ting attack, where miners will actively fork the head of the chain and leave transactions unclaimed in the hope of incentivizing PettyCompliant miners to build on their block. In some scenarios, our simulation reveals a non-equilibrium with increasingly aggressive undercutting. But with an expanded strategy space, and suitable assumptions, we are able to prove that an equilibrium exists. However, it is one where miners include only a fraction of available transactions into their blocks. This results in a backlog of transactions whose size grows indefinitely with time. We confirm this result using simulation.

So when miners include only a fraction of available transactions into their blocks then my understanding is MINFEE would stay 0. It’s misbehavior, but misbehavior that might turn out to be more profitable to the miners.

This isn’t true. With 1559, MINFEE would be 0 only if a plurality of miners (exact portion changes depending on how much they sacrifice, but it can be as high as over 50%) all sacrifice profits in order to drive the fee down. As long as they do this, any miner that defects from this strategy will be more profitable than miners executing the attack as long as the attack continues. When the attack is no longer executed by a sufficient portion of miners, the base fee will rise back up to its correct level.

This means that any miner that defects from the attack is rewarded, and any miner that participates in the attack is punished for as long as the attack is ongoing. Also, we can adjust the portion necessary to successfully drive the base fee down by increasing the block size target. Current EIP specifies the target as being “half full” but we could just as easily target 1/4 full which would increase the hashing power required to attack the system in this way by ~2x. The only downside of that is that we end up with bigger block size spikes and it is unclear how various client implementations will handle that so we are starting with only a 2x block size spike being possible.


Something to keep in mind is that a 1559-like fee system is sufficiently different from the system the paper is attacking that the attack no longer makes sense. Because of this, outcomes from that paper cannot be applied to a 1559-like system directly. If you want to describe an attack against a 1559-like system, you will need to fully describe a new attack.

Imagine the situation “When X = 1 and Y = 2 then X+Y = 3”. If you change X to equal 5, the conclusions that X+Y=5 no longer holds and you will need to re-evaluate things. In this case, the paper is built on the premise that fees are allocated in a very specific way, and when you remove that premise the rest of the paper no longer falls out.

Note: It is certainly possible that an outcome like the one described in that paper is possible, but I believe it would need a pretty significant rework to draw that conclusion.

1 Like

Maybe this would help killing this bad equilibrium

Can’t find the paper anymore but I read an idea about creating a FEEPOOL. All spend transaction fees would be added to the FEEPOOL, and a block miner would receive 1/8th of that FEEPOOL for a new block. The MINFEE would stay and guide users to pay more when there is congestion, while miners would be incentivized keep blocks filled so the FEEPOOL stays high and miners would be less worried about tricking the previous or next block for transactions as their fee based revenue is less spiky. In fact miners could be incentivized more since I think burning fees below MINFEE would not be needed in this case and could just be added to the FEEPOOL