Blockchain is another of the modern topics that seems to have a life of its own. The problem is that about half the people who think of blockchain don’t really know what it is, and the other half think it’s all about Bitcoin and cryptocurrency. The application doesn’t define the technology, or at least it shouldn’t. Blockchain technology has broad applications, but it’s hard to see them without really knowing what it is and does. Sadly, typical tutorials focus on applications and not on the technology potential.
The basic mechanics are simple. A transaction against something (the “target” or “subject” of the blockchain) is a “block”. When blocks are created, they are chained to the prior blocks, hence “blockchain”. The blockchain is a journal of transactions from the inception of the target to the present. OK, but that’s probably not really helpful in understanding one.
I think the easiest and best way to start a tutorial on blockchain is to look at a rather old-fashioned financial example, but in a different way. Suppose you have an account at a store, and you go there periodically to buy things. The storekeeper puts the items you’ve bought “on account”, and you go in from time to time to pay something on account. It’s easy to see this as being about the account ledger or transactions, but what it’s really about is trust. You trust the storekeeper to keep the books, so the truth is that it doesn’t matter much what the format is, or what you decide to buy or pay.
Blockchain is, at its core, a trust community. There are “members” of the community who have a set of cooperative activities centered around some kind of records. If your storekeeper let anyone go in and add items to your account, you’d be stuck paying for things you didn’t get. You trust the storekeeper. The storekeeper trusts you to pay for what you’ve purchased. The account is the centerpoint in the trusting process, where the parties come together.
Two-party trust is pretty easy to address, but as the number of parties increases, so do both the issues that could arise and create a dispute, and the risk that parties involved might create those issues. The traditional mechanism for trust extension in business is a combination of parallel record-keeping together with an exchange of information among parties to ensure the records are in sync. If there’s a dispute, then a third party has to step in and decide what the truth is.
A variation on this approach for mass merchandizing is the concept of Electronic Data Interchange (EDI). With EDI, it’s common to use a third party as a transaction intermediary between parties, on the theory that if a neutral player can authenticate the transactions, then it will always be possible to resolve the question of the authentic state of the records. There may have to be a legal framework to enforce a decision on authenticity, and many EDI users executed agreements to establish that framework in advance.
You could think of blockchain as a kind of super-EDI. Instead of relying on a third party to mediate transactions, what blockchain does is create a community to jointly mediate the records themselves. The concept is based on three essential principles, and without them all, it doesn’t work.
The most fundamental of the principles is that of community. A blockchain has specific “actors” or entities that are part of the community. These are typically opaque to each other, but they all see all transactions (“blocks”) and participants in the transactions must all be community members and agree to the transaction. Further, all community members have a copy of the blockchain.
The second principle is that of authority. The blockchain is secured with strong encryption to prevent anyone from altering past blocks/transaction records. Because everyone involved in a transaction had to agree to it, and because nobody can alter records to cook the books, the blockchain is an authoritative record of whatever information it’s designed to keep.
Principle number three is past-state auditability. The original information in the chain is agreed to by all, and every transaction that changes that information is stamped and signed off on. You can go to a blockchain and determine, at any point in time, what the state of the records were. The current state is thus self-proved and self-audited.
If we stay with our example of the shopkeeper and the account, what blockchain does is provide a mechanism whereby the authenticity of the books is assured by the fact that when a transaction is entered, the account book the originator is referencing is supplied. This means that all the members of the community can test the book (in blockchain form) against their own copy, and more than half must declare the book authentic in order for the transaction to be recorded.
In theory, you can do almost anything with blockchain technology, since the individual transactions don’t even have to be related to each other or anything else. An example of this seemingly disorderly application type is a journal of events; it’s transactions that matter, not the net result of them. Despite the broad potential, the largest number of blockchain applications involve something that has state, meaning a set of current conditions that are meaningful to the community. Our account book had state, and so do nearly all financial transactions.
The broad theoretical impact can be narrowed by practical considerations, the most significant of which is the potential delay associated with achieving consensus on a transaction. Could you do a blockchain to represent the state of a server (as some have already proposed)? Yes, but if the community is distributed far enough, then real-time information may be far less than real-time because of the delay in getting approval to post the transaction as a block.
Bitcoin and other cryptocurrencies are good examples of blockchain because they do have state, and because the “transaction” against a Bitcoin is likely a simple change in ownership. That means that human-level delays in reaching validity consensus probably don’t hurt much.
Bitcoin also illustrates a couple of fundamental issues with blockchain, one being the validity of the authority principle and the other being the issue of representation. If either of these things are in question, then a blockchain is a complex validation of something invalid.
Blockchain authority is created in part by its presumed immutability; a blockchain has hash totals and encryption, and any time a block is presented it’s compared with the “back-chain” values of other blocks and thus authenticated. You’d have to break both the encryption and corrupt the community in order to falsify a chain. But a given blockchain, to a new user, is still a little bit of a trust question. Suppose somebody gives you a cryptodollar. You can think that the encryption and community validation protects you by guaranteeing its authenticity, but might the blockchain represent a fraudulent community, not the one you think it does? Some protection is built into some applications, but it’s still possible to be duped.
The other issue is representation. What makes a cryptodollar worth a dollar? Answer: Someone with a real dollar created the chain to represent the dollar, and “backed” the chain with that amount. That’s called “provenance”; the backer vouches for the representation, and since that isn’t a transaction/block the representation may be doubtful. With backing, a cryptodollar is like a paper dollar. I remember that the US dollar used to say something like “This certifies that there is, on deposit in the Treasury of the United States, one dollar in silver, payable to the bearer on demand.” If you can exchange a cryptodollar for a real one at the point of its origination, it’s clearly a proper representation. If you can buy something with it that costs a dollar, it’s an accepted representation, but not necessarily real. Think the classic pyramid scheme.
The final issue with blockchain is that it’s a chain. As transaction volumes mount, so does the length of the chain and the resources it takes to transport and process transactions. Something like a ledger typically won’t have enough transactions to contaminate the value proposition, but in some applications like the recording of events, the length of the chain could be a barrier to adoption.
Despite this, blockchain has applications beyond the obvious. In the original ExperiaSphere project, I introduced a concept called “SocioPATH™” a “community” of nodes that were responsible for “voting” on asserted identities for membership, which then established connection and access rights. You could do something like that with blockchain. Google’s Wave technology, never carried forward, used a blockchain-like mechanism to establish a secure collaborative context that couldn’t be altered retrospectively and that was protected against intrusion.
What these initiatives show is that many of the blockchain ideas aren’t new, and that there are many elements in blockchain that could be used independently without the total context of blockchain, to develop new approaches to classic IT problems. It may well be that these nubbins of blockchain will prove more broadly useful than the entire strategy.