There Are Still a Few Good Reasons to Trust Blockchain
A few weeks ago, a friend forwarded me this critical op-ed published in Wired, titled “There’s No Good Reason to Trust Blockchain”. Ordinarily, I wouldn’t think twice about a critique of blockchain — there’s a new one every week — but this was different. The author is Bruce Schneier, author of “Applied Cryptography” and a veritable giant in the cryptography and security fields.
Schneier is a writer and thinker I respect tremendously and follow diligently; his blog is informative, occasionally whimsically entertaining, and a great way to keep up with the latest in security and all the various ways in which you should be concerned about the current state of IoT. As a skilled technologist deep in the weeds of debates over the role of cryptography in public policy and trust in technology, I had hoped Schneier would take a more positive (at least cautiously optimistic) view of blockchains.
Instead, his article, while being correct about many of the most vexing problems facing blockchain today, misses the point about the long-term significance of the technology. This response addresses the arguments Schneier makes, and the questions he raises. Views are my own.
The core of Schneier’s essay revolves around two main points. One, that trust in humans and institutions is essential and can never be fully supplanted by trust in cryptographic systems and code. Two, that blockchain networks are plagued by many centralized points of failure — especially in the exchanges, wallets, and smart contract code through which we interact with them — and that the risk of these is often overlooked by supporters of the crypto ecosystem. I agree, in principle, with both of these points. It’s in the conclusion — “cryptocurrencies are useless” — that Schneier misses the mark. Let’s break it down.
Single Points of Failure
I’ll tackle the second point first. Although Schneier is absolutely correct to point out the problems with trusting single points of failure, this is, at its core, not really a critique of blockchain. QuadrigaCX failed because of poor human management of the business and lack of internal controls/contingency plans, not because blockchain technology is fundamentally flawed. Exchanges with better governance practices would never find themselves in a similar situation. Likewise, smart contract bugs like the DAO hack and the Parity multisignature wallet freeze were the result of human error, not fundamental flaws in the underlying blockchain protocol. In the DAO hack, the authors of the vulnerable smart contract initially failed to account for the possibility of a recursive send. In the Parity bug, the developers of the multisig wallet had, in the interest of reducing gas costs, switched to an approach in which all sub-instances of the wallet would be lightweight “stubs” referring to a library contract, but failed to properly secure the parent contract against a transfer of ownership.
Importantly though, in both of these high-profile smart contract vulnerabilities, human coders had become aware of the mistakes in their initial live versions of the code, and intended to patch them — they just didn’t get around to it in time before they became public and were exploited/triggered. The vulnerability in Parity’s wallet was known and on their GitHub to-do list for months before the freeze happened. While painful, these learning experiences help serve as educational examples for developers — and we’ve recently seen some examples that demonstrate a more responsible approach to handling vulnerabilities in live protocols. Most notably, the Zcash team recently disclosed a counterfeiting vulnerability discovered in the Zcash core protocol. The vulnerability in Zcash was identified, categorized, studied, and discretely patched by a small team working with the utmost security and care, and as a result was never exploited prior to the patch and subsequent public disclosure.
There has also been a lot of progress recently in the research community on auditing and automatically detecting vulnerabilities in smart contracts, even before they go live. Formal verification, while still labor-intensive and in its infancy when it comes to applications to cryptographic protocols, may help to further increase the security of new smart contract projects in development. Securely making critical modifications to live code that is handling millions if not billions of dollars in transaction throughput is incredibly stressful — Vitalik Buterin has likened it to making repairs to a rocket mid-flight — but it is entirely possible, and worth pursuing.
It’s important to remember that points of access to complex technologies, even robust and well-established ones, will always be huge concentrations of risk, especially wherever humans get involved. These risks are mitigated over time for new technologies as we learn from our mistakes and improve security practices. The same is as true in existing internet applications as it is in crypto, and even in our banking system. Man-in-the-middle attacks and other breaches led to the development and promulgation of HTTPS on the internet. Password phishing has led to increased awareness of and support for two-factor authentication.
Despite all these advances in security, exploitation of human flaws at single points of failure remains the easiest and most consistent way to breach various types of security systems in the existing internet ecosystem. Most people still use very insecure and easy-to-guess passwords and re-use them widely, and password guidelines haven’t caught up. And the most common form of 2FA (over SMS) has been fooled by a simple well-executed spoofed phone call to customer service in a “SIM swap” attack, letting a determined attacker gain control of your mobile phone number — and from there, often all of your other accounts that aren’t protected by a more secure form of 2FA or identity verification.
These are all issues Schneier has written about previously. It’s puzzling to me that while he recognizes these issues do not condemn the concept of delivering banking services online or confidential information over email, he seems to use the same line of reasoning to conclude that blockchain technology is hopelessly vulnerable and therefore useless.
The Trust Gap
On to Schneier’s main point: “blockchain doesn’t eliminate the need to trust human institutions; there will always be a big gap that can’t be addressed by technology alone”, he writes, neatly summarizing his thesis. “People still need to be in charge, and there is always a need for governance outside the system.” This is made abundantly clear by the spate of recent issues in base-layer protocol governance in Bitcoin and Ethereum, which Schneier discusses in his article. I agree. Governance and the interaction between human groups of researchers and developers and the blockchain protocols they build and maintain remain fraught with issues that are far from solved. But again, it is not a foregone conclusion that blockchains are not good for anything as a result.
Although there will always be a big gap between trust in technology and trust in human institutions, it is not the case, as Schneier seems to imply, that this gap cannot be reduced substantially and meaningfully, and the system of trust overall strengthened as a result. He asks at the end of the article: “does the blockchain change the system of trust in any meaningful way, or just shift it around?” His implication is that the answer to this question is almost always “no”, and most applications of blockchain today do not create a meaningful benefit from a change in the system of trust as a result of the use of a blockchain-based system.
However, in certain applications, I would argue blockchain is capable of making some very meaningful changes to the trust system. The elimination of counterparty risk in financial products (particularly in collateralized debt and other asset-backed classes) can be hugely impactful — and we’ve seen some impact already. Take the example of MakerDAO — a decentralized platform for secured loans built on Ethereum that has issued tens of millions of USD-denominated loans since its inception in late 2017. By making the entire global community of MKR holders the lenders of last resort and maintaining a complex interwoven ecosystem of price feeds, watchdogs, and market makers, MakerDAO is able to provide secured loans (called Collateralized Debt Positions, or CDPs) denominated in a stable asset pegged to the US dollar (DAI) against a volatile asset (ETH) at interest rates unheard of in the world of centralized finance. The DAI stability fee is around 1% APR at time of this writing, though the interest rate has been as low as 0.5% APR in the past. Compare this with a typical LIBOR + 3% or more charged by banks for similar dollar loans against stock holdings — the delta in the cost of capital is substantial. Real people with ETH holdings have used this functionality of MakerDAO to refinance their home mortgages and take out loans to buy new cars, among other things. And in the near future, MakerDAO will be able to provide this lending functionality against a much broader range of tokenized assets on Ethereum.
Of course, MakerDAO is not completely decentralized — there is still human trust involved. The product is reliant on a relatively small number of dedicated risk management teams, keepers, oracles, and market makers whose expertise and active participation is essential in setting risk parameters and liquidating underwater CDPs. The MKR holders (of whom there are relatively few compared with other crypto projects) have a responsibility to govern the system appropriately via voting. But total decentralization and elimination of human trust at all costs isn’t the point — at this stage in the system’s evolution, having too many MKR holders, too many keepers and market makers, would dilute responsibility and weaken the protocol overall.
The genius of MakerDAO is that by leveraging the Ethereum blockchain as a shared source of trust in the risk status of loans, and as a way of distributing risk across a broad base and incentivizing all actors in the system to behave appropriately, the system is able to share risk more efficiently overall. In other words, the clever application of blockchain means that MakerDAO doesn’t lend like a bank — it lends like a central bank (h/t Steve McKeon). That, to me, is hugely significant.
Code isn’t Law
Another pointed rhetorical question Schneier asks: “Does blockchain strengthen existing trust relationships, or try to go against them?” Often, yes — applications of blockchain technology do explicitly or implicitly try to go against existing trust structures, something that can probably be traced back to the original Bitcoin paper, if not earlier. Satoshi Nakamoto was fairly explicitly anti-bank, both in the original paper and in the other traces they left behind. “Code is law” is a maxim often repeated in various forms by ardent crypto supporters, usually as a refutation of governmental or corporate authority — even in cases where theft or other illegal actions occur.
This was the reason for the ETC/ETH split following the DAO hack. When the Ethereum leadership team executed a hard fork to restore the stolen funds to their original owners, a minority group maintained that despite the illegal actions and significant damages caused to victims of the hack, those transactions should remain final and immutable. “Code is law” expresses an admirable spirit of techno-libertarianism, but the notion of code being the final arbiter of all things is a misguided one. It’s fair to critique this.
But it doesn’t need to be this way, and, luckily, many in the community are beginning to come around to a more pragmatic view: that code is not law in and of itself, but blockchain can automate some aspects of law, finance, and privacy, and shrink (though not eliminate) the aforementioned gap between trust in technology and trust in human institutions. Many of the security token standards proposed recently include administrative functions for forced transfer or burn/reissue as a failsafe in case of illegal actions, loss of control of keys, or a token administrator going out of business.
Adopting a shared source of trust, automation, and transparency (where appropriate) while fitting into and collaborating with existing systems and regulations can enable seamless automation of post-issuance servicing of financial instruments, replication of deal structures, and efficiencies in liquid trading and further uses of tokenized assets down the line that are simply not possible without the sharing of trust enabled by a secure public blockchain platform.
We’re Just Getting Started
Blockchain technology is at a crossroads — in the throes of a ~90% correction in publicly traded cryptoasset prices, still struggling to cast off the scams and vaporware of yesteryear and “grow up”. But security practices are maturing. The smart teams — and there are many of them — continue to build and figure out creative ways to apply blockchain in a way that does meaningfully change the structure of the system of trust, without burning the world down in the process. I remain very optimistic about what the next few years will bring. Yes, there are issues to work through. But as we have with most transformative new technologies before blockchain, we will work through them, and the result will be worth the blood, sweat, and tears, and worth the wait. I hope Bruce Schneier will one day join us on the other side — we need thought leaders like him to help us build the future of finance.
