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.