1) What has happened over the last 72 hours
Over the last 72 hours, the shortcomings of the blockchain application known as THE DAO have converged in rather spectacular fashion on account of a sophisticated hacking attack exploiting the DAO’s smart contract code. As a result, hackers have drained upwards of US$ 50 million in Ether (the Ethereum cryptocurrency) from it.
The facts on the ground change by the minute; public responses range from praise to opprobrium. Where people fall on that scale is a matter of personal preference; having no exposure, I am fairly neutral, albeit very sympathetic.
There is one line of reasoning, though, which I have seen from a couple of startup mavens on Twitter and, this evening, in long-form on the blog of USV’s managing partner, Albert Wenger. With whom, at the risk of never getting a meeting at that firm for the rest of my natural life, I am going to disagree.
2) This is not an example of “fail fast, fail often”
Mr. Wenger’s view is that with the DAO, as on many prior occasions, we are simply dealing with another example of the “fail fast” ethos which Silicon Valley has promoted, with good reason and considerable success, over the course of the last 30 years.
As he put it:
Both individually and collectively we learn more from our failures than from our successes. Failures make us question our assumptions, successes generally don’t. I therefore welcome the hack of the DAO (even if I wind up losing the 0.5 BTC I had converted to Ether and invested). It is exposing a lot of assumptions and that is the path to learning.
This might be true, but for the fact that virtually everything having to do with the DAO made very little commercial sense, and that well-informed people have been warning about the structural pitfalls of crypto-token projects for years.
Some background might be helpful here. As an entrepreneur working in this space one of the greatest annoyances I encounter on a daily basis is when someone says “Blockchain can solve X” when in fact what they mean is
There’s a reason for this. A blockchain, on its own, does very little for you; it is simply a data structure which, put very simply:
When you program that blockchain (with smart contracts), a blockchain can do rather a lot as a distributed consensus/process automation engine. However, in order to do that, you need to first understand every part of the process that the blockchain is going to manage.
3) Applied technology/ERP is not a web or iOS app
Ian Grigg calls this approach to development “financial cryptography in seven layers” – I recommend everyone read the blogpost in which he sets that out.
Given that blockchains are designed to be fundamentally multi-party, this also means that – invariably – you are going to need to get lawyers involved.
This is because human beings structure their relationships in accordance with legal rules, and have done so with a reassuring degree of consistency for the last 8,000 years.
In accordance with Ian’s thinking, if you’re automating a relationship, every single layer of the stack has to work correctly in order to achieve the desired aim: the maths, the implementation, the UX, the accounting and financial rules, and the legally relevant events all have to work in unison to create an application that takes a complex governance process and turns it into a peer-to-peer protocol.
You are taking the people out of the process and replacing them with code that is not meant to be regularly updated. So you have to understand what those people do, and why, if the code you write is to work (and save your customer time and money).
Bridging the gap becomes especially important if you want to take your idea and turn it into an investable business, as many Solidity programmers do.
With respect to the DAO, there was a similar breakdown in communication – only this time between the wider community and the developers doing the codeslinging. Serious professional objections, from persons extremely well-versed on every layer of this conceptual stack, were made known very early. And not “this is a silly idea which will never work” kinds of objections, but “this is technically bankrupt and flies in the face of all best practice for what you are attempting to do” kinds of objections.
Emin Sirer and Vlad Zamfir’s code review, Dan Larimer’s incentive review, a series of articles by Stephen Palley on legal aspects of DAOs, and Izabella Kaminska’s “Izabella Kaminska” review stand out in my memory as being particularly insightful.
4) Failing fast vs failing unnecessarily
Despite the Cassandras’ cries for intercession, true believers, the media, VCs, and others ignored these critiques and futurist optimism won the day.
And for a short time, everyone thought that a new paradigm had been thrust upon us:
This time, the futurists were wrong. I would therefore reject the characterisation that this hack – as put by Wenger –
will be more like the early failures in aviation. They are what gave us today’s safe air travel (I wrote this post on a flight earlier today).
That is not what is happening here, because today sophisticated organisations, such as a central bank, are “doing blockchain” correctly. These sophisticated efforts are Farnborough Air Show. The DAO was the Red Bull Flugtag.
The lesson here is this. There’s a difference between
- failing fast and honourably; and
- failing because you didn’t have the right expertise (i.e. you’re bike-shedding) and got in over your head, hurting a lot of people in the process.
5) Blockchain, unlike other tech disciplines that preceded it, is both a humanities expertise game and a tech game
Many of the problems Albert Wenger identifies with the DAO were, at one point, difficult technical problems. Most have been solved. Blockchains can be controlled. Smart contracts can be updated and even reversed on the fly. Legal terms can be incorporated directly into a smart contract’s code. And above all modular smart contract systems can make all of this a hell of a lot easier to build and test.
Everything “THEDAO” tried to be, it could have been correctly and in full compliance with the law. For this reason, what blockchain companies should be trying to do is take complex financial, business, and governance processes and turn them into machine-readable protocols that also tick all of the human requirements, legal or otherwise. A bit of code that does all those things is what a smart contract actually is.
The DAO, in its haste for glory, failed to tick those boxes. Instead, it took the tropes of “decentralization” inherited from Bitcoin as received wisdom (which, as we know, are highly problematic from a legal-technical perspective) and inappropriately applied these same principles to a human relationship – corporate governance and venture capital investment – which is vastly more complicated than peer-to-peer electronic cash.
And it failed. There are many technical reasons why, but the root cause of this failure was not because the concept of a “DAO” is a fundamentally bad idea, or even because blockchain tech isn’t up to the task.
It failed because in startup-land the promise of boundless disruption paired with hyper-rapid adoption is valued more highly than professional competence.
6) How to do “smart contracts” right
Human relationships are complicated. It’s my experience that really useful blockchain applications, by their very nature, require
- a high degree of professional competence,
- a lot of testing, and
- a lot of time
As a result, explosive, hype-driven overnight growth such as the speculative asset price bubbles we’ve seen with Bitcoin and Ethereum are blockchain’s past. They are not its future.
This isn’t to say that for some, or even most, startups, the fast-breaker approach makes sense. For many it still does. For blockchains it does too, but in software development and not in terms of playing fast and loose with the legal piece – because with legal subject matter (commercial relationships), it is more important for an implementation to be correct than it is to just be available.
So the DAO didn’t fail fast. It failed unnecessarily, that is to say, it failed in a way that was almost completely avoidable with a bit of due diligence. Two weeks’ worth of compliance homework or programming an emergency kill switch on the DAO smart contract could have gone some way to prevent all the trouble from happening in the first place.
Going slowly would have had consequences, mind you – it may have precluded the massive run-up in Ether and “DAO token” prices we’ve seen over the last 30 days, and it surely would have missed all the attention such headline-grabbing numbers bring (raising $150 million in two weeks, as a rule, attracts much more attention than slaving away on a truly useful distributed enterprise app subject to NDA). Without a doubt, money and markets are sexier than software development to the average Joe. They’re cooler. They’re easier to understand.
But, as the events of the last few days show, they’re also proving rather ephemeral.
What we, as a community of virtual machine and smart contract language users, learn from this is that applying the venture funding and rapid mass adoption playbook for mobile apps like “Yo” is precisely the wrong way to formalize relationships on public networks – a task for which blockchains are uniquely suited, and also for which the stakes are frighteningly high.
To do this work well one absolutely must understand, or be able to understand, every layer of the financial cryptography stack. Once you’ve got that expertise, such that you can avoid falling into a hole, then and only then can you fail fast on things like product development or new or interesting features. But not before.
Nowhere is this more important than when you’re writing smart contracts. When it comes to the legal issues, do the work and do it right. The first time around.
Like lawyers do.