Smart Contracts, Part 1: The State of Security

This is part 1 of a 3-part series on smart contracts — part 2 focuses on legal issues and it can be found here.

Smart contracts are poised to fundamentally alter how humans interact with each other. Yet, in their current state, they are not ready to be trusted at scale.

In 1996, computer scientist, legal scholar and cryptographer Nick Szabo wrote a paper entitled Smart Contracts: Building Blocks for Digital Markets. In it, he laid down the ground rules of Smart Contracts as one of the critical innovations of blockchain.

As Szabo put it, “The basic idea of smart contracts is that many kinds of contractual clauses can be embedded in the software we deal with, in such a way as to make a breach of contract expensive (if desired, sometimes prohibitively so) for the breacher.” In other words, contracts with automated execution.

Twenty two years on, and the blockchain revolution is in full swing. While most of the attention is currently fixated on cryptocurrencies and their valuations, smart contracts represent the next step in the progression of blockchains from a financial transaction protocol to an all-purpose utility.

Smart Contracts are Proliferating

Smart contracts are the application in which blockchain will likely have the most disruptive short-term impact. Millions of dollars are already entrusted to their code and, as of June 2018, more than 95,000 smart contracts had been deployed on Ethereum alone (per Etherscan).

“As of June 2018, more than 95,000 smart contracts had been deployed on Ethereum alone.”

Business logic coded as software had been automating and revolutionising the world around us long before Bitcoin came along, but the advent of the smart contract represents a ramping up of this trend.

On paper, smart contracts promise the ability to:

• Enforce contracts automatically, trustlessly, and impartially
• Remove the middlemen in contract construction, execution, and enforcement

Smart contracts will increase the speed at which business takes place, they’ll lower transaction risk, and some have even pondered whether they will replace lawyers altogether. This is unlikely in the short-term, but it’s feasible that they could nonetheless take a sizable bite out of lawyers’ market share.

Smart contracts are dynamic, complex, and incredibly powerful.

Lingering Problems

We’ve all heard how smart contracts will irrevocably transform the world, but what tends to get lost in the noise is that coding a secure smart contract is extremely challenging.

This fact has led to MIT Technology Review and other journals publishing pieces arguing that Ethereum’s Smart Contracts Are Full of Holes. This conclusion seems to be mostly coming off the back of a recently released — and highly cited — research paper called Finding The Greedy, Prodigal, and Suicidal Contracts at Scale, which notes “our analysis of nearly one million smart contracts flags 34,200 (2,365 distinct) contracts as vulnerable.” Another study found that upwards of 45% of smart contracts written in Solidity had some form of vulnerability.

“Analysis of nearly one million smart contracts flags 34,200 (2,365 distinct) contracts as vulnerable.”

Amid the hype, this is one of the things that people don’t want to talk about: most smart contracts have vulnerabilities, development standards leave vast room for improvement, and demand has outstripped auditing resources. Despite being built on security-intensive blockchain networks, smart contracts often feature bugs, backdoors, and loopholes that are ripe for exploitation.

Development Challenges

A smart contract is just lines of code that, like any other software, runs on a computer. There are, however, a few factors that make smart contracts more sensitive from a security perspective.

The syntax of Solidity, the primary smart-contract language, is similar to Javascript, which has led many to believe that writing a smart contract is easy. But Solidity is filled with quirky behaviour that can seem correct at a cursory glance, when, in fact, it may well not be.

“Smart contract programming lacks standardised best practices… [and relies] on a non-standard software life-cycle, according to which, delivered applications cannot be updated or patched.”

In a 2018 conference paper, a group of UK-based researchers highlighted two further challenges:

1. Compared to traditional software engineering, the discipline of smart contract programming lacks standardised best practices.
2. Smart contracts rely on a non-standard software life-cycle, according to which, delivered applications cannot be updated or patched.

There’s also the fact that many of the crypto tokens have come to represent such significant value that attackers are highly incentivised to find and exploit bugs in contracts that process or hold them directly for profit. According to Hartej Sawhney, co-founder of the cybersecurity firm Hosho, the sheer amount of funds at stake is and will continue to attract a lot of black hats.

Further, the blockchain boom has created a skyrocketing need for smart contract developers. As highlighted by Techcrunch, “Upwork saw blockchain rise to the fastest-growing skill out of more than 5,000 skills in terms of freelancer billings — a year-over-year increase of more than 35,000%.” As a result, many inexperienced devs have been hired just to satisfy demand.

“Many inexperienced [blockchain] devs have been hired just to satisfy demand. Even the best developers cannot be expected to write bug-free code. Per 1,000 lines, it’s commonly accepted that there will be somewhere between 15 and 50 mistakes.”

Even the best developers cannot be expected to write bug-free code. Per 1,000 lines, it’s commonly accepted that there will be somewhere between 15 and 50 mistakes. So, to write an error-free smart contract, a programmer must beat the average by 15 to 50x.

Lastly, there’s the issue of focus. As Dmytro Budorin, CEO of cybersecurity community Hacken, described it in an interview, “When coding smart contracts, programmers think more about functionality than about security, since the main task is to simply make the code work, and security is usually an afterthought.”

When you mix some of these elements and begin utilising Turing completeness, as many platforms do, it turns out it’s not hard to screw up and create all manner of unintended behaviour.

As a result, smart contracts have a history that’s already littered with painful footnotes recounting all the hacks and mishaps that have occurred.

Mending the Achilles Heel

If smart contracts are to become a core feature of the future digital economy, security must improve.

For a piece of software to be ‘secure’, it needs to be free of unexpected or undesirable behaviour, even when subjected to various threat models. So, the question is, what would make smart contracts less likely to have unexpected behaviour under adversarial conditions?

“There needs to be more focus on simplicity and coherency, even at the expense of some developer effort up front (too many languages optimise for ease-of-development rather than verifiability).”

According to experts in Seattle-based blockchain strategy & technology group New Alchemy, there are three key areas in need of improvement:

• Better language design: Programming languages that are more expressive (viz Turing complete) are also more likely to create unexpected behaviour. “There needs to be more focus on simplicity and coherency, even at the expense of some developer effort up front (too many languages optimise for ease-of-development rather than verifiability).” Also, many use cases do not need the flexibility that Turing-completeness offers. Some projects have realised this. Waves, for example, had this to say in a recent blog post: “Non-Turing-complete contracts will cover most use cases. These will be available from the Waves client for all users and will not require any specialist knowledge or expertise.”
• Better tools: Many issues that code auditors look for fall into known bug categories and can be detected automatically. A manual review is a must, but auditors also generally use a linter or tools such as Truffle and Populus, which are cheap and time-saving, but also need improvement. Indeed, a study on open-source Ethereum contracts reveals that existing solutions can miss up to two-thirds of vulnerabilities due to “insufficient coverage” (see experiments and data here). Some new tools have been introduced recently, but the bar needs to be raised higher still.
• Better methodological discipline: Ethereum tends to attract early adopters, people who like to live on the edge, but that is precisely the opposite temperament necessary to design high-assurance software. “The developers who produced the avionics software of the 80s did a lot more with a lot less, and I think much of that has to do with a cultural disposition towards conservative software design.” The blockchain developers of today will inevitably have to adopt some of that philosophy.

“‘The developers who produced the avionics software of the 80s did a lot more with a lot less, much of that has to do with a cultural disposition towards conservative software design.’ The blockchain developers of today will inevitably have to adopt some of that philosophy.”

Other Improvements

Amy Wan, CEO and co-founder of Sagewise, advocates tackling the issue with a slightly different approach: “I believe that blockchain companies will be able to prevent future smart-contract disasters by using a dedicated developer whose sole focus is developing smart contracts, hiring a reputable security-auditing firm, and including a catch-all safety net into smart contracts, such as an SDK.”

The software developer’s kit in question here can be integrated with the smart contract to essentially act as an arbitration clause in code — thus giving developers the chance to police things should the need arise. To some, this may sound like a centralised point of failure or control, but common-sense solutions such as this will arguably have a role to play.

There are also the traditional methods: testing, code audits, and bug bounties. This is nothing new — governments and big companies regularly employ these methods to vet the security of their software. The only difference is that blockchain space needs to double down on these approaches, given the ‘one-shot’ conditions of smart contracts.

In an article on the mindset of a smart-contract developer, ConsenSys Program Manager Micah Dameron makes a case for an overarching development philosophy: “With the creation of permanent software entities such as smart contracts, the need for a set of rules is fast approaching.” He goes on to use a monument as the embodiment of his proposed philosophy: a philosophy that is well summarised by this four-line stanza:

Final Thoughts

The digital economy is set to launch in a radically new direction, one possibly even more transformative than anything that has come before it. This is mostly due to blockchain and, by extension, the smart contracts it enables. But if smart contracts are to act as a fulcrum for the disintermediation of the global economy, a lot more ground must be covered.

Many consider smart contracts to be still in their embryonic stage and, as such, mostly forgive their shortcomings. Overnight solutions may be unrealistic, but a greater focus on security needs to materialise. Although the majority of the responsibility falls on developers, the blockchain community has a role to play. The community can help development teams err on the side of caution by being more outspoken, bringing security to the centre of the conversation, and demanding more.

The community would also be well advised to spend more time documenting exploited vulnerabilities. Doing so expands the existing library of case studies and situations so that future developers have more reference materials and can avoid repeating mistakes.

“There will always be trade-offs between the efficacy of new security solutions and their ability to be retrofitted on to vast deployments of existing software.”

If you look to history, a lot of security improvement in traditional software has been evolutionary rather than revolutionary and there’s little reason to think smart contracts will be any different. There will always be trade-offs between the efficacy of new security solutions and their ability to be retrofitted on to vast deployments of existing software.

The bottom line in all this is that smart contract reliability is key for mainstream blockchain adoption. If there is to be sustained sense of confidence in this new technology, it’s crucial that the points outlined in this article are addressed.

Early Adopters Swarm

Despite the relative lack of security inherent in early-stage smart contracts, there is no shortage of early adopters finding novel ways to put them to use. One such company is Fizzy AXA, a French airline, which is putting flight insurance on the blockchain. If the event — a flight is more than two hours delayed — is triggered, users are automatically notified with compensation options. The hope is that arduous compensation processes can be made a thing of the past.

Another is Propy, a company looking to make the much-touted future of real estate smart contracts a reality. The ‘across-borders’ marketplace uses smart contracts to ensure legal and financial fair play, making the buying and selling of property far more straightforward. For example, if a buyer sends a deposit of $5000 to reserve a property, the smart contract can ensure that the money is returned immediately if the seller chooses not to sell. Simple use-cases like these will see smart contracts flourish.

This article has been created by Colin Adams of The Research Institute.

The field of emerging technologies is by no means bereft of ideas or inspiration; however, these alone do not equate to innovation neither do they drive technological advancement — quality Research and Development does. The Research Institute takes a practical approach to technological development and seeks to redress the balance between ideas and viable solutions.

Illustrations by Kseniya Forbender