ALEKSANDER OLSZEWSKI,

Author at L4A ICO, Blockchain and Web Development Blog, content manager at Look4App

Smart Contracts are immutable. Which means that once you deploy them, there’s no way back, and the contract will scourge you like an evil genie distorting your wish.

But it won’t be malicious. It will just be factual – and it will all be your fault.

At Look4App we share insights on ICO, blockchain and web development. Our team has collected 3 real-life examples of other people failing to create perfect Smart Contract for you, so you won’t have to.

And well, yes, we collected them with the little guilty pleasure of watching others fail. Here’s what’s wrong with those Smart Contracts – learn by example:

1. Parity Ice Age

Smart Contracts are eternal. Every action taken on Ethereum blockchain requires Gas as a fuel. If you do it wrong, it can consume a fortune.

This is the single reason that the blockchain development community stresses the inclusion of a “kill” function so much.

But a “kill” function is not always on your side. When you build a complex multi-signature system to improve the security of Ether holders, the last thing you want to hear from a tech newbie messing around is:

“I accidentally killed it.”

That’s what happened to Parity. The kill call permanently deleted a library from the blockchain, maiming a part of the state-of-the-art platform. This simple security exploit froze over US$150 dollars of Ether in the users’ own wallets.

Now, over half a year after this incident, Parity is still promoting changes in the Ethereum blockchain that will allow them to release the frozen funds. For now – unsuccessfully. After half a year the ice age of Parity still persists.

How to avoid this kind of error? Even heavy testing might have left it unnoticed. Only a deep audit, based on thorough blockchain mechanics expertise might have discovered it.

But the sad truth for the users is this: participating in a Smart Contract is like signing a legal contract written in Solidity code. It’s all written there – and in signing up for it, you agreed to the terms and conditions.

2. EEAR by Thomas Jay Rush

Let’s switch to small scale projects – not so famous, but still well-known. In his brilliant Medium post, Thomas shared the results of defective Smart Contract deployment. His Ethereum Early Adopters Registry was draining the money out of his wallet due to a simple mistake.

It was an honest mistake. But an irreversible one, as it was already out there on the blockchain.

It could have been reversed. But the problem was actually the feature that we usually consider the con of a blockchain – anonymity. In not connecting the data on your users, you have a hard time reversing the mistakes.

Luckily, he found a way to manually bypass this issue – and due to its small scale the problem did not escalate further.

How to avoid this kind of error??In this case, a simple testing on testnet would do, thus exposing the malfunction in the code.

3. Distributed Autonomous Organization

And now, back to big business:

The DAO is an investment vehicle – it gives you the opportunity to invest your money through the Ethereum blockchain, with a Smart Contract designed to eliminate the need for human trust.

Everyone knew how the contract worked. But some people knew the mechanics just a bit better.

Attackers exploited DAO, draining resources worth US$50 million.

The “hack” was reversed and the money restored – but in fact, this was a function in the Smart Contract. If it wasn’t there in the first place, this exploit would be impossible. The story is similar to the Parity one – everyone agreed to the Smart Contract’s content by participating in the project and funding it.

How to avoid this kind of error??Here again, standard testing would have a high probability of failing to notice the exploit. It would require a deep understanding of the technology to actually discover the possibility to launch an attack.

Smart Contracts fail. And there’s a reason for that

• When writing complicated systems, bugs are almost inevitable. Luckily, we can examine the code on testnet before deployment.
• The real problems usually appear when you have a multicomponent solution, created by multiple developers all around the world, and you fail to control the versions of your code and test it inside and out.
• Even though the contracts are immutable and everyone agrees to its content, humans are fallible – and the contract will ruthlessly enforce its rules, be it through its own function, or with the help of a third party that exploits its vulnerabilities.

That’s why, in sharing our approach to ICO and blockchain projects at L4A, we stress testing so much. We believe the only answer to that is Quality Assurance and a heavy, thorough audit and testing before deployment.

SEE ALSO:?How will blockchain change retail business: TOP-5 options