The human factor in consensus on blockchain systems
Distributed consensus finding between untrusted nodes is the key ingredient in blockchain systems. Whether mining “proof-of-work” or minting “proof-of-stake” algorithms are used, the consensus established algorithmically guarantees a consistent view of the data stored in the blockchain, e.g. who owns which bitcoins on the bitcoin blockchain. Consensus algorithms in itself are not a necessarily new, but their unique setting and the way they contribute to blockchain systems were a technical novelty when bitcoin arrived (learn more in my older posts, e.g. here and here). But beyond this “technical” layer of consensus, there are more layers of consensus directly involving humans — and we don’t have a good technical solution in place for these layers. This is proving to be a problem, and is currently leading bitcoin to the brink of chaos in their debate about blocksize. Let’s take a look at the different layers before we return to the case of bitcoins current turmoil. After all, this situation is not unique to bitcoin, but as the largest, most mature system and community it seems natural that the bitcoin community encounters the problems first.
I will distinguish three concerns of consensus: (1) consensus on the data, (2) consensus on the use and usefulness of data, and (3) consensus on the communication of data.
Item (1), the consensus on the data, is dealt with by the consensus finding algorithm. It is the answer to “What data is included in the blockchain?” and answered by the miners or stake-holders in the distributed network.
Item (2), the use and usefulness of the data is the answer to the questions along the lines of “Why is the data valuable and why do we store it?”. In the case of Bitcoin, it is the function of Bitcoin as a currency, e.g. as a way to conduct transactions, or a way to store value. Without some consensus on the value of a Bitcoin, the distributed ledger of Bitcoin does not make sense. The answer to this question is often taken over by a supply/demand differential in markets, but it can also take very different forms. In Ethereum, it is not the value of the units of currency, but the value of automated contract execution that drives the value of the network.
Item (3), the consensus of the communication of data, is very critical: Every blockchain system specifies a distributed network that needs to communicate and execute a shared algorithm. To do so, it needs to speak the same language, e.g. broadcast and receive messages between the network participants, and needs to agree on the same data format. It ranges from very trivial formatting issues (e.g. imagine someone storing date in a dd/mm/yy format and someone else in a mm/dd/yy format) to fundamental questions like “What messages are valid?”, “What messages need to be broadcasted?”, or “What makes data on the blockchain valid and how to identify illegitimate data on the blockchain?” (e.g. double-spending attempts in Bitcoin).
The answer to these questions is typically hard-coded in the source code of the software. The answers were pre-defined by the developers and their implementation. This gives the developers a very central and important role in most blockchain systems. Yet, many implementations are open source. Everyone can make changes and run their own, changed version. But without other nodes accepting, acknowledging and respecting the modification, the new implementation will not have any effect: If it changes the data format on the blockchain, all participants running the original software will discard the data. If it changes the network communication format, other nodes might misunderstand or flat-out discard messages from the modified client. It comes down to the spread of the modified software: If a majority of participants adopt the new software, it will prevail and determine the data on the blockchain as well as the communication protocols involved in determining the data. This process will lead to a “fork”: The blockchain will split into two chains, each chain only valid on the software used to create it. For Bitcoin it would lead to two parallel currencies. If you receive coins on one chains, they will only be valid on one chain, but not on the other chain.
How does this relate to Bitcoin’s problems? Bitcoin’s blockchain records transactions between users, i.e. transfers of coins. Transactions are grouped into blocks, and about every 15 minutes a miner will find a solution to the proof-of-work puzzle and will append the block of transactions. So far so good; but the Bitcoin protocol prescribes an upper limit for the size of each block, and therefore and upper limit on the number of transactions that can be processed in a fixed amount of time (the current version can process around 7 transactions per second). The more popular Bitcoin gets, and the more transactions it handles, the more data needs to be appended to the blockchain. Just now Bitcoin is at its capacity limit: it barely manages to include all published transaction and execute them. Soon the amount of transactions might be too large to fit into the blocks will lead to a backlog of non-executed bitcoin transactions.
There are multiple competing proposals to solve this problem. The two most famous one are called segregated witness (SegWit) and bitcoin unlimited (BU). But how to decide which solution to use? The developers of bitcoin vowed to remain neutral and to not modify the core protocol on their own. The decision is delegated to the miners: With each block they mine, they can also signal which proposal they prefer. If version gets a significant majority, the problem is solved—but if not, the Bitcoin blockchain might fork into separate, non-compatible versions of Bitcoin. But in a proof-of-work protocol, the miners are not necessarily the stake-holders and users of the blockchain. At the moment, Bitcoin unlimited is favored by many mining pools, representing a significant amount of mining power. But many Bitcoin users prefer the SegWit solution. You can read more about the ongoing struggle over here.
What’s the takeaway for blockchain systems in general? Once deployed, a blockchain system needs to keep evolving, whether in case of rare, unforeseen situations or for regular feature updates. Despite the decentralized nature of blockchain, the need to speak a shared language, i.e. use the same communication protocol in the distributed network, leads to a central point. Having provisions to handle consensus finding and prevent fighting between users, miners, stake-holders and other parties is vital to maintain trust in the blockchain. Whether the best or correct solution is to introduce a central authority, a distributed voting protocol, or deferring the answer to these questions to the majority choice by miners and users is up in the air — there is probably not a single correct answer, just like in politics.
Please share and recommend my article if you liked it. Sign up for my newsletter down below for future updates on my favorite topics.
