Oops, I Accidentally Froze $150 Million of Ether. Or, How Smart Contracts Are Not Invulnerable

Well, here we are again. On November 6, Parity encountered yet another failure, and the result? Reportedly, some $150 to $300 million dollars worth of Ether (we are hearing conflicting reports as to how much ETH has been frozen) is locked down, and we’re hearing talk about an Ethereum hard fork, yet again. (How many times can Ethereum hard fork before it’s not a decentralized or immutable?)

As much as we’d like to throw shade on Parity, there’s a bigger picture problem here – Parity is not alone. Parity hack 1, Parity “accidental code deletion” 2, and The DAO hack are all part of a larger systemic issue around smart contracts and code.

An Explainer About This Latest “Accident”

Parity is a smart contract-based Ethereum wallet meant to provide improved security for Ether holders using something called multi-signature. A multi-signature wallet can be explained as a wallet that requires multiple keys turned at once to unlock funds. Parity and multi-signature are considered state of the art for protecting funds, and many high-profile projects use Parity wallet to hold a large amount of Ether.

On July 20th, after the first hack, the Parity multi-signature wallet software was upgraded. The upgrade included some structural changes to the project. Namely, the project was separated into individual contract code that would be published to the blockchain by each user, and a library of functions that would now only need to be published once by Parity. The idea was that since users must spend money to publish their wallet to the blockchain, this shared library would reduce the size of the code that each user needed to publish while their individual code could call into this shared code library that would already be published at a hardcoded address.

Here is where we get to the problem that occurred:

A user on github named devops199 discovered that the shared library code was not properly secured because the owner was not yet assigned. Devops199 added themselves as the owner of the contract/shared library code and then directed the blockchain to “kill” the contract. The kill call permanently deleted the shared library from the Ethereum blockchain. This means that all the other multi-signature wallets that reference this shared code library can no longer call into it at all. Without this shared library code, there is no way to transfer funds out of the wallets. Thus, any wallet created with Parity multi-signature wallet after July 20 is currently frozen with all funds sitting visibly inside, but inaccessible. The amount inaccessible is estimated to be over 1 million Ether or roughly $280 million at present value.

Smart Contracts Aren’t So Smart

The term “smart contract” might be a misnomer, because oftentimes, they’re not so smart. In fact, smart contracts are full of vulnerabilities. Just as the best lawyers cannot always write perfect, indisputable traditional contracts, developers cannot always write perfect, error and vulnerability-free, dispute-less smart contracts. Sure, we can use bug bounties, formal verification, and code audits to get close to perfection, but what happens when even those fail?

Parity Wallet Failure 2 is just another one of many smart contract failures as of late, to add to a prominent list of other smart contract failures including The DAO hack, Parity Wallet 1.

Smart contracts have potential for a host of good. (I personally think they present a wonderful opportunity to reduce the size of the $12.2B debt collections industry). But to truly maximize the potential of smart contracts, we must first understand their flaws and limitations (and resolve them):

  • smart contracts may contain coding errors (and many developers write code using a fail fast and iterate mentality)
  • smart contracts may contains vulnerabilities easily exploited by hackers
  • smart contracts may not accurately reflect the intent of parties
  • contracting parties may change their mind and wish to amend, modify, or terminate the contract due to misrepresentation, mistake, duress, impossibility, or a change in circumstance
  • external data sources, such as other contracts or oracles may provide incorrect data

Many industry experts, understanding these limitations, have been calling on solutions for a while. We’re experiencing the early days of a nascent industry, much like the early days of the internet. I think we’ll get there, but it’ll take a while.

[clickToTweet tweet=”until smart contracts allow users confidence in their transactions it is like playing roulette ” quote=”until smart contracts allow users confidence in their transactions it is like playing roulette “]

Meanwhile, until smart contracts allow users confidence in their transactions, the use of smart contracts is more akin to playing roulette – you’re not quite sure what you’ll end up with. The lack of a safety net in smart contacts currently inhibits smart contract adoption, and dampens transactional certainty. Further, the logistical and cultural hurdles of even disputing a smart contract in the current traditional legal ecosystem presents several challenges. Our team at Sagecoin is developing such a solution, which involves a smart contract “freeze button” and a dispute resolution marketplace, all atop a borderless, digital jurisdiction. This solution, alongside several others—including identity verification services, security audit solutions, etc. will help to bring more stability to the smart contract ecosystem.

With regard to Party Failure #2, we believe that a solution could have been employed to stop this issue from occurring using a number of measures:

1. Time Locked Dispute Resolution points could have been employed around key functions in the shared library such as functions that kill the contract — this would have provided ample notice that the contract was going to be killed before it actually happened and allowed the opportunity to disable the kill call.

2. Immediate Dispute Resolution Points could have been used as checks in the code to send the shared library to dispute as soon as it was clear that the contract had no owner or that someone had become owner that should not have been.

3. Every single wallet contract created with this shared library system could have included its own dispute resolution parameters local to that wallet. If implemented at the lowest level, this could have been used to dispute individual wallet contracts even if the shared library was deleted. In other words, there may have been a secondary and localized way to unfreeze the funds if the shared code was deleted.


 

Amy Wan, Esq.CIPP/US, is a Senior Contributor to Crowdfund Insider.  Amy is founder and Chief Legal Hacker at Sagecoin, a Bootstrap Legal Legaltech blockchain project, and is a consultant with ICOinvestor.tv. She has authored many legal publications, including the upcoming Bloomberg Law ICO offering practice guide. Amy was previously Partner at a law firm that specialized in crowdfunding and syndication law, and was the General Counsel of a real estate crowdfunding platform. She has been named one of ten women to watch in legal technology by the American Bar Association Journal in 2014 and was Finalist for the Corporate Counsel of the Year Award 2015 by LA Business Journal. She is the founder and co-organizer of Legal Hackers LA.

 

Daniel Rice is a veteran software engineer, leader, speaker, and writer with expertise in blockchain and finance. Daniel’s most recent role was as CTO for Totum Risk which provides portfolio analytics software. Totum was selected for YNext incubator in 2016, which was awarded “top accelerator” honors by Finance Magazine. Daniel has helped launch over 20 products, and as an entrepreneur his personal apps have racked up over 5 million downloads. He has previously consulted on blockchain projects for a blockchain escrow company and blockchain real estate title transfer and records company. In 2014 Daniel founded Bitcoin Developers Los Angeles to focus on building a developer community around blockchain technology. He has also consulted as CTO for several early blockchain startups and published a whitepaper on managing price volatility of cryptocurrencies. Daniel is also the founder and organizer of the Orange County CTO Forum. He holds a BS degree in Computer Engineering from Cal Poly, San Luis Obispo.



Sponsored Links by DQ Promote

 

 

Send this to a friend