While the ideas behind the current Ethereum protocol have largely stabilized over the past two years, ethereum’s current vision and full form didn’t come into being overnight. Since the launch of the Ethereum blockchain, its protocol has undergone a series of major evolutions and decisions. The purpose of this article is to review the evolution of the Ethereum protocol from inception to release. The extensive work done by Geth, CPpethereum, Pyethereum, and EthereumJ in implementing the protocol, as well as the application and commercial history of the Ethereum ecosystem, is beyond the scope of this article.
Also out of the question is the history of Casper and sharding research. No doubt more articles could be written about the various ideas that Vlad, Gavin, myself and others have proposed and rejected, These include proofs of proof of work, wheel assisted multichains, hypercubes, shadow chains (arguably a precursor to Plamsa), chain fibers, various iterations of Casper, and Vlader’s rapidly evolving idea of reasoning about incentives and the nature of actors within consensus agreements. The story behind these ideas is itself complex enough to warrant another article. Therefore, we will not discuss them for the time being.
Start with the earliest version. That version eventually became Ethereum, but it wasn’t even called Ethereum at the time. When I visited Israel in October 2013, I spent a lot of time with the mastercard team and even suggested that they add certain features. After thinking about what they were doing, I sent the team a proposal to make their protocol more generic and to support more types of contracts without adding a large and complex set of features.
It’s important to note that this version was very different from ethereum’s later, broader vision: it was purely focused on the technology mastercard was trying to break through at the time: bilateral contracts. In this contract, party A and Party B jointly invest money, which can then be withdrawn by both parties according to some formula specified in the contract (for example, the wager reads “if X happens, all the money goes to A; otherwise, all the money goes to B”). The scripting language that implements this contract is not Turing-complete.