This post serves as a timeline of what happened during the recent Ethereum Classic controversy. The event caused Aztlan hard fork (ECIP-1061) being cancelled because of specification flaws, and testnets Kotti and Mordor being broken for weeks.
The goal of this post is not to judge right or wrong, but to provide references of the controversy history, drama, blame game, and everything else. I hope what readers take from this post are lessons learned in the hard and daunting task of managing a specification repository for a decentralized community.
There are several people involved in the timeline below. We’ll be
addressing everyone by their first names. Wei (who is me, developer
and volunteer for Ethereum Classic), Afri (who works for ETC Labs,
known by handle
q9f), Bob (who works for ETC Coop), Yaz
(who works for ETC Coop) and Donald (who is coordinator and volunteer
for Ethereum Classic).
On June 28th 2019, the first formal ECIP process (ECIP-1000) was
merged in Ethereum
Classic repository. Five editors were proposed, addressed by their
real names, and all of them agreed to join. This includes
who is also known by the handle
soc1c. The real name of Afri
soc1c), however, later turned out to be the point of the drama.
On November 15th 2019, Afri made an attempt in PR#176 to add several EIPs in to one of the planned hard fork “Aztlan”. The PR was put on hold by Yaz and me for several days, because at that time not everyone agreed to add in those EIPs for the hard fork. In fact, the specification added by Afri later turned out not to be the adopted version. At that time, the hard fork was even not formally discussed yet.
On November 21st 2019, Afri made an attempt in PR#194 to move one of his other proposals ECBP-1076 into Active status. In my opinion, this PR was problematic in several ways, so I submitted a “request changes” review:
- There were still issues unaddressed in the draft specification. ECBP-1076 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 in Github issues, 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.
Afri, however, did not look like willing to discuss those concerns. The review was dismissed by Afri citing 80 minute call and rough consensus. Immediately after that, he made an attempt in PR#196 to remove me from ECIP-1000. Both PR#194 and PR#196 were later closed.
This was the first time when someone tried to resolve conflicts by dismissing another person’s objection, and by attempting to exclude people from the process. As readers will soon learn below, it later happened again. Fortunately both of those attempts failed.
On November 27th 2019, Afri made an attempt in PR#199 to move Aztlan hard fork into Last Call status. This is when the air went hot. 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, to which I submitted a “request changes” review.
Afri, again, did not look like willing to discuss the issue. The review was quickly dismissed by Afri citing it’s “resolved” without any further explanations.
Afri’s action resulted in lengthy discussions about this issue. Irritated by Afri’s repeated dismiss of other people’s objections, I submitted “irregular process transitons” in PR#220.
In addition, I also raised my concern whether the hard fork actually got enough technical reviews so that it is safe for Ethereum Classic. Yaz, at that time who were supporting ECIP-1061, replied me with the following comments:
You can ask me about the safety properties of the hardfork, but you’re just changing the subject to show off how much you know about the technical details of the hardfork in question … Stick to the subject matter.
Another main argument from Afri and Yaz was that there should only be one ECIP for a single hard fork.
On November 29th 2019, realized that I could not get people in ECIP process to discuss the technical aspects of the hard fork, I posted a message on Twitter. I made it clear that I do not think Aztlan is a good hard fork and may contain flaws.
Around December 2019 to January 2020, the topic suddenly shifted by
Bob, claiming that in ECIP-1000 I used the real name of
that was “doxxing” and “against CoC”. On January 20th 2020, Bob submitted
PR#267 to remove
the real name of
soc1c from ECIP-1000.
Bob’s claim of “doxxing” was quite loud at that time, but it really is
quite absurd to me, because not only was the editor list already
merged 6 months ago (which everyone agreed on, including
explained in the beginning of this timeline), but also
name has been well-known in the community, to the point that even
soc1c himself uses his real name
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 ===
On December 20th 2019, although I was still objecting Aztlan hard fork, believing Bob and Afri had made it as community consensus, I implemented it in MultiGeth. After the implementation is finalized, I suddenly realized there may be some issues in EIP-1884 of Aztlan, so I did some digging on the same day, and found several issues, raising them to the community.
During January and February, several additional issues of Aztlan were found. Those issues also caused testnets Kotti and Mordor to break for several weeks.
On January 24th 2020, Donald submitted ECIP-0001 as the second attempt to remove me from ECIP process. One of the main reason was the “doxxing” argument, claiming I was “abusing the process”.
On February 20th 2020, Yaz accused me of “implementing the flawed Aztlan specification in MultiGeth and OpenEthereum”. I find the accusation quite absurd, because from what actually happened to me, I discovered the specification flaws through implementations. I wrote a tweet thread as explanation. I also wrote some posts on what I think those accusations are all about.
On February 24th 2020, Afri posted PR#299 and PR#300 as two new options for the hard fork. To me, one interesting aspect of this is that two option EIPs are posted, yet during Aztlan drama one of the main argument from Afri was “only one EIP per hard fork”.
On February 26th 2020, Aztlan hard fork was cancelled. Phoenix (new) hard fork was the replacement.
On March 18th 2020, Donald submitted PR#313 withdrawing his attempt to remove me from ECIP process. It was cited that there were not enough consensus.
On April 1st 2020, Afri wrote a
revealing that the handle behind
q9f is also Afri.
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.
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.
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.
Aren’t you the author/co-author of both ECIP-1061 and ECIP-1072?
Yes. This is what really makes things ironic that the specification author’s view to not support it and not move it forward being dismissed.