Ethereum smart contracts, according to the platform’s official web page, “run exactly as programmed without any possibility of downtime, censorship, fraud or third-party interference.” That sounds good, but is it true?

In this article, I examine whether things are actually so nice and neat by dissecting some issues encountered by smart-contract users. In the final section of the post, I will also recap my thoughts with a brief guidance on creating safe smart contracts.

A Few Quick Notes

The article is going to cover Ethereum smart contracts only. The community has wordlessly associated “smart contracts” with “Ethereum smart contracts.” Nevertheless, the former is more of a concept, while the latter denotes an implementation, and the question of how accurately this implementation corresponds to the concept is debatable. (And so is the smart contract concept proper as well as other implementations. This subject matter is complex, underestimated by many and captivating — those interested can peruse the materials by Nick Szabo.) Long story short, by mentioning “smart contracts” in this post I mean “Ethereum smart contracts.”

The article will only touch on the Solidity contract-oriented programming language as the most common one in the Ethereum ecosystem and, effectively, the only language of its kind at this point.

Smart Contract Security Caveats

Let’s take a moment to shed some light on the issues that smart contract developers come across, rather than the security of the platform itself. (Although a little bit of the latter will be mentioned, too.) It makes sense to break these issues down into the following types:

  1. Issues with smart contract code
  2. Development issues
  3. Language issues
  4. Concept issues

1. Issues With Smart Contract Code

When discussing coding issues, I refer to the ones that can be solved by editing the .sol file. These include:

  • Known vulnerable constructions (for example, re-entrancy). Even well-documented (and previously exploited) re-entrancy vulnerabilities, denoting the violation of the Checks-Effects-Interactions pattern, continue to be encountered in new contracts.
  • Author-borne vulnerable constructions, including errors in code logic. A real-world example is a MultiSig wallet that’s not actually MultiSig. It takes a specific number of wallet owners’ signatures that equals the required parameter to sign a transaction and complete a transfer of funds. Meanwhile, the signature of only one owner is enough to change the required value and, for instance, make it ‘1’ to be able to solely sign transactions.
  • Faulty architecture. For example, it can be an attempt to implement a token, a wallet and a key storage within the same contract. This will make the contract too complex and the code will be hard to support, audit and modify, which will affect security.
  • Poor quality of the code. Contracts with code that contains different indents, arbitrary jumps to new lines and redundant spaces make an example. The code becomes hard to read and the contract’s security is impacted, even though there are linters for Solidity, such as Solium and Solhint.

Coding issues can facilitate attacks and cause users to lose their assets. The good news is that these flaws can be found in the course of auditing and then eliminate; however, it’s important to understand the source of these issues in order to avoid them in the future. This brings us to the next section:

2. Development Issues

Coding flaws are primarily caused by poor development practices. It might appear that software development is a well-trodden path; however, the smart contracts industry is still young, and big money and lots of hype can make people neglect fundamental procedures. This leads to serious problems, such as:

  • Technical specification. Most Ethereum smart contracts are created without one. It doesn’t take a genius to understand what the consequences can be.
  • Deadline. Very little time, usually about a month, is allocated to the development. Here’s an extreme example from my experience: a customer told a developer to write a smart contract three days before the ICO.
  • Developer’s skills. Lots of people are joining the industry, some of whom don’t have much programming background.
  • Knowledge of the ecosystem. Even with solid backgrounds in place, many developers aren’t proficient enough in the smart contract domain.
  • Development cost. There are few coders who write smart contracts at this point; and there are even fewer who do it well – hence the unreasonably high cost of these services.

3. Language Issues

The Solidity language itself adds some extra flies in the ointment. It was originally meant to be simple enough for a lot of people to get the hang of it, rather than be a handy language to write secure smart contracts. Here are a few of its characteristics that don’t get along with proper security.

  • Multiple inheritance: using for, call/delegate call. These launch code from a source other than the current one, thereby impacting readability and security of the code.
  • Checks-Effects-Interactions pattern. If constructions violating CEI are unsafe, why not ban them (and many others) at the language-wide level?
  • While calling another contract, you can suddenly end up in its fallback function, which may lead to unpredictable outcomes.

It is clear that the evolution of the Ethereum project is in progress and it’s impossible to foresee all the issues. But at the end of the day, developers have to keep a number of language peculiarities in mind to make sure their smart contract is safe.

Ethical Hacking Training – Resources (InfoSec)

4. Concept Issues

The most serious issue, though, is yet deeper. Some people simply don’t have enough understanding of what smart contracts are meant for, what they can and can’t do, and how they work. In the worst-case scenario, this makes a smart contract:

1. Not really smart

  • It’s poorly written – does what it says instead of what it’s supposed to do.
  • Excessively back-end and/or front-end-centered. In this case, it is no longer a smart contract; it is executed in a regular way; and its execution is fully controlled by a server admin.

2. Not really a contract

  • Doesn’t define parties’ responsibility. For instance, an ICO sells its tokens for ETH, but these tokens are actually “candy wrappers” as they don’t impose any restrictions or responsibilities upon the releasing entity.
  • Allows for one-party modifications, resulting in a scenario where one of the parties can change the contract after it has been signed. For example, a contract owner can modify the capitalization, exchange rate and token sale period.

3. Not really useful

  • The smart contract isn’t added because it’s technically necessary, but because its authors want to ride the wave of hype.
  • Someone may try to add smart contracts to an existing product.

Can Smart Contracts Impact the Security of Blockchain Startups?

So where are we now? We wanted to keep up with the trends and make things “blockchainish,” but what we got instead is unsupported code that poses multiple security risks and doesn’t make much sense. We wanted our smart contracts to “run exactly as programmed without any possibility of downtime, censorship, fraud or third-party interference” – and they actually run as programmed, but they are programmed with vulnerabilities under the hood.

Ultimately, all that’s left for us to do is bid farewell to our assets or create a hard fork (thereby making the original concept go down the drain), in case Ethereum authors are among those who lost money over another vulnerability.

How to Write Secure Smart Contracts

… Or perhaps not. In fact, it’s not all bad; the industry is evolving, and people are learning to make smart contracts more secure.

If you decide to write a smart contract, here is what I’d recommend you do:

  • Understand the smart contract’s goal, if any
  • Get technical specification from the customer, or write it on your own
  • Set a reasonable deadline
  • Use development and testing tools (Truffle, Remix, SmartCheck, the Solhint or Solium linters)
  • Write and run tests
  • Do several independent audits and set up bug bounties
  • Keep an eye on the security of other components of the project (website, social networks, etc.)

Conclusion

By following these simple recommendations, you can avoid most of the issues described above. You can create smart contracts that are safe, well-made and carefully-tested. But always remember: if the industry does decide to do a hard fork, you never know what will happen next.

Sources

Ethereum Project

Solidity

Money, blockchains, and social scalability, Nick Szabo

Re-Entrancy, Solidity