ECIPs, also known as Ethereum Classic Improvement Proposals, are a set of specifications and processes that ease the complexity of hard fork on the Ethereum Classic blockchain.

After theDAO hard fork, ECIPs are forked from the same process in Ethereum, called EIPs (Ethereum Improvement Proposals). The initial process was slow, in that no one, even a core developer, knows the precise rules on how to write specifications, move it forward, gather consensus, and apply it in a hard fork. In June 2017, I drafted ECIP-1000 as an attempt to define the process. The draft moved slowly, but after two years of iterations and great feedback from the community, in early 2019, ECIP-1000 was finally enacted as the active process. In the document, a role called ECIP editors, which handles administrative tasks of the ECIP repository, was proposed. With the community’s support and enthusiasm, five editors were accepted – meowbits, Cody, Yaz, soc1c, and me. Things initially went well. PRs moved significantly faster than it was previously, and two successful hard forks, Atlantis and Agharta, were conducted.

It does not for the next planned hard fork Aztlan (ECIP-1061).

This post is a subjective story of the controversies behind it. It’s subjective because I am one of the person in the center of the controversies, together with soc1c. In the mean time, you will definitely hear a completely different story from the other side.

I hope what readers take from this post is not judgement of who is right or wrong, but lessons learned in the hard and daunting task of managing a specification repository for a decentralized community.

The Beginning

ECIP repository is hosted on a platform called Github. On Github, developers collaborate on code using a quite specific workflow. Code is first initially “forked”, either to another repository or to the same repository of a different branch. It is then submitted back as pull requests (PRs) for reviews. After a sufficient number of reviews, maintainers can proceed to merge PRs. Maintainers can also “request changes” of a PR, indicating that she or he believes that something may need to get fixed first before it is merged.

In addition, Maintainers can “dismiss” other people’s review. This indicates that either the review has already been well-addressed but the reviewer cannot be contacted (to re-submit the review herself/himself), or a maintainer wants to bypass another maintainer’s review. “Dismiss” is generally thought to only be used in specific situations where all other methods do not work. The UI also made this clear, by making the action of “dismiss” a tedious two-step process – a reason field that must be filled in, and a confirmation button.

ECBP-1076

The controversy starts with PR#194 on ECBP-1076. The PR proposed some changes in the documents, and at the same time, attempted to move it from “Draft” to “Active”. I was slightly puzzled by the changes, so I submitted a “request changes” review, for two reasons:

  • There were still issues unaddressed in the draft specification. ECBP-1065 was indeed discussed in a previous meeting. Although I was not able to join, prior to that meeting, people (including me) wrote some concerns related to the specification, and I couldn’t find them addressed. Based on my experience with Ethereum’s AllCoreDevs, I also find it quite unusual to propose a proposal for the first time and accept a proposal in the same meeting.
  • The move to “Active” status was unheard of and potentially unfit for the ECIP process. ECBP corresponds to Ethereum’s ERC specifications. Specifications in this category usually goes from “Draft” into “Last Call” and then to “Final”, but not “Active” status.

So I asked to put the PR on hold – it will be better if we could have more discussions before moving this specification out of draft. What followed is soc1c’s immediate action to “dismiss” the review, citing that the meeting is sufficient to make the decision. After some back and forth and both parties got more angry, soc1c submitted a PR#196 as an attempt to remove me from the whole ECIP process.

Aztlan

Then we came to the Aztlan hard fork. It starts with this PR#199, moving Aztlan (ECIP-1061) specification from “Draft” to “Accepted”. The initial dispute was on the ECIP number – as we couldn’t figure out whether the specification we actually accepted in the meeting was ECIP-1061 or ECIP-1072. soc1c’s argument was that we should only have one ECIP for a hard fork, but not any competing ones. My argument was that at that time ECIP-1072 had the final specification we agreed on, but copying it back to ECIP-1061 (which had the sad effect of making ECIP-1061 and ECIP-1072 identical) would not be a good idea. This might have been a normal argument that would have been resolved like everything else we had in Ethereum Classic community. However, soc1c decided to do something highly unusual – instead of engaging in the discussions and try to persuade the other side, he chose to force merge the PR by using the privileged “dismiss” functionality in Github. This was where things went out of hand.

The whole thing then quickly turned into a drama, to be what is known as the ECIP-1061 vs ECIP-1072 debate and people have already started to pick sides. Bob Summerwill, the ETC Cooperative executive, first decided to support ECIP-1072 but later switched to supporting ECIP-1061. Employees from ETC Labs mostly supported ECIP-1061, as soc1c is also affiliated with them. Later, I decided to withdraw ECIP-1072 and in a later meeting, agreed to move with ECIP-1061 as a compromise.

Accountability

The drama of ECIP-1061 vs ECIP-1072 might have been over, but the controversies had not. My concern was on the power of “dismiss”. In the ECIP repository, we have many cases where more than two people from the same organization have write access. This is true for ETC Coop, true for ETC Labs, and true for many other organizations. If it becomes a norm in using “dismiss” button like what had happened in ECBP-1076 and Aztlan, then it will be a great centralization risk. Those organizations will practically be able to merge any changes into ECIP no matter how many objections there are.

Irregular Process Transition

As a result, I created PR#220 as an attempt to confirm that the “dismiss” happened in Aztlan ECIP-1061 was an exception and against the process, but not a norm.

This is when people started to take sides and when it went out of control. One or two people who still thought this was about ECIP-1061 vs ECIP-1072, which was quickly clarified. However, a few people started to argue that the “dismiss” happened in Aztlan ECIP-1061 is justified, and even went as far as saying ECIP-1072 was against the process, this also included Yaz, the person who approved the PR that merged ECIP-1072 into master.

In the exchange, I also mentioned some practical issues that those force merges might result into, for example, higher likelihood of flawed specifications.

Pseudonymization

To my surprise, later there was attempts in shifting the topic, from something on process, to “doxxing”. I was accused of using soc1c’s real name instead of his handle in ECIP-1000’s editor list. This rather comes to a surprise of me, because not only was the editor list already merged 6 months ago (which everyone agreed on, including soc1c), but also soc1c’s real name has been well-known in the community, to the point that even soc1c himself uses his real name frequently before the controversy happened. As MiKo, the ETC Discord administrator, has put it:

From my perspective, just being on calls in discord. There was always a connection of soc1c === Afri through the public conversations here. IIRC there was a push to try and keep his name out of association with ETC early on, but as I recollect, we always knew Afri === soc1c.

All things considered, you can imagine how I find that argument of “doxxing” quite absurd. I raised the issue, alongside with some other concerns on how we can make editors take responsibilities when they’re pseudonymous. However, all of those concerns also quickly met with soc1c’s “dismiss” button again.

Design Flaws in Aztlan

In December 2019, I did an additional round of review and wrote down some design flaws contained in Aztlan ECIP-1061 on Core Paper. It was apparent to the whole ETC community that those design flaws will seriously damage the effect of the hard fork. Leaving them unfixed, Aztlan would not really be useful.

At that time, ECIP-1061 was already in “accepted” status. In usual terms, that means clients can start to implement it. The specification, under “typical paths”, cannot be changed. In addition, it can only be moved to either “final” or “rejected”. This is indeed also how it worked in Ethereum (see Constantinople and Petersburg hard forks).

Immediately after the flaws were published, a proposal from ETC Cooperative quickly emerged, aiming at specifically allowing ECIP-1061 to be able to revert back to “draft”. Fortunately, that proposal was turned down by the whole community.

However, it is still unclear currently how the actual fixes are going to be applied. There were still strong push from the side of who originally supported ECIP-1061 (ETC Cooperative and ETC Labs) in keeping the original hard fork date, despite the fact that the new fixes will require additional time for review and implementation. This is something I have been strongly questioning them. The whole thing feels like a rush, and it has been really supicious to me whether their motives in keeping the original date is for the security of the ETC network.

Attempted Expel

In January 2020, an effort was made by ETC Cooperative and ETC Labs to “expel” me from the ETC ecosystem. They presented two reasons:

  • I was accused of “doxxing” in the editor list of ECIP-1000.
  • I was accused to be too rigid in interpreting the ECIP-1000 process and in “blocking” PRs from merging by people, mainly ones by employees of ETC Cooperative and ETC Labs.

I find both of the reasons hard to justify. For the first one, I have explained in the section “Psedonymization” – the editor list of ECIP-1000 was merged 6 months ago on which everyone agreed, including ETC Cooperative and ETC Labs. The real name of soc1c has also been well-known, and frequently used by soc1c himself. For the second one, the ECIP-1000 process is there to ensure network security in a decentralized community. Blocking PRs from merging before concerns are addressed is necessary to ensure bugs do not accidentially get applied on ETC mainnet. Not being rigid can mean some parties may take advantage of the process.

As an independent developer who does not really have any financial involvements in ETC, I can understand why ETC Cooperative and ETC Labs consider me as a “trouble-maker”. In July 2019, I played a major role in blocking an attempt from ETC Labs to “accelerate” the Atlantis hard fork, due to potential issues in client implementations (later, we indeed found several consensus bugs in Classic Geth). In October 2019, I strongly questioned ETC Cooperative’s motives in rushing Aztlan ECIP-1061, due to bypassing the process and insufficient reviews (later, we indeed found some design issues as described in the last section).

The landscape for Ethereum Classic has changed dramatically in the last year. After Igor, the founder of ETCDEV team, was pushed out of the community, independent “hardcore” developers start to fade. It unfortunately felt more and more like a cooperate thing, rather than an open source community. In the mean time, the community is also under considerable centralization risks. Out of the total 6 ECIP editors we currently have, ETC Labs controls 3, and ETC Cooperative controls 1 (the number can raise to 2 soon as Bob has declared his intention to become an ECIP editor).

I want to be in a community where I can be proven wrong, but not to be blamed by some obscure reasons like “doxxing” or “blocking the process”. I do like Ethereum Classic for its philosophical baseline, but based on recent events, I do think it’s slightly losing on what it stands for.

I hope this is not the last post I write for Ethereum Classic. No matter what happens, I wish ETC to have a good and bright future.

So Long, and Thanks for All the Fish!

Appendix: Lessons Learned

Restrict People Who Can Dismiss Reviews

Github has the protected branch feature, which restricts a bunch of things. This also includes who can dismiss reviews. If we had that protection in ECIP repository, soc1c wouldn’t be able to casually hit the “dismiss” button multiple times, and we may be able to have a more proper conflict resolution without those controversies.

Keep Names Out Of Specifications

Having named ECIP editors and named ECIP authors may not be a good idea. After all, Ethereum Classic is a decentralized community, and those names gives people false sense of power and authority. A simple change like removing the author field in specification and only keep it in “Copyright” section may move the process a long way forward.

MultiGeth Project

Unfortunately, it’s no doubt that the drama has caused ECIP process to lose a considerable amount of reputation. In the future, talking about the MultiGeth project, we will only take ECIP as reference for a section of the Ethereum Classic community. Instead, there will be a separate MultiGeth RFCs process to decide how potentially controversial changes are merged into the codebase.

Appendix: FAQ

Have you blocked attempts to withdraw/deactivate ECIP-1061?

No. I was always in the position of not supporting ECIP-1061, because its lack of reviews and bypassing the process. In the mean time, I did respect community consensus, and thus implemented ECIP-1061 in Parity Ethereum and MultiGeth. I only blocked attempts to move ECIP-1061 back to draft and enact the same specification again, because that’s an unusual path of ECIP-1000 process (and thus should not be done unless in extreme situations). In fact, if we had withdrawn/deactivated ECIP-1061, Ethereum Classic would have been in a much better position right now.

Previous: Choosing Mining Algorithms

November 19, 2019

Three criteria for Proof of Work mining algorithm selection.

Up: Classic in Orbit