If Blockchain Is the Answer, What Is the Security Question?
Like any technology, blockchain has its strengths and weaknesses. But debunking three common myths can help you cut through the hype.
Blockchain technology has made its way into a wide range of business environments, solving problems from securing land registry records to ensuring that music royalties are paid fairly. To the casual observer, this technology enhances any business relationship, especially when parties are distributed or distrustful. However, like QR codes in the '00s or, more recently, big data, blockchains are appearing a little too frequently and sometimes with dubious business benefits. To cut through the hype, let's consider the most talked about capabilities of blockchains and examine the reality behind the claims.
Myth 1: Blockchains are a resilient, distributed database.
For many people, blockchains and Bitcoin are synonymous — thousands of computers scattered about the planet, each with a copy of an ever-growing digital ledger. For Bitcoin and other sizable public blockchains, including Ethereum, the size of the network is indeed very large and claims of resilience are fair. Each full node in the network keeps a copy of the entire ledger, and the ingenious proof-of-work consensus mechanisms ensures this is kept in sync.
However, in many of the examples making the news lately, the structure of the network is quite different. The majority appear to be private chains, run by a handful of nodes set up specifically for the purpose of managing a business process. While this implies a degree of resilience, it doesn't compare to the robustness offered by a large public chain. Given that you have to configure and manage these nodes yourself, you might question what you gain over deploying a properly distributed database.
Which brings us to the next problem: blockchains are not databases. They are a ledger data structure, suited for appending new pieces of data and allowing an auditor to occasionally do a full-pass validation of the contents. They are not designed for supporting queries on data, or certainly not queries of any great complexity. If a business plan contains the phrase "store on the blockchain," alarm bells should be ringing. In such cases, always ask why a blockchain is superior to an actual database.
There's also the question of confidentiality. Ledgers are generally public data structures and thus unsuitable for storing private data. Sometimes this is mitigated by storing ID values or hashes in the blockchain, with the actual data living in a private shadow database elsewhere. Particularly in these situations, one must question what is gained by involving a blockchain at all.
Myth 2: Blockchains are the ideal audit tool — a perfect, immutable transaction history.
A blockchain uses a chain of hashed data structures to record a sequence of transactions. In the case of Bitcoin, these transactions are generally transfers of funds from one address to another, but in other chains, the transactions may be nonfinancial and domain-specific.
The brilliance of blockchains is that a transaction has truly happened only when it is captured in the ledger and thus recorded forever. This means there is a one-to-one link between the action and the audit log — perfect forensics evidence. However, this perfection requires your business transaction to be modeled as a blockchain transaction (perhaps using smart contracts on Ethereum or Burrow). If you merely post an audit entry to a blockchain after your business transaction completes, that magical property is lost. There's no guarantee that every business transaction was posted to the chain, or that every element in the chain is the result of a real business transaction. If your software is merely posting audit logs to a blockchain, you should ask yourself why a blockchain is the right answer, versus a database or some other data structure.
One should also consider the claim of immutability quite carefully. All blockchains can resist a certain proportion of bad folks trying to subvert its behavior — typically somewhere between a third to a half of participants. Beyond this threshold, if sufficient nodes collude they can rewrite the past. Imagine a scenario where three banks keep a shared blockchain ledger to record transactions. Is it so hard to imagine two of the banks conspiring against the third? Probably not, yet we could equally imagine that the use of blockchain technology was championed in all three banks as a cure-all for data integrity and auditing.
One way to approach the above problem is to anchor your private chain in a public chain, such as Bitcoin. Through the wonderful properties of Merkle trees (which essentially condense an entire blockchain history into a single hash value), it's possible to notarize your chain state by including its hash in a Bitcoin transaction. You've piggy-backed on the immutability afforded by Bitcoin to protect your private chain! A number of startups have sprung up to offer this as a service.
Myth 3: In the future, all business contracts will be smart contracts on a blockchain.
Ethereum was the first blockchain designed for executing arbitrary code "on the blockchain." Its brilliant design allows users to upload small pieces of code to a blockchain address, which can be executed by sending a transaction to that address. The code is executed faithfully by all the participants of the network, and the results are committed to the blockchain. There are cunning security mechanisms and economics in place to prevent spammers from running never-ending programs and bringing down the network.
On the face of it, this seems very exciting for business. Error-prone, corruptible human processes can be replaced with autonomous scripts that are guaranteed to execute correctly and audit themselves automatically on the ledger. So, what's the problem?
One problem is the difficulty in writing flawless contract code. In 2016, this was dramatically highlighted when around $50 million was stolen from The DAO, an autonomous corporation running on the Ethereum blockchain. The theft was made possible by a bug in the contract code, which allowed the attacker to withdraw a third of the value of the corporation into anonymous accounts. Contrast this outcome with a flaw in a legal contract, where you have the opportunity to argue the matter in court and seek a reasonable judgment based on the intention of the document.
Another issue is the legal enforceability of smart contracts. For the foreseeable future, smart contracts will be secondary to a written contract that actually binds the parties together. It will be the latter document that provides the legal protection and risk mitigation, not the smart contract. Yet, in spite of the above, smart contracts are an excellent idea and will no doubt revolutionize the way business is done in some sectors. Just don't expect to be taking your lawyers off retainer just yet.
Like any technology, blockchain has its strengths and weaknesses. With the current hype surrounding the subject, it's all too easy to incorporate blockchains into projects where an alternative approach might be easier or more flexible. If your business transactions can be represented as blockchain transactions, you get a lot of powerful side effects for free. Auditing, shared state, and consensus between distrusting parties are pretty impressive secondary benefits. But you probably shouldn't be using a blockchain as your primary method to solve those problems.
Related Content:
Learn from the industry’s most knowledgeable CISOs and IT security experts in a setting that is conducive to interaction and conversation. Click for more info and to register.
About the Author
You May Also Like