# EIP-1559: Fee market change for ETH 1.0 chain

My proposal: Set a minimum value of at least 1 wei to `MINFEE`, `PARENT_MINFEE`, and `block.gas_used`.

``````delta = block.gas_used - TARGET_GASUSED
TARGET_GASUSED = 8,000,000
MINFEE_MAX_CHANGE_DENOMINATOR = 8
``````

There is also way to simplify the `MINFEE` formula:

``````MINFEE = PARENT_MINFEE + PARENT_MINFEE * delta // TARGET_GASUSED // MINFEE_MAX_CHANGE_DENOMINATOR
``````

For the rest of this comment, I will be using abbreviated variable names:

``````MF = MINFEE
MF_P = PARENT_MINFEE
MF_MCD = MINFEE_MAX_CHANGE_DENOMINATOR
GU_B = block.gas_used
GU_T = TARGET_GASUSED
delta = GU_B - GU_T
``````

Note: Iâ€™m also using `/` for division instead of `//`

1. Substitute original formula with new variable names
``````MF = MF_P + MF_P * delta / GU_T / MF_MCD
``````
1. Separate `MF_P`
``````MF = MF_P * (1 + delta / GU_T / MF_MCD)
``````
1. Instead of dividing by `MF_MCD`, multiply by the reciprocal
``````MF = MF_P * (1 + (delta / GU_T) * (1 / MF_MCD))
``````
1. Substitute in the variables for `delta`
``````MF = MF_P * (1 + ((GU_B - GU_T) / GU_T) * (1 / MF_MCD))
``````
1. Separate the delta variables from the numerator and divide both delta variables
by the same denominator
``````MF = MF_P * (1 + ((GU_B / GU_T) - (GU_T / GU_T)) * (1 / MF_MCD))
``````
1. `GU_T / GU_T` == 1, so replace `GU_T / GU_T` with `1`
``````MF = MF_P * (1 + ((GU_B / GU_T) - 1) * (1 / MF_MCD))
``````
1. Multiply `1 / MF_MCD` with both `GU_B / GU_T` and `-1`
``````MF = MF_P * (1 + (GU_B / (GU_T * MF_MCD)) - (1 / MF_MCD))
``````
1. Replace the first `1` with `MF_MCD / MF_MCD`
``````MF = MF_P * ((MF_MCD / MF_MCD) + (GU_B / (GU_T * MF_MCD)) - (1 / MF_MCD))
``````
1. Since `MF_MCD / MF_MCD` and `1 / MF_MCD` have the same denominator, we can combine the numerators
``````MF = MF_P * (((MF_MCD - 1) / MF_MCD) + (GU_B / (GU_T * MF_MCD)))
``````
1. Replace `MF_MCD` and `GU_T` with their static values
``````MF = MF_P * (((8 - 1) / 8) + (GU_B / (8,000,000 * 8)))
``````
1. Simplify
``````MF = MF_P * (7 / 8) * (GU_B / 64,000,000)
``````
``````MF = MF_P * ((7 * GU_B) / 512,000,000)

or

MF = MF_P * ((7 * GU_B) / (2^9 * 10^6))
``````

My conclusion:

• `MINFEE`, `PARENT_MINFEE`, and `block.gas_used` can never be equal to 0.
• If `MINFEE`, `PARENT_MINFEE`, or `block.gas_used` equal 0, all three variables
will equal 0.

• Can a bad actor to intentionally mine a block with 0 gas used?

They commonly do, yes.

They do, but not necessarily as a bad actor. If constructing a block full of transaction takes a long time, they first quickly construct an empty block, start mining it. Then, if constructing the block finishes and the empty block is still not mined, then they switch to the full block. If, however, the empty block is mined before the full block is constructed, they just publish the empty block. Makes economic sense

2 Likes

Seems like:

• What is the ideal adjustment formula?
• How to simulate and verify it?
Are good open questions to add as directives for the working group.

Another open question for me:

• Is the computation cost of verifying there is a miner-tip for a transaction enough to justify a miner even considering adding it?

My thinking so far is that it isnâ€™t enough for one person to tip â€śenoughâ€ť, but there have to be enough people tipping enough for the likelihood of any one transaction to have enough value for a miner to consider including any transactions.

• From a minerâ€™s point of view, what is the Expected Value (in the sense of probability theory) of adding one transaction to my block?
• From a users view, what is the minimum I can pay to get my transaction included?

My worry is that usually the â€śPay as little as I can get away withâ€ť, or â€śPay a little bit more than the person that pays least.â€ť tends the system to zero. The game theory of unlimited vacation days in corporations is a good example of this.

Perhaps system norms can fight this, or even displaying average gas-tip per block in the UX so users are encouraged to keep what is working working and can tip extra if they are impatient. This is probably something that will be seen as it runs on the network and the network can adapt to it through off chain coordination. Or, perhaps the cost of inclusion of a transaction is so low it wonâ€™t even be a problem.

Overall, I really like this idea of separating the auctions of gas-limit (network throughput) and block inclusion.

I see like this EIP is trying to exchange current â€śhigh volatility gas price schemeâ€ť + â€śtransactions prioritized by explicit gas priceâ€ť with â€ślow volatility gas price schemeâ€ť + â€śtransactions prioritized by implicit gas priceâ€ť.

So you are trying to fix gas price volatility with formulas allowing this price to be changed slowly from block to block.

I see the following problems here:

• Implicit gas price will not allow working with exact balances, it will be hard for example to spend all ETH balance from the wallet
• Miners could decide if a transaction is even worth to be considered, this usually means using ETH price in calculations, which can not be handled by formulas.

The first point I donâ€™t think will be much of a problem. The base_fee will be very predictable and if it works out as intended the miner_tip that miners will accept will also be stable. Or, at least the minimum tip they would consider.

The second point is something that we will see as it gets deployed. It is definetly possible that miners could reject transactions based on the tip being too low. It may also be that they get together as a group and â€śdemand higher wagesâ€ť. This would be a tough sale as rogue miners could swoop in to get increase profits, so there is likely an equilibrium there. Hard to tell where it will be until we get there. It is also depends on how coordinated the miners can be. And, by miners I really mean mining pools.

I wrote a post providing economic analysis about EIP-1559 in May. I had thought that maybe it is not necessary to publish it as others could provide similar thinking. But when I saw that someone still proposed it to Istanbul upgrade, it seems that many people still didnâ€™t know its influence on the network.

EIP-1559 is just making tips become the gas fee, and making BASEFEE a tax on transaction. Finally, as BASEFEE will change according the using rate of gas limit in last block, it will serve as a policy similar to lock the maximum of size of block.

And all of all, it could not make userâ€™s life eaier or make the actual fee predictable.

Here is the link of the post

2 Likes

I still think a once-per-day change in BASEFEE would be optimal for the user experience. Today, say itâ€™s 10 Gwei. Let the MAX gas float up to 4x the target of 8 million for the entire day. If we use 175 Billion gas instead of the daily 50 Billion target, AND that raises the 30-day moving average above 50 Billion, then the BASEFEE inches up to 12 Gwei tomorrow, and 20% more the day after that, etcâ€¦until the average gas usage returns to target. Sure, the state size can grow at 4x for very a few days, but it really doesnâ€™t matter as long as the gas slowly reprices to limit state growth to something sustainable.

Tips would only really be needed (1) to incentivize miners to take the transaction and (2) if the network is under a severe load (whether the surge due to an ICO or Cryptokitties or DOS), in which case it can revert to more of a competitive auction. But set the default tip at 25% of BASEFEE. Everyone knows the gas price, and that it might go up (or down) 20% tomorrow. If a client pays yesterdayâ€™s basefee by accident (e.g. they submit the tx a few seconds before the BASEFEE changes, then their 25% tip will be reduced to 5% and probably still be accepted by a miner.

Clients can still opt to pay double the BASEFEE (or more) as a tip for high priority transactions during congestion.

I fail to see why the gas price needs to change so rapidly as every few blocks. It makes for a frustrating user experience. We have the luxury of a low uncle rate now, so there is no barrier to allowing high capacity days to occur.

Hey all,

I am working with Rick on coordinating the EIP-1559 Working Group.
Currently, we are looking for a:

• Senior Geth Dev
• Wallet Dev.

PM me if you are interested, or know where we can find some. As, @tvanepps told me recently Senior Geth Devs are " elusive, like leprechauns" So, we appreciate any help.

1 Like

as stated here: Fee Market Change Working Group formation (and my proposed amendment)
I am happy to implement the new tx type in WallETH

1 Like

So, letâ€™s talk about DoS. The block gas limit currently acts as a protective measure for short term attacks (mispriced opcodes taking too much CPU resources, ala Shanghai), and long term attacks (state bloat).

The proposed EIP insta-bumps the gas limit to 24M, which would lead to block times of 200-1000ms (just pulled some random numbers from a Geth full node). By removing minersâ€™ capabilities to influence the block gas limit, we also remove the possibility to adjust in case of a future DoS attack. Is this good? Bad? Would be nice to discuss.

Wrt long term state bloat, the bumped gas limit will also permit a 3x rate of growth compared to current limits. The EIP assumes that people wonâ€™t be willing to pay for that, but until now weâ€™ve seen that Ethereum blocks are always full. I guess the design is that eventually the basefee grows so large that â€śnobodyâ€ť will want to play, so it will fall back down. I can imagine this working out, but would be interested in some discussion around it.

One interesting phenomenon that I see is that users would sign a transaction that actually permits an interval for the fees, but youâ€™ve no idea how much that will end up being. This will make sweeping an account impossible. Good? Bad? Dunno, just stating the facts.

A complication might arise around transaction propagation. Currently transactions have a total order, so full nodes can pick the best N transactions to keep and discard anything afterwards as SPAM). The base fee model could make things messy here, because the total order can change across blocks. We need to ensure that itâ€™s not possible to create transaction propagation scenarios where data rotates in the network indefinitely.

6 Likes

I like these comments a lot. Iâ€™m still preparing my comments on the EIP and Vitalikâ€™s paper. Iâ€™m less in favor of discussion and more in favor of modeling, I respect that the major stake holders already understand the problems well enough and need firmer numbers and/or code to agree with a proposal. This change is too fundamental to do otherwise. Once I have more details ready, Iâ€™ll provide those for feedback, thanks again.

2 Likes

I strongly agree with that. The BASEFEE is equivalent to taxation that people cannot escape from. The problem remains the same: There is limited gas avaible and people will compete with their respective tip that is equivalent to the current fee.

Furthermore (because the BASEFEE is equivalent to taxation) there will be lower welfare. A BASEFEE is also highly unfair since rich and poor individual pay the same fee. Imagine a scenario where there is a period of high network usage and therefore a high BASEFEE and tip. People with high willigness to pay will get their transactions included( probably rich people). Now imagine a period of low network usage where there would be low tips and a person with low willigness to pay could get his transcation included. Problem is that he inherits a high BASEFEE from the previous period. It`s like youâ€™re driving at night to avoid traffic and then the police stops by to say: â€śSorry there have been a lot of traffic today please drive slowlyâ€ť and you think ** because the street is fully empty.

Why to derive `tx.fee_premium` and `tx.fee_cap` from `tx.gasprice` uses 2**128? Does not that large number produce some issues in other languages?

The goal there was to shoehorn the two into one variable as a hack to avoid having to change transaction formats. My understanding is that @AFDudleyâ€™s work is NOT going in that direction, and instead itâ€™s biting the bullet on complexity-of-change to â€śdo it rightâ€ť.

Wrt long term state bloat, the bumped gas limit will also permit a 3x rate of growth compared to current limits

Not in the long term. The reason is that if average gas usage is above 8M/block, then fees will keep going up until average gas usage is at 8M/block.

The base fee model could make things messy here, because the total order can change across blocks.

Interesting! What do you mean by this?

Hi, I am very interested in this EIP but I have a question about the miner incentives. To be honest I didnâ€™t read through the whole thread here so I hope it wasnâ€™t answered before. What is the incentive of miners to increase the `BASEFEE`? As the proposal states:

A valid `BASEFEE` is one such that `abs(BASEFEE - PARENT_BASEFEE) <= max(1, PARENT_BASEFEE // BASEFEE_MAX_CHANGE_DENOMINATOR)`

So as I understand that the miners can decide what the next `BASEFEE` will be. Reducing the `BASEFEE` would result in more people sending transactions leading to bigger blocks (up to `SLACK_COEFFICIENT * TARGET_GASUSED`) and potentially more tips => more profit for miners. What incentives do they have to increase the `BASEFEE`?

When I first read the proposal I thought there is a deterministic consensus rule which determines the next BASEFEE based on the gas used in the previous block (or maybe better in the previous N blocks?) and the miner has to follow this rule (basically what is now described as â€śdefault strategyâ€ť but is not enforced in the current proposal). Why not use such an approach?

Hey all
We would like to bring this topic of discussion up during Magicians Council in Berlin. Is anyone interested in to talk about it @econoar @AlexeyAkhunov or anybody else

Would you like me to discuss it?

Sorry for the confusion, my proposal will have the increase under consenus.

Indeed, my extremely strong inclination is to figure out the right way to do it and then figure out when it fits in the release schedule.

The current plan is to add a new transaction type and fields to the block. This will allow us to have both transaction types functional at the same time, which is a hard requirement for tooling compatibility.

1 Like