Some Thoughts on ETC

As the past few weeks in ETC land have been filled with a bit of drama and uncertainty that is bubbling into the public domain, I've decided to collect my thoughts into a single document. First, it's always a rude awakening being reminded how much FUD, trolling and in some cases genuine hate the internet brings out in people. I suppose it's a toxic blend of anonymity and lack of social pressure to behave like reasonable human beings.

This said, I've seen a lot of good people step up over the last few days in particular with good arguments, support or at least constructive criticism. Such things give me hope. And I continue to hope that we can be civil as a community despite the idiocy of a few bad actors.

Now on to my points. There are three that I'd like to discuss. First, the ECIP 1017 monetary policy proposal. Second, IOHK's treasury proposal and future roadmaps. Third, a broader point on community management and governance.

With respect to ECIP 1017, I think Snaproll has done a great job producing something fair and timely for our community. I'm in full support of it and I'd like to see it approved and implemented. My reservations actually don't come from a desire to install a hook for a treasury, but this of course would be nice, but rather a lack of process for communicating with all the major stakeholders.

ETC isn't just Slack or Reddit. There are other communities that are directly responsible for the success of the project that either cannot or will not use our standard communication mediums. Second, they, in some cases, do not speak English. My primary reservation is that we cannot change the social contract of ETC without their consent or we have every right to expect a surprise fork just like the EF endured.

IOHK has been proactively trying to broadcast the need for a MP discussion in places like China and we've even sent Carlo there in person. I'd love to see both Snaproll and Elaine enter this market as well for several face to face meetings. Yes this process takes time, but it can and should be expedited.

In reality, if conversations began now, then unless there is strong opposition to ECIP 1017, I think we can get final approval in mid-March and then it's a settled matter. Things could go wrong, but as with Die Hard, I've been amazed at our ability to pull together when absolutely necessary.

Second, IOHK has recently released a treasury proposal. I would like to apologize for it's poor and confusing release to the general public. We intended on a soft discussion that would gradually solidify over time. It was not meant to be a papal bull encased in immutable canon law once given.

I want the community to understand a few points. First, we are all paying an inflation tax at the moment to miners. This tax is in the form of coinbase awards and it's a standard notion as we consider it for a common good. It's clear to those in the game theory business and those who understand that mining alone isn't sufficient to maintain a healthy network that we need to have a serious discussion about other incentivized behaviors.

People need to store the blockchain for the system to work. People need to relay data upon request. There needs to be bootstrap nodes. There needs to be developers maintaining the protocol. There is community management and marketing. There are DApp developers who need capital to deploy contracts on our network.

If the protocol cannot make financial accommodations for these actors, then we face either the unpredictability of volunteerism, which has never historically scaled (Here's a great article providing an elucidating example) or we endure the soft federation of patrons buying influence through subsidies. The latter is more likely and inevitable.

My purpose in bringing up the treasury discussion is to make sure we in the future social contract of ETC understand the need to diversify incentives beyond mining. A treasury gives the stakeholders of the system a much larger role and provides the competitive advantage of guaranteed capital for long term projects. More abstractly, let's try to cut the inflation pie into more than a single piece for a single group.

My second point is that I do not believe that it is wise or sane to implement a treasury system with a smart contract. It will take likely 6-12 months of research and development to build a proper peer reviewed and tested treasury system (something the DAO never did) and we will likely have to introduce new cryptographic primitives, data structures and other pieces of complexity to implement this system. The earliest it can be safely done would be Q1 of 2018.

Utilizing a smart contract for a global system would make it bloated, force development in a sub-optimal language solidity and greatly restrict our flexibility. It makes no more sense to me to embed a treasury's mechanics into a smart contract than to embed our consensus algorithm into one.

Third, I would like to remind everyone that one of the reasons the hard fork occurred is that the core entity pushing it has absolutely no accountability to the stakeholders of Ethereum. The EF cannot be defunded or compelled to behave in a certain way from the holders of Ether. It's effectively like a supreme court justice in power for life without fear or recourse for actions beyond brand damage.

Decentralizing the capital available to the ecosystem and making it flow in stages with contingencies and revokeability would completely change the social dynamic. An entity like the EF would be forced to ask have they really achieved proper consent from the community for an action. Lack of consent wouldn't breed anger, it would remove capital.

This mechanism is an extremely powerful governance tool and ought to be explored. ETC was founded with the goal of minimizing centralization and strongmen pushing us into bad directions.

My last point, with respect to the treasury, is that we should dream big with ETC. The reality is that smart contract competition is going to get extremely tough in 2017. Tezos is launching with smart contracts. Rootstock will be a player in the second half of this year. Ethereum continues to evolve rapidly. There will also be many more.

If ETC wants to stay relevant and survive, then we cannot be the litecoin of smart contracts. We need to seriously differentiate ourselves from Ethereum and the rest in class. This means we need to get used to discussions about new consensus algorithms, better and more secure smart contracts, decentralized funding and other topics. The advantage is that we have the total freedom to pursue any path, but we need to pick one.

To me, the worst thing we could do is be overly conservative. I cannot understand how just being Ethereum that stuck to mining will make us competitive at all. Rootstock will have far more hash power, the stability of the Bitcoin network and one of the top InfoSec minds in the world behind their client (which is also five times faster than the original EthereumJ client they forked and modified).

I've had a chance to read so many great papers that provide a lot of cool insight into how we can do something special. For example, here's one on adding concurrency to smart contracts jointly published out of Yale and Brown. Loi lou and his co-authors published a wonderful set of recommendations for smarter smart contracts here. There are dozens more.

IOHK has two research centers and soon more. We have some of the best cryptographers and PLT folks in the world working with us on a daily basis. We are willing to put in the legwork to build out an extremely competitive roadmap for ETC to be a best in class protocol, but we can't and won't invest the time and effort for this work if the community simply wants to litecoin.

In any event, we'll continue developing and release the Grothendieck client without any divergent code from the Geth and Parity clients maintained for ETC. Whether we continue supporting this client through 2018 and beyond will be totally dependent on the roadmap ETC settles on.

Now on to my final topic, community management and governance. When ETC first began, I quickly hired two people. Christian Seberino and Carlo Vicari. They serve totally different, yet complimentary roles. Christian is subsidized to write at least one article a week on a blockchain topic related to ETC. We have no editorial control over his work nor have ever asked him to support a particular idea.

I realized that as our roadmap evolves, it's going to be important to have several people in an objective explainer role similar to Andreas for Bitcoin. Our relationship with Christian is to bootstrap the development of these characteristics in the community.

Carlo is a traditional community manager. He's responsible for accurately broadcasting news and events, creating more positive interactions between community members and also dealing with crisis control when bad events happen like unexpected bugs, security flaws or hacks. We have limited oversight over Carlo and he mostly operates autonomously. The exception is usually when I ask him to travel to places like England, Japan or China to talk to a particular group like the London MP event for example.

It's important to understand that while I pay Christian and Carlo, they ultimately work for you. They are resources for the community and exactly the type of roles that a treasury could eventually cover.

The last thing I'll mention is the core/reference client issue I've had with the Geth team. It's extremely distasteful to me that some members of this community have decided to view the formalization of this team to mean the IOHK is somehow on the peripheral of core development or is less important to the community than Splix or Elaine.

Let me be blunt. Taking someone else's code, making some modifications does not make you a core developer of a project. No one has nor should have a mandate to be in charge of the reference client for ETC. As the weekly Grothendieck stand-ups should make very clear to the general public, Ethereum is an extremely complex protocol.

While I have tremendous respect for the work the ETC devs have been able to accomplish, it's necessary to point out that it took Jeff, Vitalik and Gavin nearly two years to launch the Frontier client with the aid of dozens of contributors and much security auditing. Even still, they got a lot wrong that had to be fixed over another year.

No one in our community has publicly demonstrated an equal level of competency as the EF's core developers. This observation is not an insult or an attack on intelligence. It's a merit based fact.

In my view, the only way to demonstrate competency is to build a client from scratch or spend many months of heavy refactoring of the original source base. Perhaps this view is misguided, but it's the one we adopted at IOHK. We could have hired Go or Rust developers and contributed to the currently used clients, but I felt it would eventually lead to a disaster where a lack of experience led to a bad update.

This view means that Grothendieck has not been able to participate in the recent two hard forks or contribute code yet to the clients currently in use. Some have inferred from this lack of contribution that we are thus worthless to the effort or do not deserve to be considered core developers. It's hurtful and counterproductive to the community.

Seven full time Scala developers each with a decade or more of development experience is not a cheap proposition. IOHK made this commitment and will see it through. I personally spent many hours- usually late at night- reviewing resumes of candidates for the Grothendieck team. I didn't have the time for it, but I found it because I really do care about this project.

My point here is that there is no core client or core developers. Anyone who claims this mandate or infers or implies it is trying to centralize the project. I am directly asking the geth team to stop using core or reference when discussing their efforts. I am also directly asking the community to reject any attempt to establish a reference client.

There is a formal specification for Ethereum. It's Gavin's yellow paper. We will work to improve it and also add more detail and content. But to assert there is a reference client, in my view will lead to a small group of people having near totally control over the roadmap and direction of the project.

Thanks for reading,
Charles