Upon reading the headline, you might say to yourself: hell right! Why should they use such a no-brainer statement for a title? But, before giving up on this article, at least have a little run-through of the next paragraphs because we believe this is a piece worth reading.

One of the most oft-talked about, and most oft-misunderstood, blockchain terminology is smart contract. Because its name does not necessarily stand for our conventional understanding: smart contracts are not contracts and they are not necessarily smart, as the MIT professor Gary Gensler once said.

Of course, as in the case of all state-of-the-art technologies, smart contracts are just as smart as their developers. We have always emphasized the role of impeccable coding to govern all blockchain functions and transactions and the same rule applies for smart contracts. Coding mistakes in smart contracts do result in significant monetary losses for enterprises.

Before we delve into horror stories of smart contract coding fails, let us do a quick refresher on the term.

Smart contract is a specific term which refers to how transactions are being automated in the blockchain. Smart contract runs on an “if”, “then” logic which seeks to maintain trust among individuals and parties involved in a transaction. If the buyer manages to transfer an x sum of money within 2 x 24 hours, then the seller will shift the goods’ ownership status to him. If the applicant has submitted all the prerequisite documents, then the agency will handle the certificate issuance. 

So they have nothing to do with contracts as we typically know it, like employment contracts or procurement contracts. Rather, a smart contract is just “a set of promises in a digital form” which run on codes instead of written out, to quote Gensler once again. 

Well, speaking of codes again, not only coding mistakes can cause promises to be broken, but can also cost the seller helluva money. 

The chain of (unfortunate) events caused by smart contract design flaws goes like this. Coding mistakes often lead to bugs and, within the context of interactions between multiple smart contracts, bugs can cause functions to execute from the user address, instead of from the owner of the contract.

Bug-infested: the DAO case and vulnerability of smart contracts

The most famous, or rather, infamous, smart contract bug attack is the 2016 attack of the Decentralized Autonomous Organization (DAO) project funded by cryptocurrency. The hacker managed to siphon almost US$50 million out of the project. 

Another high profile case: GitHub user Devops199 once had an Ether transaction worth US$285 million frozen after it was “infected” by a common bug.

In response to this case, a smart contract bug detector called Maian came into being. Maian analytics helped a group of five cryptocurrency practitioners to discover another 970,898 smart contracts which contained bugs.

Apparently, these high-profile cases are merely the tip of the iceberg.

The National University of Singapore (NUS), meanwhile, has uncovered several severe smart contract bugs and, in response, created an analysis tool called Oyente to scan smart contracts. The result was staggering: out of the 19,366 Ethereum smart contracts scanned through the analytics platform, 8,833 of them had bugs.

What does it take to be a smart contract developer?

Let me ask you two questions: 1) Are you interested in being a smart contract developer? Or: 2) do you work in a blockchain company and are wondering about which developers to hire to develop smart contracts for your solution? 

If you answer “yes” to any of these questions, then this will be a very relevant segment for you (did you catch the smart contract reference in that sentence?).

Blockchain engineer Dave Kajpust, in an excellent Medium explainer article, lays down the essential skills that a developer must possess to develop smart contracts. There, he pointed out that “coding a smart contract is more akin to hardware development than software development”. It seems like the analogy he uses is spot-on.

Hardware development has to be very precise and accurate; only after you’ve gone through several rigorous testing and prototyping can you put the product out there; smart contract development also requires such rigorous product development process. Also, much like cases of hardware recall, whereby a faulty hardware causes people financial losses upon its launch, when you release a bug-infested smart contract into a live network, it costs people a devastating amount of money.

You have to be very patient in testing and retesting the product on the testnet before launching it to the mainnet. 

By going through the process slowly, you will be able to work extra meticulously in handling small subtleties in the smart contract, as these subtleties are the ones which often cause so much trouble (think of the Augur bug found in a well-known Ethereum token). Thus, the devil is in the details and you can’t be too careful. 

Finally, use a different way of thinking when coding smart contracts. Approach it from the perspective of an adversary trying to hack your code. By creating a scenario on their possible next moves, you can conjure up scenarios on how you can defend yourself, thus preventing such attacks.

Also, think about how you can promote and encourage good behavior among the peer-to-peer network participants. Think about appointing a smart contract owner who can perform transaction reverse scenarios as possible damage control mechanisms in case of bug attacks. You will note straight away, however, that this means you have to compromise the decentralized advantage of your network, so before making that decision, you first have to consider whether such a trade-off is worth taking.

Simply put, to reiterate the story’s opening argument, you need to become a smarter programmer in order to program a really smart contract.