The HardFork drama is an opportunity for Ethereum Classic to fixe technical challenges

 As some of you, I discovered the Ethereum project with the Homestead edition of its blockchain, and I got quickly enthusiast about the technology and its potential, and started by investing some money to buy ETH, but mainly investing time to read about the technology, learn the Solidity language, trying to build some smart contracts and play around with the tools. I was also planning to invest in TheDAO project but finally I was a little bit scared about all the amount of money put there. I was expecting something like $5M to $10M, but when it reached the $20M in less than 2weeks, I got afraid and though that it was an extreme hype movement that would collapse when trading of DAO tokens will start and people will lose their money and it will somehow have the same end as BitShares.   

 Nevertheless, I still profoundly believe in the DAO concept. 

So with TheDAO drama, the HardFork and the emergence of the Ethereum Classic chain, that I can say today that I’m fully supportive of. Particularly after what the Robin Hood Group or White Hat Group tried to do to kill the Ethereum Classic chain, and steel the remaining ETC from TheDAO hack and to transfer them to Ethereum Foundation without getting the Ethereum Classic community approval. 

From this experience, I learned that Ethereum is facing strong technical challenges, and we, as a community, need to find strong solutions even if this can imply redesigning important parts of the project. 

The Ethereum Virtual Machine challenge:

  I believe that it was not a good idea to start the Ethereum project with a specific Virtual Machine, the EVM that is not fully mastered. The goal of ethereum is to build The Worl Computer with a Turing Complete machine to allow people to build any kind of applications with secure, unstoppable and decentralized behavior.    

 The architecture of the ethereum blockchain does not allow a simple and easy process of updating smart contracts, especially when these ones embed complex data structure and funds. So, this forces the developers and the community involved in each Dapp to spend tremendous time on thinking about the design, learn a new and incomplete language (Solidity) and asking people for auditing the code. So the need of tools for Formal Verification become critical, especially when the amount of money engaged is important (i.e ~$160M for TheDAO).

Thus, I think the Ethereum Classic community should consider changing the EVM to more robust and approved machine with a complete language and already available Formal Verification tools. Charles Hoskinson spoke about the Java VM as an alternative, but there is also a less known language called Ada that is widely used in RealTime, Embedded System, Safety and Security-critical applications, and that have a full stack of tools to build secure code.
It may deserve a brief study.

The transactions form challenge:

As Ethereum is designed now, Sending Ether from and address A to an address B is a transaction, Calling a certain method in a smart contract is also a transaction. And both of them rely on the Proof-Of-Work consensus algorithm for validation. This is for sur not an efficient way of doing things.

For example and according to ethernodes.com, there are approximatively 6000 nodes in the Ethereum network, so if a method call needs 1000 instructions then this would result in a 6000000 instructions in order to include the transaction in a new block.

So let’s imagine now that we have 1000 Dapp deployed on Ethereum, with thousands of users for each Dapp and tens of thousands of people doing simple Ether transfer transactions. This would result on huge network inefficiencies (energy consumption, mining hardware wastes, latencies...).

 In my opinion, I think that we need to redesign the transaction types in addition to change on the consensus algorithm. So mainly have ContractTransaction and EtherTransaction, where ContractTransaction are created by the protocol whenever it detects a call to a method a smart contract and send this transaction to ContractTransactionPendingPool and where the validations are done via a Proof-Of-Stack algorithm. While EtherTransaction are created by the protocol in the case of simple Ether transfer and validated via a Proof-Of-Work algorithm.

This may also need the redesign of the blockchain data structure and chaining process to allow the chaining of blocks from the two pools or some other structure.

I also believe that there many other technical challenges sourrounding there, so feel free to comment, suggest new ideas  and share. Ethereum Classic has a very good opportunity to reshape the Ethereum project and we as a community need to help, even if only with ideas, to get things right.