Coming to Consensus Part 2 of 2
This is part 2 of our 2-part series on consensus algorithms. If you haven't read part 1 yet, you can do so here.
There are certain requirements that need to be met:
In typical centralized systems, security mostly relies on a 3rd party to do the right thing.
Blockchain systems replace that requirement of a trusted 3rd party with a smart combination of techniques, one of which is the consensus protocol (required to have logical centralization / a global singleton).
In this blog post Vitalik Buterin claims: Even if there is only one miner in the world, there is still a difference between a cryptocurrency mined by that miner and a PayPal-like centralized system.
To understand why this is the case, it's necessary to look at all system aspects underlying its security:
- P2P network: A centralized system has a single source of truth (e.g. api.paypal.com). If for some reason you don't trust that source or can't access it (e.g. because your ISP blocks it or because the service itself blocks you), there's not so much you can do about that. Behind the scenes, a service provider may have deployed a distributed network (architectural decentralization) in order to make the service more resilient against infrastructure failures and for load balancing, but since all network nodes are controlled by a single entity, it's still politically centralized.
A P2P network is both architecturally and politically decentralized (read here for a more detailed explanation of the aspects of decentralization) and doesn't hide its nodes behind a single logical one - network participants are free to peer with a set of nodes of their choice.
- Authenticated data: The term Blockchain directly relates to the concept of securing blocks by chaining them via cryptographic hashes - an idea pre-dating Bitcoin (implemented e.g. also by the Git VCS).
Additionally, transactions are authenticated by the cryptographic signature of their creators.
These data authentication mechanisms are probably the strongest pillar for security of Blockchain systems, compared to centralized systems where you usually have to trust that the data delivered by an API is correct. The only guarantee a centralized service typically gives you is that the data was not tampered with while in transport - through transport encryption (SSL/TLS).
- Distributed consensus: Eliminates some remaining issues. Even in a P2P network with authenticated data, a central coordinator for state updates could still abuse its power, e.g. by censoring or delaying specific transactions. Distributing consensus makes sure that individual misbehaving consensus nodes can't affect the system in any significant way. E.g. in a PBFT-style protocol, if a node fails to produce a block when it's supposed to, the consensus protocol will simply re-assign the task to another node, causing only a short delay instead of halting the chain.
Existing Blockchain (and similar) systems have so far shown that they are up to the task of providing security without a central authority - with hundreds of billions of USD worth of crypto-assets at stake by now.
While there have been and continue to exist all sorts of security incidents, few of them are related to consensus failures. This is despite the fact that few Blockchain systems have reached a high degree of political decentralization on the consensus layer - partly because of the reasons outlined before (see PoW in practice), partly because their consensus layer was designed to allow lower levels of decentralization due to performance reasons.
Another requirement of Blockchain systems which is becoming increasingly important is performance (in terms of transaction throughput).
The history of Blockchain started with Bitcoin, using very conservative parameters which limited max. transaction throughput to about 3 tx/s (in practice). Bitcoin showed in an impressive way that the basic idea works, it also triggered a lot of research around the various aspects it touches. The results of that research and of the experiences made with Bitcoin have influenced and keep influencing more recent Blockchain system.
Bitcoin recently also showed what happens if the demand for transactions exceeds the capacity of the system.
The search for more performance also re-ignited interest in PBFT-style protocols, which - with some optimizations - have pretty good performance characteristics with modestly sized validator sets.
ARTIS will start with Tendermint as consensus protocol. Tendermint was first proposed in 2014 by Jae Kwon in this paper and later researched more in depth by Ethan Buchman in this paper. It also underwent extended scrutiny by 3rd parties, as for example documented here.
Tendermint is a PBFT-style protocol, adapted for Blockchain applications, with focus on good performance.
It is not vulnerable to the nothing-at-stake problem and the long-range-attack (both first described in detail here) which undermined the security of early PoS implementations and are often cited as arguments against PoS by PoW proponents to this day.
Tendermint is weakly synchronous, which means it deploys timeouts in order to avoid the chain to stall if a designated proposer fails.
It can deal with variable network health by dynamically incrementing those timeouts if several rounds are necessary for a block height.
Tendermint offers instant finality and can stall if more than 1/3 of consensus nodes fail.
We believe this is a feature, not a bug, because in a situation with such a significant part of the network failing, to check what's going on and eventually intervene off-chain looks like a better idea than to just let nodes continue updating state and wait for an eventual re-org of the chain. The way the community handled the aforementioned Bitcoin chain split incident, which was ultimately resolved by coordinating miners off-chain, confirms this.
The following visualization (source: Buchman's paper) shows the state machine of Tendermint.
At each height, at least one round consisting of 3 steps (+ 2 special steps) is transitioned. If that round for some reason fails to lead to consensus about the next block, a new 3-step round with a new proposer (selected round-robin) is started. This continues until there's consensus (> 2/3 of votes) for a block.
ARTIS will be configured for significantly higher peak performance than the Ethereum mainnet in order to provide enough transaction capacity until scalability solutions like Sharding and Plasma are ready to be deployed. This was an important factor in the decision about a consensus protocol.
In order to achieve political decentralization, the composition of the validator set has the goal of achieving diversity on multiple dimensions:
- legal systems
A combination of economic incentives and governance rules will be necessary to get there.
ARTIS aims for a block time around 5 seconds and a significantly higher blockgas limit than the Ethereum mainnet - putting higher performance requirements on consensus nodes.
The exact parametrization of the chain is yet to be determined with simulations.
The Tendermint protocol is already partly implemented in Parity (which will be the foundation for the ARTIS reference client due to its superior performance).
We consider Tendermint to be a pragmatic choice for getting the ARTIS network started, but don't intend to commit to it forever.
We are closely following developments in consensus research, having a close eye for example on Algorand and Casper (research for which has split into the finality favouring Casper FFG and the liveliness-favouring Casper TFG).
Alternative approaches to limiting the power of consensus nodes, like for example the concept of fishermen (as described by the Polkadot whitepaper), will also be evaluated.
In the long term, ARTIS can leverage its unique feature of having a concept of accounts representing unique humans to build governance mechanisms which complement the consensus process without hurting performance. While other Blockchain systems are limited to deriving voting power from asset holdings (as is typical for DPoS schemes), ARTIS can add truly democratic principles (that is, 1 person = 1 vote), e.g. employing mechanisms described by the concept of Liquid Democracy.