Some thoughts and suggestions on the ETC development roadmap

Over the past few weeks I have been thinking about some ideas about how Ethereum Classic (ETC) should develop with the available resources and community size. It looks like we have a good base of miners - especially in China. There are quite a few enthusiastic members who can write code. Exchanges seem happy to list ETC as an asset. As ETC proves to be very resilient to external attacks, wallets will soon support ETC.

So the foundation of ETC looks solid, but there are some possible conspiracies on the outside that would maliciously attack ETC or its hashrate. However, when the cost of an attack exceeds the benefits of the attack, such incidents are usually short-lived and conspiracies quickly fade. Therefore, as a community, we need to stay united on the path forward.

This post will make a few suggestions to start the conversation. My goal is not to ask everyone, but to ask what if as a thought experiment and see where it goes. Some ideas really need a lot of fleshing out, while others can be done easily. So please comment and be as detailed as possible. I'd love to see better ideas.

The Consensus Era

As we’ve heard more than once, there is a ‘bomb’ in Ethereum that forces a consensus change. Initial research on Casper seems cautiously promising, but regardless of its success, the end result is the same - miners are fired. Miners have proven to be valuable and committed to the ecosystem in the first place. It would be a shame if they suddenly lost their jobs.

Instead, I’d love to see a gradual transition towards a hybrid solution that serves two purposes. First, I’d like to see a useful proof-of-work algorithm that ties into the DApp model (which also means getting rid of that difficulty bomb). Second, I’d love to see ether holders be able to use their stake to make meaningful decisions about the future of the platform.

Several VCU researchers have proposed a formalized hybrid that I believe can serve as a foundation for this effort. The proposals by Permacoin and Spacemint have some merit in terms of the effectiveness of POW, and they have opened up a conversation about decentralized storage in the context of consensus. DApps should increase in complexity and storage requirements, thereby advancing decentralized databases and network security.

IOHK is preparing to release a whitepaper inspired by Permacoin called Rollerchains which could be a good stepping stone for this system. Somewhat ironically, we are also preparing to release a provably secure proof-of-stake algorithm next week. I guess this speaks to our agnosticism towards consensus algorithms.

In addition to changing the POW mechanism, there are some improvements to consider. The outsourcing of the mining problem has led to mining pools and cloud computing farms, and has led to the concentration of overall mining power in the hands of a few people. Andrew Miller has done a lot of amazing work to solve this problem while also allowing mining investment to become a reasonable business model.

Two other areas for improvement are Ghost and verification time. Ghost transforms the blockchain structure into a more loosely directed acyclic graph structure. Recent analysis shows that Ghost has some problems. Second, smart contracts will increase complexity, interaction, and size. Their verification is not like Bitcoin transactions. It would be great if verification time could be reduced.

For Ghost, the same authors are currently working on a replacement called Spectre which has huge advantages. I think there will be a modified form that can be installed on ETC.

Regarding verification time, research like proof of work and SNARK proofs seem to provide a good direction for contract verification to become a linear complexity class. It is an open question as to how much should be placed on the main chain and how much can be offloaded to a private SMC group, which needs to be verified through correctness proofs.

For proof of stake transactions, there are many options for organizing a system that allows stakeholders to meaningfully vote on topics such as governance issues, treasury mechanics, and adding a second layer of protection against unwanted or malicious forks. I will discuss the first two in the next section, and the last will be discussed in the VCU paper.

As a subplot to this topic, I don’t think it’s wise to solve the scalability problem while implementing a new consensus algorithm. I think solving the scalability problem requires the organized use of evolving cryptography, overlay protocols, and a proliferation of market mechanisms.

Management and the Monetary Era

Ethereum’s most important problems are not technical. The community split is the result of poor management. People think the hard fork is the best option among a series of bad options. People think the hard fork is legally necessary. However, people cannot think that the fork will not destroy the community. ETC is a large, surprising and well-capitalized minority.

We have two interrelated issues coming to ETC. With the dust from the hard fork settled, ETC needs to make a decision for its development direction and roadmap and put it into action. The Ethereum Foundation has made it clear that they will not support ETC, and a small group of the ETC community recently declared independence, ending the marriage and going their separate ways.

Therefore, ETC needs some form of decision-making body and funding mechanism that is sustainable. I also added that the system must prevent the formation of a cult of personality and cannot be dominated by a single centralized entity, otherwise what is the point of breaking away?

The good news is that decades of innovation have created a nice pipeline of ideas that can provide a huge amount of growth, experimental data, and resistance to corruption. I’ll mention three of them.

First, Dash has introduced a treasury model. In short, the Coinbase reward for each block is divided into three pools (45, 45, 10), 45% goes to miners, 45% goes to a pool called masternodes, and 10% goes to a treasury pool. Anyone can make a funding request to the treasury for a small fee, and it is settled on a monthly vote. The masternodes vote on the proposals. If the votes in favor exceed the votes against by 10%, the proposal passes.

Anyone with at least 1,000 dash can become a masternode, and there are currently more than 4,000 active nodes in the network. The website provides proposals and node information. For example, this proposal is to pay the core developers of the system. Another passed proposal is to add tilting support to the Dash slack. When I recently joined their slack, I received my first dash as a tip.

The dash model needs a proper game theory and information security analysis, but I think the idea has merit in principle. In addition, it appears to be a novel solution to some common problems that all open source protocols suffer from. IOHK will study the dash model and publish a white paper on the results of the study. I hope to be able to improve and modify ETC to strengthen funding for Dapps, core development and academic research.

Second, in addition to soft forks and hard forks, there needs to be a mechanism to evolve the ETC protocol. Arthur Breitman's Tezos system, based on Peter Suber's Nomic, provides a potential solution. The basic idea is to treat a cryptocurrency as a combination of three different modules: consensus, network, and transactions.

The Tezos model provides a mechanism to formalize these modules and then propose a new configuration to stakeholders. The assumption is that all meaningful configurations can be expressed in this way (a completeness assumption), and second, that the system will evolve to be more competitive if it is properly parameterized at installation time (a productive evolution assumption).

Arthur has also indicated that he plans to release some Ocaml code that covers some or all of the Strange Loop pattern, and we look forward to studying the feasibility of the system. The concept looks great, and it provides a very good mechanism for upgrading the protocol in an organized and methodical process.

Finally, Ralph Merkle proposed the idea of ​​DAO democracy. Merkle recently drafted a well-written white paper. The basic idea is that inspired by futarchy, we should separate value from belief, and then create an incentive system to get the most knowledgeable stakeholders to predict the future, but not let them play a direct role in execution.

The specific mechanisms for how this will eventually be achieved include the use of prediction markets and other mechanisms. But I won’t add much to the whitepaper and interview. I will just say that the Merkle idea looks much brighter than the Tezos concept.

Instead of a direct or delegated stakeholder voting process to modify the protocol, people can use votes with the highest predictive utility in the protocol to evolve the ledger. Some restrictions must be added to protect the original social contract (think of the 10 commandments of this system). The model requires some training, starting with the prediction market mechanism, which is just a reference, not a command.

Regarding monetary policy, Ethereum was not designed from the beginning to be a store of value, but rather a source of computational fuel. The pivot to proof of stake will change monetary policy, making it more attractive from an inflationary perspective. However, ETC needs to decide its own path.

If we stay in mining mode, then I propose using a decay mechanism similar to the Bitcoin system. It would be nice to do a comprehensive literature review to see if any white papers have been written about this model, and if there is a better way to benefit miners than a sudden coinbase reward halving. It would also be good to consult with miners in the ETC community to see what policies they prefer, and whether they would support a Dash-style vault model.

The era of code as law

If your philosophy is that code is law and you must end up with results from code execution, then you should have some strong guarantees about the correctness of the results. The topic of code verification is very rich, filled with many interesting techniques and tools. The most concise text on this topic probably comes from the book Software Foundations by Benjamin Pierce.

Despite the richness of the topic, it is not a simple proposition to solve the correctness problem. There are actually three levels of the problem: smart contracts, compilers, and virtual machines. At the smart contract level, we need to have a functional DSL with direct proofs, there was a recent paper using Idris for this purpose, and the work done with Haskabelle is very promising. It would be very nice to have a metalanguage to formulate the intent of the contract. The Prolog community may have some answers in this regard.

Smart contracts run on virtual machines. Bugs or artifacts that reduce security or correctness are a flaw in the compiler and should not occur given the intent of the paradigm. Therefore, it seems prudent to perform a fairly detailed analysis of the quality of the compiled program. Inria's CompCert project is such an example. This provides a functional DSL
This is an order of magnitude simpler to do.

Finally, the nature of the EVM is beyond my knowledge, I'm sure there are wonderful theories that produce spectacular guarantees, but I can't offer much advice, my best advice is to limit the development of the EVM to what the wider virtual machine community is doing. It would be wiser to move the EVM to run on something better understood and supported like the JVM. This shift would also allow developers more language freedom.

In summary, paradigms come with costs. Code is law carries a high burden of correctness. This requirement at least acknowledges the need for better pedagogy and a reference library for developers to validate smart contracts. At best, it will require careful observation of best practices from mission-critical software and heavy investments to implement these practices.

Summarize

If you've made it this far, then I must thank you for reading this. This post is just a suggestion to start a conversation in the community. I'd like to see better and more formed ideas. I'd also like to see these ideas turned into a cohesive, realistic, understandable roadmap that explains past mistakes.

At any time, I am willing to be part of the development roadmap discussion and look forward to helping with its implementation.