EIP-1559 Go-etheruem implementation

Hello everyone!

This thread will serve to extend the previous EIP-1559 discussions with a focus on the go-ethereum implementation provided by Vulcanize Inc.

That implementation can be found here

Other relevant links:
Updated EIP documentation
Previous discussion thread
Skinny EIP-1559 thread
Ethresear.ch Post w/ Vitalik’s Paper

After incorporating feedback received here I can proceed to open a PR for the implementation and the EIP documentation updates.



Thanks for doing this. Aside from the transition part, in the final state, would you mind ELI5-ing the way the main parameters (TARGET_GASUSED, BASE_FEE etc) get set in the current proposal?

The EIP has a TARGET_GASUSED and a BASE_FEE, but the BASE_FEE is now in a header field, so is the idea that the miners are voting on BASE_FEE directly like they do with the current gas limit, and the TARGET_GASUSED is just a parameter the miners set to feed the implementation’s default method for telling their node how to vote? Or is something else meant by “BASEFEE is maintained under consensus”?

Did you decide to make the basefee adjustment formula “just a suggestion”? I thought we had talked about this and decided to make it hard-coded to prevent miners from being able to individually push the fee up or down by a significant amount by adjusting the formula? Or is there some overriding rationale for making it just a suggestion?

Hey @edmundedgar and @vbuterin , thanks for the comments!

@edmundedgar TARGET_GASUSED is a constant that is used in the BASEFEE adjustment formula, it is the amount of gas we target to use and miners adjust the BASEFEE up or down depending on how the actual gas usage deviates from this value. Specifically, miners set a block’s BASEFEE as PARENT_BASEFEE + PARENT_BASEFEE * DELTA // TARGET_GASUSED // BASEFEE_MAX_CHANGE_DENOMINATOR, where DELTA = PARENT_GASUSED - TARGET_GASUSED.

The BASEFEE is maintained under consensus by the ethash engine. In the verifyHeader() method a header is invalidated if the BASEFEE increases or decreases relative to PARENT_BASEFEE more than the allowed amount (PARENT_BASEFEE // BASEFEE_MAX_CHANGE_DENOMINATOR).

@vbuterin per your comment the above is not quite right. I will update the consensus engine so that the exact value from the basefee adjustment formula is enforced, not just an upper and lower bound on the value. The need for this is apparent, currently a miner could change their basefee adjustment algo to submit arbitrary BASEFEEs that are valid so long as they are within the upper and lower limits e.g. they could raise the BASEFEE by as much as PARENT_BASEFEE // BASEFEE_MAX_CHANGE_DENOMINATOR even if PARENT_GASUSED is below TARGET_GASUSED. That’s an oversight on my part, but a simple fix to make. Thank you for pointing it out!

@i-norden Thanks, so to make sure this is clear, the proposal is that TARGET_GASUSED is hard-coded at 8 million and never changed, except by a future hard fork.

@edmundedgar that is correct!

Any reason why 8m, and not the current max of 10m? Setting to the current max seems most sensible.

Just a thought: It might be worth putting something about the change from miner voting to a hard-coded limit that’s only changed in hard forks in the abstract and the motivation section of the EIP; I think I understand the basic reasons why this is being done from the previous Magicians discussion, but it’s arguably a more significant change than the fee market reform that’s the subject of the EIP.


@vbuterin 8m is left over from when work began on this, before the gas limit increase to 10m. I simply missed that change. Will update to 10m now.

@edmundedgar that is a good point, I will update the EIP doc to be more explicit about this.

Thank you both!

Another change I would recommend is setting a hard per-transaction gas limit of 10m, arguably even set the per-transaction limit to 8m. Don’t want to set the precedent that yuge transactions are possible.

1 Like

@vbuterin added a per-transaction gas limit of 8m as recommended :slight_smile:

1 Like

Just curious, what are the next steps for moving forward with this EIP?

Will your team be presenting the updates to the spec on the Core Dev call tomorrow?

Hi @tvanepp! Sorry for the delayed response.

We didn’t make it on the Core Dev call last Friday. The plan of action is to incorporate feedback from here and then move forward by opening a PR for the EIP doc and Go-ethereum implementation. I’ll go ahead and open those PRs at the end of the week if no more changes are recommended/requested here. A more code-focused review can occur on the Go-ethereum PR.

1 Like