This post assumes some level of understanding of the design goals of EIP-1559 and an understanding of their significance. For more information on this please visit the EIP and the Magicians thread.

Where We Were

Vulcanize was given a grant mid last year to do a feasibility study for implementing 1559 into a client and provide a Proof-of-Concept implementation. This work recently concluded and includes:

Moving forward, Ian Norden will be the primary developer continuing to work on the implementation. It is at the stage of 80/20. As in: yes, there is an implementation that works in Geth (80%), but there is still a lot of work to do before it can be considered ready to merge into the main client (20%). However, the last 20% is 80% of the effort needed.

Where We Are

The original EIP did not specify where any changes in client code need to occur. Transactions are handled in many places in the client codebase and the implementation study sussed out where these would be in practice. There also was an addition, after a suggestion from Alexey Akhunov that there should be a transition period, where both new and old transaction types exist on the network. This, as well as other practical limitations from the client architecture, informed the updated design for 1559.

The implementation study was then used to create the Geth PoC we have today. The next step is to take the implementation and update the specification to match, and then to verify that the spec and the implementation say the same thing. This is likely a process that will repeat a few times until the core devs are comfortable with a finalized design.

This is the stage where we are currently. Terry Culver from ETC Labs is providing us with one of their engineers to help with this process, but we need more eyes on this! Any experienced Geth developers who are able and willing to help with this process please reach out to me. @jhancock

Additional Work Ahead

Before 1559 is accepted fully by the Core Devs there are few remaining unknowns to be addressed:

Will increasing the Block Gas limit leave open a DoS(Denial-of-Service) attack vector where someone could fill blocks long enough to disrupt the network?



There is an economic argument against this that any sustained attack would be too expensive to be practical. This has yet to be formally written, which would help clarify this point.

Will increasing the Block Gas limit allow blocks of sufficient size to disrupt transaction propagation on the network? This will require some simulation of the network to verify there is no problem. There is one team currently preparing to execute this task.

Will the new transaction fee mechanism behave as expected under the new economic rules? Economic simulation and Game-Theoretic evaluation is needed to answer this question sufficiently. Who is doing this is yet to be determined. There is funding available, please reach out if you think you are capable of taking on this part of the work.

Work in Parallel

The Besu team (w/ Tim Beiko coordinating) is ramping up to provide the Java implementation. Thank you!

Get in Touch.

After some discussion at EthDenver I signed on as acting champion for EIP-1559, with Ian championing the implementation. I see this EIP as very important to the community and so am working to translate this sentiment to the Core Devs as well as keep the work moving forward.

If you have any questions please feel free to comment on the Magicians thread. If you would be willing or know someone willing to review the implementation please reach out.

Thank you,

James Hancock

Special thanks to Trent Van Epps for his help with this report

Links