Before the NXT cryptocurrency I used to be a developer of a distributed system crawling articles around the Web and building Kohonen’s self-organizing map filled with them. During those days I read a lot about CAP theorem. The theorem states pretty common in everyday life principle “you can pick only two out of three” (e.g. in the “Price – Quality – Delivery” triangle). The three desirable options of any distributed system are consistency, system availability and tolerance to a partition fault. And you can pick only two of them.
CAP & Distributed Ledger - The Problem
In case of a distributed ledger CAP properties mean:
- Consistency - all nodes have the same ledger at the same time
- Availability - the network accepts transactions at any time
- Partition tolerance - the network is resistant to a node(s) failure
The sad thing is that widely acceptable currency couldn’t exists without all the three conditions met. Nobody will use a currency if it’s offline during data synchronizations(CP system). Nobody will use a currency if network is vulnerable to a node failure(CA system). And for sure nobody will use currency if different nodes operate with different ledgers(PA system).
The Blockchain Solution
Blockchain is the elegant bypass of a CAP problem for storing a distributed(& decentralized) ledger. So transactions are grouped in blocks, and you can trust block only after some number of confirmations(i.e. number of new blocks added after). In case of Bitcoin, you can rely on transaction just included into the blockchain after 6 confirmations(with a negligible probability of transaction being reversed even after that), in many practical cases 2 or 3 confirmations are enough though (see original Nakamoto’s paper for precise numbers satisfy your needs).
So in terms of consistency the blockchain is about very weak consistency! Working with Riak and other databases with weak consistency, I’ve never seen anything like that.