The Fundamentals and Future of Blockchain and Bitcoin: Part 2 of 4

In Part 1, I narrowed the problem set of blockchain to proof of ownership in order to create a value proposition context from which to understand the purpose of the technology. This next part begins to explain how the specific technical implementation of blockchain works.

The Immutable Distributed Public Ledger

The word blockchain evokes its fundamental structure. It is a chain of blocks (of data) connected in sequence. The sequence is defined by a reference in each block to the block that came before it. For example, if there is a block alpha, and a block beta, and a block zed, each block contains a reference to the block before it. If someone hands me block zed, and I find written on it, “comes after beta,” I know that I need beta to complete the chain, and when I get that, I likewise know I need alpha. But how do I know that someone did not erase the reference and write a reference on it that inserts the block into a different part of the chain? If there’s other data on the block (of course there is, that’s the point) how do I know they did not edit it?

This is where cryptography plays an important role. We typically think of cryptology in terms of hiding data, but in this case it serves a different purpose. Cryptography that hides data for that purpose must also be able to unhide it. We call this reversible encryption. Another type of encryption is one-way. It is intended to completely and irreversibly disguise data. We call this a cryptographic hash, or just hash. A key feature of a hash, or really a key feature of computing, is that if you process a quantity of data, no matter how complex, through an algorithm, the result will always be identical. That is to say, if I input a long string into the SHA-256 hashing algorithm, and you enter the same string into the SHA-256 hashing algorithm, we will arrive at identical hash values. Another key feature of a hash, in addition to being irreversible, is that it is not possible to predict the output based on the input. Other than running it through the same algorithm, there is no way to guess or construct the same hash value. This means that a hash value cannot be forged if we know the data input. Blockchain takes advantage of these features by including a hash of the block’s contents (more precisely the header contents), and a hash of the prior block’s contents.

Getting back to the physical, let’s say wooden, block analogy: someone you trust hands you a block with it’s unique name, the name of its predecessor in the chain, the exact date that it was created, and some other information on it, and it also includes a hash of all the information I just mentioned. You could leave that block in a room of low-tech criminals, come back in an hour, and verify whether it had been changed by entering the information written on the block into your hashing device to determine if the same hash as is on the block is calculated. If it is not, either the data was changed, or the hash was. But what if one of the criminals has their own hashing device? They could easily change the information and calculate a new hash, and change that too. The block would then be internally consistent—e.g., the data would match the hash. A way to guard against this would be to make copies of the block (this is much easier with digital blocks than wooden ones, of course) and distribute them to a bunch of, hopefully, trusted collaborators. But then, what if a number of those collaborators conspire to forge or replace their copies of the block? While distributed blocks can be a way to retain evidence of the original state of a trusted block, as well as backup blocks should one or more be destroyed or otherwise become unavailable, there are still problems. In a distributed network of block holders, who has the authority to add new blocks? How do we trust them? If blocks at the same location in the chain don’t match, which ones are correct or trusted? What if one bad guy starts adding bad blocks at such a volume that it overwhelms the network’s ability to verify them?

This is where the Satoshi Nakamoto (an alias) white paper was revolutionary. So, check back in for Part 3, where I’ll explore the Nakamoto proposal and specifically how crypto coins are interdependently inseparable from the implementation of a truly distributed public ledger.