This past week, a few hundred million dollars worth of Ethereum were rendered inaccessible due to a poorly written smart contract, highlighting a lax attitude toward security in the blockchain world. Parity, a popular Ethereum wallet, offered a type of “multi-signature wallet” controlled by a smart contract. These contracts were themselves reliant on library code contained in another master contract, which was responsible for the flaw. Seven days ago, a Github user going by “ghost” casually posted an issue on Parity’s repository claiming that he killed the library code. Furthermore, he clarifies that he’s new to the Ethereum ecosystem and was simply playing around. How could this be, right? Surely some random person can’t walk in and grab the keys of a safe and throw them away? Yet that’s exactly what happened. He first made himself the owner of the library contract (warning bell, anyone could do this!), and then sent a kill signal, leading the library contract to self-destruct. Without this library, nobody is able to access the funds within their multisig Parity wallets, affecting major Ethereum stakeholders such as ICOs raising millions. First of all, the wallet library probably should not have been implemented as just a regular smart contract. Second, the contract lacked proper access control. Third, there existed a self-destruct function without any means of recovery.
In the world of traditional finance, properly audited, secure code is a paramount concern since vast amounts of customer funds are being entrusted to firms in question. Meanwhile, in the crypto world, the situation is still a Wild West, partly because there’s no real government regulation in place and the technology is still maturing, finding its best practices. If adoption needs to grow, and innovative applications be found, we need a new approach to developing smart contracts with the precise eye of a lawyer, a proper audit system in place. Furthermore, perhaps we should work on protecting people from themselves when they’re developing contracts, by altering the programming language itself. Ethereum smart contracts are typically written in Solidity, which offers much room for error. One could draw an analogy to C code: versatile and powerful but offering many opportunities for an inexperienced programmer to cause a major bug. A higher-level language could offer more protection. Maybe one could even use formal proof-based mathematical verification to ensure a contract behaves as intended.
I mention this as an example of decentralized, powerful technology leaving gaping holes for adversaries to exploit, much like the internet in general. Imagine if we do one day operate our voting systems and other critical infrastructure on the blockchain. Indeed, much of our critical infrastructure today is internet-connected, creating many potential vectors for adversaries to find flaws, conduct espionage, and bring down our systems. While we like to talk about government strengthening our cyber defenses, much of this burden is ultimately shouldered by the variety of private and decentralized products we use every day, by nature of the tech industry. Every last citizen and product can be vulnerable, and will be targeted, making the challenge of cyber defense uniquely difficult. All it takes is one government agent clicking on that all-too-tempting phishing email from “àpple.com”, or a zero-day exploit in Windows 10, for critical national security apparatus to become possibly exposed. Or perhaps not a government agent, but an important corporate figure will be targeted, having impacts on the broader US economy. Corporate espionage betwen the US and China is a continuing topic of concern.
Lockscreen bypasses on iOS seem to spring up every year, and FaceID was just shown to be fooled by a certain specially crafted mask. Facebook and Twitter have been used at media for spreading propaganda. It becomes clear quickly that government must coordinate its efforts with the private industry in order to stand a chance against foreign adversaries in a cyber warfront. Meanwhile, corporations must strike a balance between maintaining governmental independence and accepting help from the government in taking defensive measures to preserve security.
Fascinating set of examples. Thank you. I couldn’t help but think of a real-world equivalent here. When I sign paper contracts, I keep a copy along with the copy that the other party keeps. One of those copies could be destroyed (e.g., in a fire), but the other continues to be useful (putting aside all sorts of legal challenges). Most of us have enough experience with the real world to make sure we avoid entering into “fragile” agreements, where by fragile I mean that I can easily lose out. Most computing grew up in a context where you can easily start over and recompute the answer if something goes wrong. Contracts are not that way, and it seems like we need more than just better programming languages if a digital copy of the contract isn’t the same as a physical copy (as it’s not in your example).
Great post.
What shocked me most about the Etherium lockout was that a novice was able to add code to the base without appropriate review and testing.
There is a view from the outside that open source projects are free-for-alls, with anyone able to check in code and add to the effort. But the best open source projects (like, for example, Linux) have what is known as the B.D.F.L. (Benign Dictator for Life) who has ultimate authority over what gets added to the codebase and what does not. Looks like that role was missing for this part of Etherium, to someone’s great cost.
Democracy and equality is great for some things. But for software that people depend on, it may not be the best approach.