Centralization trends in blockchain explored with reference to AWS and EOS.Read More
Blockchain is often presented as a solution to the problems that quantum computing will pose for cryptography and these claims are false. Blockchain has no particular relationship to quantum computing whatsoever. Some very brief backstory: encryption methods are invariably built on a math problem that is believed to be difficult and quantum computers are a sophisticated new technology that promises to make some of these math problems less difficult. Although there is considerable propaganda out there to the contrary, blockchain is built on top of the same cryptographic techniques as everything else, it will be compromised by quantum computing like everything else, and if it gets patched up it will likely be in the same way as everything else.
As we discussed briefly in Part One, blockchain is not an innovation in cryptography per se but a distributed program built with heavy use of existing cryptography. Notably, blockchain makes heavy use of cryptographic hash functions and asymmetric (public and private) key encryption. Any frequent user of a cryptocurrency is implicitly familiar with the latter as it is important to keep track of one's private keys, which essentially give ownership of accounts with currency, while the corresponding public keys represent one's identity on the ledger. The public vs. private key algorithms used in most blockchains are not unique at all but are well-tested algorithms, even down to the level of particular implementations, that are applied many other places.
It is the public vs. private key algorithms that are threatened by quantum cryptography and as blockchain is using the same algorithms it is also threatened. It is well beyond the scope of this post to give the details of how quantum computing works, but for those readers who want to do their own Googling we will hit some of the high points. Asymmetric key cryptography is typically built around some form of a type of math problem, the discrete logarithm problem, which involves certain computations that are efficient in one direction but very difficult to invert. The security of the cipher is dependent on this difficulty, and the danger of quantum computing is that it allows new algorithms that make this inversion much easier.
For the moment, though, there is no danger. The engineering difficulty around building a practical quantum computer is vast and existing (extraordinarily expensive) prototypes contain just a few quantum-analog logic gates. Even as they improve, there will be a long period where very few actors have real access to them - they will be a sort of cryptographic nuclear weapon. There are also new cryptographic techniques, notably lattice-based cryptography, that may prove more resistant to quantum attacks. Blockchain's could easily be fixed by swapping in these new parts, but it would be the new components resisting quantum cryptography and not any aspect of the blockchain algorithm itself.
To recap, blockchain has nothing to do with quantum computing and won't do anything on its own to protect you from quantum attacks. Next in Part Four, I will talk about how blockchain doesn't do anything itself to protect your data from theft and rather presents significant new liabilities.
An important part of a blockchain is the process by which the nodes come to an agreement about what to add to the ledger - you might call this a consensus process. This consensus process has implicitly gotten a lot of attention, both in the abstract context of the "Byzantine general's" problem and for it's application in business settings. Unfortunately, much of this attention is not justified by the reality of the algorithm.
The core of the consensus algorithm, the part that actually makes a decision per se, is a simple, familiar majority vote. If 51% of the nodes agree that the next block in the chain should look a particular way, that is the consensus verdict. The 51% number gives it's name to the "51% percent attack" where a sufficiently large (51% or more) group of nodes ("miners" in the cryptocurrency context) can make the blockchain ledger anything they want, and this attack is thus often discuss in the context of centralization in cryptocurrency mining. That there is danger in too much friendliness between nodes is a point we will visit again.
The original blockchain architecture hardens its consensus process by making suggesting a new block expensive, originally via the "proof-of-work" concept. To submit a new block, a node must also solve a computationally expensive (and notably, totally useless otherwise) cryptographic problem. This deters bad guys who might set up malicious nodes, as running nodes is expensive and running enough nodes to approach the 51% number is extremely expensive.
An important subtext in these last two paragraphs is that we hope our nodes distrust each other. We hope they can't collude and that the are checking each other's "proof-of-work" homework. Blockchain is not quite the "trustless" innovation advertised, but something powered by distrust.
Elsewhere, you can find a lot of skeptical commentary on "private" blockchains and it all relates to the distrust issue discussed above. If you are trying to run a blockchain inside a single business, it is liability that your nodes might be run by people who all work for the same people and drink together after work. You might be running an expensive, from a computational standpoint, architecture that really is just a simple majority vote without the distrust among nodes that makes it work. Much of the interest in blockchain from large businesses revolves around it's functionality as a consensus process, but it is not a very good consensus process if implemented inside a single business.
Blockchain is also not the comprehensive solution to the "Byzantine general's problem" (a landmark type of problem in network communication) that it is sometimes proclaimed to be. We have seen above that it requires a specific sort of human context to work appropriately. It also has more subtle problems, too subtle to discuss here but embodied in debacles like the $70 million DAO hack. The short story is this hack exploited confusion about just which nodes had what information and when, and this the essence of the problem facing the Byzantine generals.
Thus, blockchain is in part an interesting and novel consensus process, but this consensus process depends on human context and has technical limitations. Commentary on blockchain is often hagiographic and careless with both of these.
In Part One, we talked about what blockchain definitely offers: immutability. Here in Part Two, we talked about what blockchain is and isn't on its own: a consensus protocol. In the following installments, we'll start to examine the things blockchain definitely is not beginning with a discussion of how blockchain definitely does not offer any unique safe harbor from the security problems posed by quantum computing.
The central, novel property of blockchain is immutability. This means that records can not be changed once they are accepted, and implicit here also is that records receive a timestamp that can not be changed once it is agreed. Immutability was key to the success of the Bitcoin network as it guaranteed there would be no tampering with the older sections of the ledger. Immutability is also the property by which blockchain can offer something genuinely new to information security, but to see clearly how this works we should first examine some basic concepts in cryptography and blockchain architecture.
The mysticism around blockchain imagines it as being everywhere and nowhere, but a blockchain is tangibly a group of databases on a number of different computers, commonly called nodes, communicating constantly via a cryptographic protocol in order to make sure they are all keeping records in the same way. This protocol isn't really an innovation in cryptography in the pure sense, but really a bunch of old ingredients linked together including a very common ingredient called a cryptographic hash function. Informally, the important properties of these hash functions are that 1) they are easy to compute, but very difficult to invert, 2) their output depends chaotically on every little bit of input, and 3) they (hopefully almost) never produce the same output given two inputs. If I give you an output from a hash function, you are going to have a hell of a time finding an input that produces this output unless I give you mine.
So thus far we have databases sharing cryptographic information to try and stay on the same page. This could be a big headache if we are working with a lot of data, and this is where the blocks, their arrangement in a chain, and our hash function get put to work. All the data goes into blocks as we get it, and we put the data of the n-1 -th block into a hash function and include this output in the n -th block. Because of property 2) listed above, this means that any change in a block will radically change all the hashes appearing in all later blocks, while properties 1) and 3) make it extremely difficult to cheat and come up with new, fake blocks that prevent these radical changes. Thus, the efforts of our many databases to stay on the same page need focus on the most recent block as any violation of prior consensus will upset the hash appearing in this most recent block. This resistance to changes in prior consensus, which we previously called immutability, is what makes the whole enterprise workable, both computationally and on level of human trust.
Immutability is useful in information security because it guarantees tamper resistance. We might want to ensure that malicious actors are not doctoring our records towards their own ends, and the transmission of hashes from one block to the next ensures that this is very difficult or impossible. But...in the blockchain context immutability depends on the collaboration of the nodes of our network and their consensus process. The role played by this consensus process, and how the consensus process determines what blockchain can and can't do for information security, will be the topic of the next post in this series.