Blockchains Tech Talk

2017-02-13, 10:47 Posted by: Tero Keski-Valkama, Elisa Patronen

We are arranging another open Cybercom tech talk in Tampere University, this time about blockchains. Please join us, more information in the end of this post!

This post brushes upon the same themes as the tech talk, but the content is a bit different.

Introductory texts on blockchain are mainly focused on two core things: Bitcoin-style open blockchains with proof-of-work consensus mechanism, and integrity through sequential hash evaluation in the block chain. While these things are important, they are not everything blockchain technologies are about, and as such they might give a bit misleading picture of the whole.

There is a really good, novice-friendly introduction to these core topics of blockchain in a comic form made by Futurice Spice Program.

For a deeper insight into open blockchains there is the Princeton course book on Bitcoin and Cryptocurrency Technologies.

I would like to show a quick bird's eye view to blockchain technologies and solutions, and describe some underrepresented features.

Many blockchain features derive from specific security threats. One of the most fundamental ones concerning open blockchains is the Sybil attack.

Sybil Attack

In a democracy, every person gets one vote. Blockchain integrity is based on a majority consensus. This majority consensus can be compromized if any one person could masquerade as multiple people, and in a way, hijack the election. This multiplication of identities is known as the "Sybil Attack".

In societies, people prove that they are individual natural persons by providing birth certificates and paper trails. In a digital network of computer software it is more challenging to make sure no one votes twice. Anyone can make multiple copies of software and have multiple identities in a system where new, previously unknown people can join at will. In blockchains, the "votes" are actually turns to declare the next block to the blockchain.

Bitcoin solves this problem by allocating "votes", or actually turns to present the next block to the blockchain based on work, or energy usage requirements. There is no way to add a block to the blockchain without expending considerable amounts of resources by the miners. If a miner divides the energy and resources to multiple identities, the overall energy expended is still the same and the probability of being allocated the turn to declare the next block is the same, irrespective of the number of identities used.

To keep the system stable, the difficulty of adding new blocks is constantly adjusted to reflect the hashrate of the infrastructure so that the block rate keeps somewhat constant. In Bitcoin blockchain the difficulty is simply a number which depends on the rate of last blocks which must be larger than the hash of the next block.

The target rate of blocks is one block per 10 minutes in Bitcoin. The block size is 1 MB, and typically contains about 2000 transactions. In practice this makes less than 4 transactions per second, but at most that block size can contain 7 transactions per second.

Costs of Transaction Infrastructure

All open blockchains include a cryptocurrency tied to the transaction processing, because otherwise it would not be clear that the miners could be trusted. If the miners' profits are tied to the cryptocurrency, they have an incentive to keep the infrastructure operational and healthy. The cryptocurrency accumulated by the miner only have value if the system works and the currency is used by many people.

Proposing a yet another cryptocurrency is not an easy task, because to have value, the currency must have faith of many people. It must be publicly exchangeable in markets, and easily used in transactions. If the currency has no value, few people will mine it and the system does not maintain itself in a stable fashion.

The cost of energy spent for mining is offset by the mining rewards automatically given to the miner within the blocks, including the implicit block reward and the transaction fees paid in the transactions incorporated to the block. As the transactions include the implicit transfer of money to the miner, the miner can only get hold of those bitcoins by incorporating the transaction to the blockchain.

This clever game theoretic "hack" provides infrastructure for transaction processing much like the internet, where the rules of routing traffic between networks give rise to the internet networking, or postal regulations give rise to the international postal system.

1 kWh = 0.538 kg of coal equivalent

At the moment it seems that the Bitcoin value is high enough so that it is economically feasible to spend somewhat extreme resources into transaction processing. No matter how much resources are spent for transaction processing in Bitcoin, the speed of transaction processing is the same. This is 7 transactions per second for the whole Bitcoin network at most.

At the moment of writing the total Bitcoin network hashrate is about 3,000,000 TH/s, which corresponds to the energy use of about 3,000 MW (assuming 1 W/GH). This corresponds to the whole network burning 450 kilograms of equivalent coal every second, that is 64 kilograms of coal per transaction, for the highest possible transaction rate.

This animation represents the realtime speed of equivalent coal burned by the Bitcoin miners in 200 kg reindeers.

This animation represents the realtime speed of equivalent coal burned by the Bitcoin miners in 200 kg reindeers.

Bitcoin uses proof-of-work algorithm of double SHA-256 hashing as its consensus algorithm. That means that for the miners to accept a new block to the blockchain and to start mining the next block on top of that, the block has to contain a nonce that leads to the double SHA-256 hash digest of the whole block to be a smaller number than the current "difficulty". The miners compete in who can first find a nonce that produces a valid block. Since this process is random, the miners get their turns to determine the next block weighted by the computing capacity, and energy they have expended.

Because of a rather extreme strain this puts on the environment and resources, there is a general will for moving to different Proof-of-Work algorithms, or to Proof-of-Stake blockchains. For example, Ethereum will migrate to Casper Proof-of-Stake algorithm in 2017.

Consensus methods, coins

There are also different Proof-of-Work algorithms which represent clever utilitarian methods to make sure the miners provide a valuable service instead of simply hashing together dumb numbers. For example Primecoin PoW algorithm publishes useful prime number values to the scientific community. Some PoW algorithms require the miners to store the whole blockchain, improving redundant storage. Some PoW algorithms, like Litecoin Scrypt, aim to be efficient in normal consumer PC hardware utilizing the downtime in normal PC hardware pool making it less attractive for speculators to build large data centers for mining.

Proof-of-Stake consensus algorithm also prevents a Sybil attack, but instead of giving "votes" based on energy spent, they give votes based on how many coins are owned. This produces novel game theoretic difficulties and new vulnerabilities, but there are also various solutions for those. There are several PoS blockchains in existence, for example Peercoin.

Consensus methods, differences

What is a Consortium Blockchain?

A corporation cannot simply introduce a new publicly exchangeable cryptocurrency for each blockchain application they introduce. It would be very difficult to get the public to accept it and assign value to it.

It is also often the case that existing public blockchains do not offer a good match for the purposes of specific applications, even with Turing complete smart contracts. The transaction costs are also high in public blockchains by comparison to private ones.

With all these difficulties arising from the open system with untrusted, unknown participants, corporations have considered alternatives. If a corporation can manage the membership of the consortium in a trusted fashion, the Sybil attack becomes irrelevant (or technically only the trusted party is able to perform a Sybil attack, which they swear to never, ever do). Also if the miners (or more commonly "validators" for consortium blockchains) are assumed to gain from the operation of the infrastructure, with minimal processing costs, the requirement of needing a cryptocurrency to compensate the miners can be dropped.

While it is still possible to cheat in the consortium blockchain system, as there are no cryptocurrency holdings that would lose value as a result, the transparent system allows the corporations to keep track on each other and potentially delegate disagreements to external courts.

So, consortium blockchains make some compromises with openness and security of the system while gaining more energy efficient operation and no need to create a new cryptocurrency.

How is Consortium Blockchain Different from a Distributed Database?

Distributed databases have existed for tens of years, and are a de-facto solution for data storage and distribution. What benefits would consortium blockchains, "the bastard children of open blockchains", bring over normal distributed databases? Have all the blockchain benefits been thrown away when making brave compromises in the security model and openness?

This is a core question in enterprise blockchain adoption and the raison d'être for consortium blockchain stacks, such as IBM Hyperledger Fabric.

In fact, consortium blockchains are an important middle ground, and offer true benefits for situations where multiple companies need to cooperate in administering a shared database, when all these companies are not necessarily implicitly trusted. In consortium blockchain, all parties validate the blocks suggested by the others, and the whole system is robust against failures and cheating.

Blockchain data model has some requirements for the stored data. All the data must be stored forever, and it also makes sense to include some kind of microcode in the blocks to facilitate evolution over time. Blockchains cannot be migrated to a new version and new data model for new revisions, like traditional databases. Instead, blockchains are evolved through soft forks, whitelisting new patterns of transaction microcode which will be accepted by the validators after a designated point in time, or hard forks, where the validators coordinate between each others to facilitate major changes in interpreting the blockchain state. Hard forks are difficult organisationally, even with consortium blockchains, so flexibility through internal microcode offers an important avenue for evolving the system.

Welcome to our open tech talk about blockchains in Tampere University in 2017-02-23, the invitation and registration is in!

comments powered by Disqus