Caspar Herzberg |
This article first appeared in the
Winter 2017 issue of The Record.
Given the rapid ascent of Bitcoin, it’s no wonder that so many industries are looking at blockchains. Blockchains use a distributed architecture that records information in an additive manner, creating a growing ledger that uses all the records before it to form a cryptographic ‘lock’ on the information being added. It doesn’t rely on a centralised coordinator to guarantee the data or commit to the ledger.
However, it’s sensible to ask: do you really need a blockchain or a Create, Read, Append, Query (CRAQ) solution? Rather than overwriting information to make changes, CRAQ dictates that a new record is appended to the database and linked to the old one. It enhances the historical validity of information and supports emerging requirements for data retention and auditability.
Thus, a business might be considering a blockchain to address fundamental requirements of data retention, analytics, ability to rollback after a mistake and non-repudiation, when these capabilities may be obtained using other technologies. For example, increasing storage and computing capacity with dramatically reducing costs has led to the emergence of append-only databases in which nothing is ever deleted. In theory, once data is recorded to such a database it can’t be changed. This can be great for integrity, auditability and avoiding errors, although as append-only databases grow they tend to run into availability and scalability constraints.
Centralised control and administration is a core advantage of traditional databases. Separation of responsibilities has led to centralisation of data integrity and security concerns in relational databases, freeing up applications to focus on business logic. For most applications, this works well. However, like any centralised service, databases may suffer downtime or become compromised, leaving applications inoperative. For applications that demand high availability, this risk may be unacceptable.
One way to mitigate the risk of centralised data stores is to place replicas of some or all the data in multiple databases distributed across nodes of a network. As long as a critical number of nodes is available, the applications can remain operational.
Auto-replicating databases enable tamper-¬resistance, keeping all the data spread across nodes of a distributed database updated and in sync. This replication should be handled at the protocol level of the database implementation using some form of ‘consensus’.
Apache Kafka is a distributed streaming platform that can maintain a persistent representation, facilitating a natural append-only database. The stream can be replayed to enable new receivers and pathways to be triggered based on the data being streamed over Kafka. Hence, Apache Kafka is a compelling alternative to blockchain technology if authenticated transactions are not required.
As with distributed databases, data integrity constraints between blockchain nodes are automatically imposed. If blockchains look a lot like databases, this is because most blockchains are themselves implemented using append-only databases that auto-replicate their data among distributed nodes.
At a foundational level, blockchains may be identical to, and use, commercial or open-source databases. The next level of blockchain architecture adds capabilities beyond database storage. Protocol-level cryptography helps to implement tamper-evidence of digital assets. Consensus algorithms ensure the integrity of digital assets by all nodes participating in the distributed network. Ownership and control of blockchain assets is assigned using public key infrastructure digital signatures. Protocol-level scripting capabilities allow self-executing smart contracts, simplifying transfer of blockchain asset ownership.
Applications are the third level of blockchain architecture. Cryptocurrencies such as Bitcoin, Litecoin or ZCash are all ¬single-purpose blockchain applications. Blockchains such as Ethereum and Hyperledger Fabric provide a platform on which arbitrary applications can be developed. Examples include e-attestation of data or documents and other proofs of existence; supply chain and other asset tracking; decentralised voting to reduce the likelihood of vote tampering; and complex coordination among counterparties using smart contracts in insurance, travel, healthcare and other industries.
As a promising new technology, it’s easy to try to coerce blockchain technology into solving problems for which it may not be necessary or well-suited. Consider blockchains if:
• you need to assign verifiable control of the stored data to multiple parties
• data being stored represents valuable assets which would benefit from cryptographically-¬ensured access control
• tamper evidence to all parties is important
• automated coordination of control of stored assets is needed
• there is enough tangible benefit to participating and hosting a node in the blockchain network
Faisal Siddiqi is an enterprise architect and JP Morgenthal is CTO for application services at DXC Technology