Removes block size and transaction size riders from EIP 1559.

[MicahZoltu]

This EIP previously changed the mechanism for calculating block size from a miner-voted mechanism to a hard-coded mechanism. This change is not necessary for the implementation of EIP1559, so this PR removes it and updates EIP 1559 to retain miner voted block sizing.

Opinion

Riders are very unhealthy for governance. While in this case I suspect that the rider may not have been intentionally underhanded, I think we (EIP authors/editors/core devs) need to be very cautious about allowing riders to become a norm. I have seen them included in more and more EIPs lately, especially controversial topics like miner issuance reductions.

I do not think it is unreasonable to change from miner voted block size to core dev defined block sizes, but that should occur as its own EIP and debated on its own merits, rather than being bundled in with this EIP. It should also, ideally, be configurable per-chain separately from EIP-1559.

cc @vbuterin @econoar @AFDudley @mslipper @i-norden (EIP-1559 authors)

[eip-automerger]

Hi! I'm a bot, and I wanted to automerge your PR, but couldn't because of the following issue(s):

• EIP 1559 requires approval from one of (@i-norden, @mslipper, @AFDudley, @vbuterin, @econoar)

[Agusx1211]

My opinion is that the part of the system that is currently broken is the fee market, not the mechanism of determining the size of the block, so EIP should only address the former.

Miners slowly moving the block gas limit has been very useful in the past, for example the migration from 8m to 10m blocks went very smoothly, and it would be nice that something like that could happen again without a hard-fork.

Also, IMO a fixed dev-defined gas limit has more chances of becoming the status-quo similarly to what happen with Bitcoin.

[i-norden]

Only potential complication I can see is that- since the base fee is a function of the previous block's actual gas usage and target usage- continuing to allow miners to set the gas limit/target provides another means by which they can affect the base fee. Another way to put this is, the base fee introduces a new incentive for miners to reduce the gas limit/target. In my view, this is more problematic than the other means by which miners can influence base fee- by affecting gas usage- since in that case miners are incentivized to include more txs whereas in this case they are incentivized to reduce block size.

Keep in mind I am merely an implementer! I look forward to discussing this further tomorrow, and will be happy to make the requested changes to the go-etheruem implementation if this is the consensus.

[MicahZoltu]

@i-norden Can you describe the attack vector you see in more detail? In particular, I would like to see an attack that is profitable rather than lossy, and so far I have been unable to come up with a profitable attack for miners.

When I think about miners reducing the block size, I don't see how they will profit from that short term or long term. Short term (this block), they received epsilon less gas in their block so it is a short term epsilon loss. Long term, if they reduce the block size to say 21,000 gas, 1559 will still result in blocks being half full on average, and the basefee will increase until that is true. When that happens, miners will be back to receiving the same premium as they received before but on a much smaller block.

I believe that the blocksize moves slow enough and 1559 basefee moves fast enough that 1559 should maintain its target 50% full equilibrium for essentially the entire ride down, so there also isn't a medium-term profit for miners by swinging block sizes.

[AFDudley]

@MicahZoltu Okay, all of that sounds reasonable, what amount of proof would be required for you to feel comfortable putting your suggestion into production?

It's not really a rider... the whole thing is grossly under-specified and untested. This particular implementation was selected because it seems safer, again entirely based on feel, not any sort of testing or simulation.

EDIT: Just to be clear, this implementation was selected with the expectation that testing would resolve this question about miner attacks. None of us on the implementation side have any idea what the community's tolerance for vulnerabilities is, nor do we wish to be prescriptive. That being said, it's pretty obvious to me that the logic "riders are bad so remove it" doesn't really fit given the significance of the change in question. I think this EIP is filled all sorts of governance landmines, this is just one of them. I also don't want to prescribe a solution to the "rider problem" which I acknowledge is real.

[MicahZoltu]

I'm comfortable merging this PR now and getting it integrated into clients and scheduling for a hard fork (assuming no one shows up with a good argument against merging this PR or 1559 in general).

I'm not in the camp of people who feel a need for a computer to tell me that the mechanism design is sound. 😬

[i-norden]

Hey @MicahZoltu those are all great points, and no unfortunately I do not have a more detailed description of an attack vector at this time. I avoided that language in my post, the only thing I'm attempting to convey here (which you have clearly already considered, so I apologize if my post implied otherwise) is that setting the gas limit provides a means to affect base fee and the base fee adds a new incentive for miners to reduce the gas limit. Correct me if I am wrong, but I don't think either of those two things are disputable.

I don't have the math or models at hand to demonstrate whether or not this is actually problematic- whether or not that incentive weighs enough to matter- given all the other mechanisms at play here. Uncle rates and the relative sizes of the base fee reward, block reward, and the fee tip rewards are complicating factors here.

I am in no way trying to provide a definitive answer here, I am in the camp that believes we need proper modeling and testing before these things can be asserted one way or another.

I do think we should at least discuss this further at the meeting tomorrow before merging.

[MicahZoltu]

the base fee adds a new incentive for miners to reduce the gas limit. [...] I don't think [that is] disputable.

I dispute this. 😄 My assertion is that the introduction of the base fee does not incentivize miners to reduce the gas limit. At worst, it makes them a bit more ambivalent toward the gas limit and incentivizes them to set it appropriately given uncle rates as a function of block size and marginally decreases their incentive to size blocks based on expected current or future congestion (their profit during times of high congestion are reduced by 1559).

[MicahZoltu]

Keep in mind, while it may seem like a good idea to increase the block size during congestion, this increases uncle rates which results in more frequent reorgs which results in longer confirmation times along with higher node operating costs which can lead to reduced number of nodes which reduces decentralization which can reduce censorship resistance.

That is a long winded way of saying that "bigger blocks are not always better". The current system mildly incentivizes miners to increase block size even when that may not be good for the health of the network. The new system takes away that incentive I believe.

[AFDudley]

Yeah, there is a lot to unpack here. I think we've been erroneously conflating "congestion" with "attack" and also conflating it with "growth". Allowing the miners to set the block size absolves the client engineers from having to figure out the difference between "congestion", "attack", and "growth". It seems logical to me that if we are going to dampen the gas/USD volatility, we must also begin to clarify the difference between growth and an attack. If we need to change the wording of the EIP to make that relationship more clear, someone should submit a PR 😁

[i-norden]

I would argue that an incentive is an incentive whether or not it is enough to outweigh other incentives, and I am making no assertations of the later.

Also,

it makes them a bit more ambivalent toward the gas limit and incentivizes them to set it appropriately given uncle rates as a function of block size and marginally decreases their incentive to size blocks based on expected current or future congestion (their profit during times of high congestion are reduced by 1559).

sounds like a change in incentives to me... but let's not devolve into a semantics discussion :D

[imkharn]

Riders are a form of unnecessary centralization of power in the hands of those proposing the change. Thus subjects of votes should be on the smallest scope possible. In this case the principal change potentially affects the incentives for block size voting in a negative way, so perhaps it needs to be included. The default assumption should be minimum scope, and to increase the scope should require discussion and sound argument as why it needs to be included.

In this case the change does influence the incentives of miners when they vote on size so its possible it is best to remove that power. Don't know without discussion.

If block size goes down:
Minfee goes up to reduce the use of Ethereum which in turn reduces the number of parties paying tips. Average tip should only ever grow large if the block is constantly full which minfee increases make unsustainable. Otherwise average tip will be the minimum needed to not be ignored despite the space available in the block. I predict miners will want the block limit to be as much as their computers can handle while remaining profitable. Since minfee is basically a tax that reduces the supply of fee payers, miners will balance the benefit of more transactions tipping with their mining operation costs. Without examining deeply my initial impression is that it's safe to leave in the block size voting.

[MicahZoltu]

I would argue that an incentive is an incentive whether or not it is enough to outweigh other incentives

Just for clarity, when I said:

introduction of the base fee does not incentivize miners to reduce the gas limit

I was using the term incentivize in this context to be a boolean state that resolves to true if the sum of all incentives (positive and negative) is positive, and false otherwise.

[i-norden]

@imkharn I agree riders are bad form but I also echo @AFDudley in that "the logic 'riders are bad so remove it' doesn't really fit given the significance of the change in question"

I also think there is some irony in proposing removing a rider while also suggesting that we do not need proper tests or modeling to demonstrate a mechanism's design is sound. On the surface it is always safer to make fewer changes but these mechanisms aren't isolated and so by introducing just the core/required changes of this EIP- because of how significant they are- we are already introducing change further throughout the system.

I should add that my assertion about miners being incentivized to increase base fee only holds any water when a portion of that base fee is being rewarded to the miner, something that has been discussed but is not currently part of the EIP or geth implementation. I apologize for that confusion. Although, in the absence of that I think the same argument could be made for it incentivizing raising the gas limit for the reason you just highlighted @imkharn. Is that a problem? I don't think so. Do we know for certain? I also don't think so.

In any case, I'll be happy to make the imp changes to fit the consensus. Although, it's not entirely clear to me how exactly consensus will be measured here.

[i-norden]

I would argue that an incentive is an incentive whether or not it is enough to outweigh other incentives

Just for clarity, when I said:

introduction of the base fee does not incentivize miners to reduce the gas limit

I was using the term incentivize in this context to be a boolean state that resolves to true if the sum of all incentives (positive and negative) is positive, and false otherwise.

Thanks @MicahZoltu that clarifies things- my mistake- and in that case I would tend to agree but would also like to see modeling of both cases or a more formal proof :D

Measuring incentive as a boolean makes sense to me for a single state but I think in general we need to consider incentives as cumulative forces, since whether or not introducing a new incentive later will flip that boolean switch will depend on the cumulative non-boolean state of all incentives at the point of its introduction.

[MicahZoltu]

suggesting that we do not need proper tests or modeling to demonstrate a mechanism's design is sound

Creating a soundness proof is incredibly difficult and expensive. It wasn't until many years after Bitcoin's launch that it was realized that "fees only for miners" isn't actually incentive compatible. If the bar to change the system is such that you must show up to the table with a formal proof that your proposal is sound then changes to Ethereum will slow to a crawl. While I am certainly not in the "move fast and break things" camp that some people are in, I also don't think we are at the point in Ethereum's lifecycle where we need a 5-year change control process to touch parts of the system like Bitcoin (effectively) has.

In this case, I'm reasonably confident that the system is sound enough without taking away miner control of block size and I haven't heard any strong arguments that the system isn't sound with that change (e.g., proposed attack vectors). I further argue that for Ethereum, at this point in its lifecycle, the burden of proof should be for someone to show that a viable attack vector is possible, rather than on the proposer to show that there exists no possible attack vectors. The former is far simpler than the latter, which is why I think it is appropriate for Ethereum today. At some point in the future, it may make sense to flip that around and put the burden of proof on the change proposer, I just don't think we are there yet.

[i-norden]

I agree that we don't need a formal proof or that one is necessarily feasible. But systems testing/modeling would be nice and are feasible; they are already under way for the current implementation. So I think the ultimate questions here are: is there time/resources to test both? If not, which approach do we continue forward with? I can't answer either of those questions but hopefully they will be resolved in the meeting tomorrow.

[axic]

@i-norden if you want this to be merged, you have to make a review approval on github and the auto-merge will merge it since you are an author.

[i-norden]

@axic @MicahZoltu I need to be requested for review, It appears to not be possible for me to request review from myself here.

[MicahZoltu]

@i-norden I think only members can request a review. However, you can supply a review without being requested by clicking the files tab at the top and then the green review button in the top right.

[i-norden]

Thanks @MicahZoltu!

[axic]

Thanks @i-norden! The same applies to other EIP-1559 changes 😉

[0xalizk]

the burden of proof should be for someone to show that a viable attack vector is possible, rather than on the proposer to show that there exists no possible attack vectors.

When the proposal in question is so close to the metal, this is a very risky approach.