The Ethereum Casper Project — Part 1/3
Introduction to blockchain consensus
This post is part of a research report conducted by BELEM for Crédit Agricole CIB in December 2018. The full report can be found at https://belem.io/research
The consensus problem emerges in the context of the need to replicate critical computer systems such as databases [Johnson 1975]. The principle is simple: if a critical system can be faulty, then replicating it can serve to tolerate a number of failures of it. This is known as a fault-tolerant system. A considerable amount of academic research has been conducted since then, in order to characterize, among other things, the types and number of failures that can be tolerated and the best replication algorithms achievable in practice.
In simple terms, the consensus problem can be explained as follows: if a system is replicated in several instances, some of which are faulty, how can we determine the actual consensus within the replicates? In other words, when faced with several results that should all be identical, which one should be chose if they are not all identical?
Intuitively, one may infer that consensus is like a form of majority vote in instances. Indeed, it is assumed that a majority of instances work properly, otherwise determining the correct state of the system would seem a difficult task. The question is, however, how many faults can be tolerated.
A fundamental aspect of the consensus problem is that it is up to the instances themselves to vote. In other words, the instances must run a communication protocol, and this protocol must guarantee convergence to a deterministic state despite the occurrence of various faults. Any external element is excluded from the field, since it would then be necessary to characterise its degree of reliability, which amounts to integrating it into the initial system to be replicated.
The problem of general consensus is complex because the solution must tolerate all type of faults such as failures, transmission delays or loss of messages, or adverse behavior on the part of certain instances. This is called a Byzantine fault tolerance. The term refers to the Byzantine Generals’ Problem introduced by L. Lamport in 1982.
The Byzantine Generals’ Problem (Lamport 1982)
A group of generals in which each one commands a part of the Byzantine army encircles a city. These generals want to come up with a common plan of attack and must decide whether to withdraw or attack. Some want to attack, others do not; what is most important is that all take the same decision because a small attack will fail for sure.
These generals can exchange messages to take a decision, but some are traitors and can lose or alter messages. The problem, then, is how to ensure that honest generals come to a joint decision safely?
This reference problem gave its name to the so-called Byzantine faults. A Byzantine fault is as general as possible — anything can happen. While Byzantine fault tolerance is adapted to public blockchains, it is often too strong (too restrictive) for classical contexts. It is used in ultra-critical systems (aviation in particular); other systems use less-general failures, such as the initial crash model which is used often. Either an instance is working properly, the general is honest, or the instance is down and does not participate in the protocol, the general does not respond nor send a message.
To solve the problem, we must first ask a precise communication model (synchronous, bounded time, asynchronous, etc.). Without going into the details, we note that there is not always solution to the problem, in some cases, a single faulty instance can systematically cause the protocol to fail. In others, a certain number of failures can be tolerated: the strict threshold of two-thirds of valid instances often shows up and appears as a limit to what can be tolerated in practice. It is noted as “> ⅔” below.
Proof-of-Work: the Bitcoin solution to the consensus problem
Bitcoin introduced a new consensus algorithm based on Proof-of-Work (PoW). However, this algorithm solves a very particular consensus problem related to what we can call an “open consensus” (or “public consensus”, but this term is confusing) that was previously little studied by companies or research laboratories. In fact, most of the research work focused on the scenario where there is a fixed number of replicates controlled by a single entity. In addition, Bitcoin introduces a mechanism of economic incentive, which Ethereum copied, that is absent from the classical research framework.
The open consensus focuses on the case where the number of replicates is large and evolves over time as participants join and leave the system, which is the case for public blockchains.
On the one hand, Proof-of-Work proposes investing computing power to receive a cryptocurrency: the security of the algorithm cannot be approached without cryptocurrency at the heart of the solution. On the other hand, the Proof-of-Stake proposes replacing the computing power expended by a security deposit in cryptocurrency.
Many questions remain unresolved for open consensus problem posed by blockchain. The Casper project deals with one of them: can we do without the Proof-of-Work and replace it with another economic mechanism based on cryptocurrency sequestration and penalties?
The Ethereum project
Ethereum was originally described in a white paper by Vitalik Buterin, a programmer involved in Bitcoin Magazine, in late 2013, with the aim of building decentralised applications. The development of the Ethereum software officially began early in 2014 via a Swiss company, Ethereum Switzerland GmbH (EthSuisse).
Ethereum offers the possibility of completely programming the transactions of a blockchain via smart contracts. While Bitcoin offers similar functionality, Ethereum is set apart by its more effective (and more centralised) governance that allows it to move faster towards its primary purpose: to be a universal platform of decentralised, trustless applications.
The Ethereum Foundation (https://www.ethereum.org/foundation) is in charge of the project governance and promotion. For the most part, Vitalik Buterin remains the face of the project, but many developers have taken a key role in its development. Among them, Gavin Wood and Jeffrey Wilcke who contributed to the creation of the platform, and Vlad Zamfir for Proof-of-Stake developments. Also worthy of mentioning are Péter Szilágyi and Felix Lange who contribute to the Go implementation of the Ethereum client. For more information, refer to the project wiki which remains the main source of information on the project. https://github.com/ethereum/wiki/wiki/. The project blog and Vitalik’s blog are also useful resources: https://blog.ethereum.org/.
The Ethereum project is open-source and free. As a result, several companies have adapted or deployed public implementation of the technology in the private setting of a corporate network.
