Moving parts within the Ethereum Classic ecosystem

There has been a lot of confusion within the Ethereum Classic ecosystem about the multiple Github organizations and how everything is meant to fit together.

Where is the client code? How do we coordinate between different client teams and other ecosystem participants on how to make updates to the protocol? Where do the key community resources live?

Websites

EthereumClassic.org is the canonical best "landing site" for Ethereum Classic. The DNS entry is owned by Anthony Lusardi, Ethereum Classic OG and ex-Director of the ETC Cooperative, but the actual content is developed collaboratively at github.com/ethereumclassic/ethereumclassic.github.io.

This is a homecoming of sorts, because this Github website served the ETC community from July 2016 until April 2018. It was replaced by a new WordPress site built by ETC Cooperative, which looks great, but the content is already outdated. Only the admins could update it. We will bring the Github based content back up to date and then improve the design.

Other important websites are etccooperative.org, etcsummit.org, etclabs.org, etclabscore.org and iohk.io.

Social media and chat

The ETC Discord is the #1 place on the planet in which to talk about Ethereum Classic. Please do join us there! Crypto Twitter is always popular, but can be a "talking shop" where not much actually gets achieved. Key accounts are twitter.com/ETCCooperative, twitter.com/eth_classic (operated by IOHK), twitter.com/etclabs | twitter.com/etclabscore and twitter.com/ClassicIsComing.

There are other communication channels - Reddit, Telegram, Facebook and more, but they are generally pretty poor quality and might be worth skipping. Other countries and language groups have their own communication channels.

ECIPs (Ethereum Classic Improvement Process)

The ECIP process is the single most important thing for all ETC ecosystem participants to understand. It is our means of reaching human consensus on any changes to the protocol. Proposing or making changes to the ETC protocol outside of this process is extremely ill-advised, as it will be seen as an attempt to subvert the network and as an attack against the community. On a lighter note, it is very easy to understand the process and to participate. Anybody with an interest can join in.

There is an excellent web view onto the active ECIP proposals at ecips.ethereumclassic.org, which is self-describing. The ECIP-1000 Meta ECIP describes the workflow for ECIPs, and any changes to the workflow should be proposed as modifications to ECIP-1000.

Ethereum client implementations and Github

A key decision which the Ethereum team took back in 2014 was to have a neutral specification of the protocol together with multiple implementations of that protocol. That facilitates a free market in client implementations and encourages decentralized development. They wanted to avoid what happened to Bitcoin, where the initial implementation, Bitcoin Core, became a reference client and the defacto specification for the protocol. Alternative Bitcoin implementations never get much market share, because they must be bug-for-bug compatible with Bitcoin Core. Not so for Ethereum and Ethereum Classic, where we have always had multiple client codebases.

Geth is the most popular Ethereum client. Its development is funded by the Ethereum Foundation and developed in github.com/ethereum/go-ethereum. Directly after the time of the DAO fork, Geth supported both Ethereum and Ethereum Classic, but that support was dropped pretty soon afterwards. There there was little or no demand for Ethereum Classic support, with most of the ETC community preferring to use Classic Geth.

That was a world ago, with most people in both the Etherum and Ethereum Classic communities having arrived long after those events. Many individuals within the ETC community would love to see built-in support for ETC restored to vanilla Geth, whose development team have proven themselves to be unsung heroes time and time and again. They continue to squeeze better and better performance from the code.

Classic Geth was originally a fork of Geth but diverged over the years until there was no hope of the codebases ever reconverging. It was developed by the sadly defunct ETCDEV team which folded in December 2018. Igor still continues to work on Emerald Wallet. ETC Labs funded ChainSafe to refresh Classic Geth for the Atlantis hard fork, which will be its last outing. That has been far from a smooth ride, but many ecosystem participants still use it. Classic Geth is developed by ETC Labs in github.com/etclabscore/go-ethereum.

MultiGeth is a downstream fork of Geth which adds support for many different species of Ethereum networks. Unlike Classic Geth, MultiGeth has always intentionally stayed very close to Geth, with regular downstream merges. Given that the majority of the changes in MultiGeth are related to configuration for other Ethereum networks, it would make sense to audit the differences against Geth for consideration for upstreaming, so that all Ethereum networks could work from the same Geth codebase, rather than being forked for a difference which can easily be captures using parameterizations and conditional code, as Parity Ethereum has done throughout. Wei Tang (AKA sorpaas) is the MultiGeth maintainer, with development happening in github.com/multi-geth/multi-geth. The ETC Labs Core team has indicated that they intend to migrate their client development efforts from Classic Geth or MultiGeth during the next hard fork, with Classic Geth finally retired.

Parity Ethereum was the first truly successful Ethereum client developed outside of the Ethereum Foundation, when Parity Technologies (originally Ethcore) developers who had previously built the cpp-ethereum client left and built a brand new Rust client, based on their experiences at building a C++ client. Both of these teams were led by Gavin Wood. Now, sadly, it appears that Parity Ethereum is reaching the end of the line, with funding having been minimal since 2017. Can the code find new life, or will it die? It remains to be seen. Development occurs in github.com/paritytech/parity-ethereum.

Hyperledger Besu is perhaps the single most exciting development in the Ethereum client landscape, with world-class licensing and IP protection, governance and workflow, due to the choice of Hyperledger as its home. It is implemented in Java, making it hugely appealing to enterprises. It has been developed by the PegaSys team, spawned from ConsenSys, with a large and incredibly talented team. It supports Ethereum mainnet and permissioned scenarios and is compliant with the EEA Enterprise Ethereum specification. All of these reasons are why the ETC Cooperative chose to fund ChainSafe to implement ETC support in Besu, as the very first new feature being contributed to Besu within the Hyperledger workflows. Besu is now developed in github.com/hyperledger/besu. It was previously called Pantheon, and has been in development since early 2017.

Mantis is a Scala client built by IOHK from scratch following the birth of the Ethereum Classic network. The motivation for this, Charles Hoskinson said at the time, was to give the Grothendieck team the opportunity to really learn the protocol inside out in a way which forking another team's code does not. In the middle of 2018, Charles announced that the Mantis team would be adding Ethereum support, and it appears that much progress was made towards that goal, but development was defunded at the end of 2018, and Mantis did not participate in the recent Atlantis fork. We hope that they will return to battle soon. Development occurs in https://github.com/input-output-hk/mantis.

The github.com/ethereumproject organization, which was forked from github.com/ethereum organization at the time of the DAO was finally retired in October 2019, just ahead of ETC Summit 2019, bringing the confusion between github.com/ethereumproject and github.com/ethereumclassic to a close.

Igor continues to maintain the excellent Gastracker.io website, which has a node stats page showing the market share between the various clients for ETC.