EIP-1559: Fee market change for ETH 1.0 chain

EIPs
,
#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.

#77

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
#78

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.

3 Likes
#79

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:

#80

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
#81

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
#82

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.

#83

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
#84

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:

#85

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?

#86

Just saw your comment @vbuterin

IMG_20200722_105546
IMG_20200722_1055461038×980 186 KB

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.

#87

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
#88

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.

#89

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
#90

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…

#91

The paper is saying the opposite. Miners are incentivized to drive the fees up, but drive the MINFEE down, so that the tip maximizes. When a miner creates a filled block that has a higher MINFEE then that creates an incentive for all other miners to ignore this block as it reduces all future revenue from transactions. In fact the incentive to game the system gets bigger.

E.g. for Spark Pool and Ethermine each step higher MINFEE would mean to surrender future transaction profits on their 29% / 20% share of all blocks.
Selection_199

True, I was just curious which aspect of 1559 specifically is the part that is disabling the mentioned attack as twittered by Vitalik. For me it seems 1559 in it’s current form incentivizes the attack even more.

– We have posted nearly at the same time, so see my previous post for a patch proposal on EIP-1559 to remove the gaming incentive.

1 Like
#92

This has been discussed here in this thread I believe. I forget what the arguments against it are but I think it was just something like, “why miners instead of everyone?”

The paper wasn’t about 1559 either. :slight_smile:

If a miner controls 51% of hashing power then they can do some pretty bad things to Ethereum, including simply ignoring all other miner blocks to maximize their block reward. 1559 doesn’t really change that in any meaningful way, and if someone wants to exploit 51% of hashing power for financial gains there are far more efficient ways to do so than driving the fee down. Something to keep in mind is that this sort of attack is collusion resistant because there is a financial incentive to defect, and you can defect anonymously. Because of this, it is very hard for miners to collude to execute the attack.

As far as mining pools go, keep in mind that any mining pool that is executing this attack will become less profitable than a mining pool that doesn’t execute the attack, which means pool participants can (and potentially will) individually defect if a mining pool is detected to be executing an attack like this.

It is the fee burning aspect that does it.

1 Like
#93

Thanks for the discussion @MicahZoltu , it’s good to keep the ball moving here. Very curious about the impact of EIP-1559 on the fee market once it’s deployed. If there are side-effects fixes such as FEEPOOL can still be discussed then.

1 Like