There is absolutely no use for "blockchain technology" in libraries. NONE. Zip. Nada. Fuhgettaboutit. Folks who say otherwise are either dishonest, misinformed, or misleadingly defining "blockchain technology" as all the wonderful uses of digital signatures, cryptographic hashes, peer-to-peer networks, zero-knowledge proofs, hash chains and Merkle trees. I'm willing to forgive members of this third category of crypto-huckster because libraries really do need to learn about all those technologies and put them to good use. Call it NotChain, and I'm all for it.
It's not that blockchain for libraries couldn't work, it's that blockchain for libraries would be evil. Let me explain.
All the good attributes ascribed to magical "blockchain technology" are available in "git", a program used by software developers for distributed version control. The folks at GitHub realized that many problems would benefit from some workflow tools layered on top of the git, and they're now being acquired for several billion dollars by Microsoft, which is run by folks who know a lot about that digital crypto stuff.
Believe it or not, blockchains and git repos are both based on Merkle trees, which use cryptographic hashes to indelibly tie one information packet (a block or a commit) to a preceding information packet. The packets are thus arranged in a tree. The difference between the two is how they achieve consensus (how they prune the tree).
Blockchains strive to grow a single branch (thus, the tree becomes a chain). They reach consensus by adding packets according to the computing power of nodes that want to add a packet (proof of work) or to the wealth of nodes that want to add a packet (proof of stake). So if you have a problem where you want a single trunk (a ledger) whose control is allocated by wealth or power, blockchain may be an applicable solution.
Git repos take a different approach to consensus; git makes it easy to make a new branch (or fork) and it makes it easy to merge branches back together. It leaves the decision of whether to branch or merge mostly up to humans. So if you have a problem where you need to reach consensus (or disagreement) about information by the usual (imperfect) ways of humans, git repos are possibly the Merkle trees you need.
I think library technology should not be enabling consensus on the basis of wealth or power rather than thought and discussion. That would be evil.
Notes:
1. Here are some good articles about git and blockchain:
2. Why is "blockchain" getting all the hype, instead of "Merkle trees" or "git"? I can think of three reasons:
It's not that blockchain for libraries couldn't work, it's that blockchain for libraries would be evil. Let me explain.
 |
| A Merkle tree. (from Wikipedia) |
Believe it or not, blockchains and git repos are both based on Merkle trees, which use cryptographic hashes to indelibly tie one information packet (a block or a commit) to a preceding information packet. The packets are thus arranged in a tree. The difference between the two is how they achieve consensus (how they prune the tree).
Git repos take a different approach to consensus; git makes it easy to make a new branch (or fork) and it makes it easy to merge branches back together. It leaves the decision of whether to branch or merge mostly up to humans. So if you have a problem where you need to reach consensus (or disagreement) about information by the usual (imperfect) ways of humans, git repos are possibly the Merkle trees you need.
I think library technology should not be enabling consensus on the basis of wealth or power rather than thought and discussion. That would be evil.
Notes:
1. Here are some good articles about git and blockchain:
- Blockchain: Under the Hood - Justin Ramos
- Is a Git Repository a Blockchain? - Danno Ferrin
- Is Git a Blockchain? - Dave Mercer
- The Blockchain, From a Git Perspective - Jackson Kelley
2. Why is "blockchain" getting all the hype, instead of "Merkle trees" or "git"? I can think of three reasons:
- "git" is a funny name.
- "Merkle" is a funny name.
- Everyone loves Lego blocks!
3. I wrote an article about what the library/archives/publishing world can learn from bitcoin. It's still good.
Posts
