Hardfork Meta EIP-1679: Istanbul discussion

Uh. Or just add a column to the spreadsheet with a name :wink:

For the fee change EIP, Vitalik was the original author, Eric helped out, now Rick is the working group lead. So, champion / point of contact is Rick.

A working group column would be good too.

Also, code centric dudes, the point of contact doesn’t need to be an engineer — just someone who is helping with coordination and project management.

1 Like

That is fine too :+1: It solves the problem for me

But not sure it solves ^
I am confident I am not the only person who runs into this issue.

Also :+1:


Can you please explain why should it be possible that there’s no technical person as a point of contact for a protocol changing Core EIP? I can understand that could be the case for ERCs or non-Core EIPs.

Core EIPs should be serious specifications and there should be an obvious way to reach someone capable of answering specific technical questions about a specification. If there are multiple hops someone has to go through to reach a technical person, then I do not think such a Core EIPs should have a chance to be accepted. If there is no technical person willing to champion it, that signals to me there is no technical need for it.

At the specification stage (e.g. Draft mode) there must be a technical champion. When the specification is clear and coordination focuses around implementing the change in second and subsequent clients, there I could see non-technical coordinators to play a big role.

Yes technical people need to be involved. To pick on @MadeofTin, he’s not going to be able to defend a Blake2b precompile. But he could coordinate whatever is happening in the GitHub / Gitcoin thread.

EIPs with multiple authors needs to have one POC, a team (eg Parity or a Working Group) having a single point of contact for multiple EIPs, etc

This is all theoretical so let’s just do the work of filling out the spreadsheet. I’d like to capture the name not just GitHub handle.

@MadeofTin there are lots of things we can’t see by looking at an EIP, which is why we’re going to need to track things outside of a Markdown file :wink:

1 Like

Accepted as a Draft? Maybe the EIP-1 requirements need to be updated because that wasn’t on the list when I submitted blake2b nor 2025.

Your role as the champion is to write the EIP using the style and format described below, shepherd the discussions in the appropriate forums, and build community consensus around the idea.

As far as I can tell, that is exactly what I am doing. Of course, anything beyond being accepted as a Draft I understand. Why “accepted as draft” is the gatekeeper for this I don’t understand. I will respect it, I just don’t understand it.

What is the issue in labeling an EIP as Draft? Being draft doesn’t mean you are going to be accepted. Being draft doesn’t mean the core-devs need to bring it up on calls. After it is accepted by an editor it could never be brought up again. It is the first stage in the rest of the process. My previous understanding was that the requirements to be made a draft is that it was correctly formatted.

  • :arrow_right: Draft – If agreeable, EIP editor will assign the EIP a number (generally the issue or PR number related to the EIP) and merge your pull request. The EIP editor will not unreasonably deny an EIP.
  • :x: Draft – Reasons for denying draft status include being too unfocused, too broad, duplication of effort, being technically unsound, not providing proper motivation or addressing backward compatibility, or not in keeping with the Ethereum philosophy.

Draft – Once the first draft has been merged, you may submit follow-up pull requests with further changes to your draft until such point as you believe the EIP to be mature and ready to proceed to the next status. An EIP in draft status must be implemented to be considered for promotion to the next status (ignore this requirement for core EIPs).

What is the resistance to marking things as Draft? I am not upset, I just want to understand where I am wrong on this.

This is our first time through the EIP driven network upgrade process, so I don’t think any of these rules are hard and fast but are taken more of a measure of what EIPs are viable for this specific network upgrade. The fact there is a document that can be pointed to and a person willing to attend calls and advocate on FEM I think are the two strongest indicators, aside from the next checkpoint which is actual implementation in clients.


I know the deadline have passed but I would like to add a last minute proposal (EIP-2075) since it relates to 2 proposals already part of 1679 (EIP-1706 and EIP-1930).

See PR for hardfork : https://github.com/ethereum/EIPs/pull/2077

Hope that is fine, thanks.

EIP-1 currently requires a “technically sound” specification.

Also from EIP-1:

The main point of being Draft and having a somewhat comprehensible Specification is to allow actually useful discussions to happen around it. If a Draft doesn’t have any specification, then how will it be discussed?

I actually like @timbeiko’s proposal clarifying the EIP-1 text:

My understanding based on this is that EIPs without specification should not be drafts, but rather discussions in appropriate forums, such as FEM.


Updated http://eips.ethereum.org/EIPS/eip-1679 to reflect the current status as per today’s ACD call.

It was updated again by @timbeiko to reflect ACD#67.

As discussed on ACD#68, “Istanbul part 2” is named: Hardfork Meta EIP-2070: Berlin discussion

Ilan from Kyber
we would like to test and prepare our code for Istanbul fork.

anyone can share a working ganache version. Or any other working client?

Ilan Doron
Solidity developer
Kyber Network

Pantheon 1.2.2 release has a full implementation - https://pegasys.tech/solutions/pantheon/#installation-links

Geth’s git head also has a full implementation, and is fairly straightforward to build - https://github.com/ethereum/go-ethereum

I have reviewed this EIP and all its dependencies. My complete list of outstanding review comments follows: