Smart Contracts — road of a glass cannon*

So powerful… yet fragile

by Emily Morter on Unsplash

*Glass cannon — usually refers to smth with huge potential e.g (attack), however generally poor defense.

These days “Smart contract” as other buzz words (“IoT”, “AI”, “Quantum computing”) are getting a lot of hype. Range of interest spreads not only across startups and other early adopters of blockchain technology but also attracts attention of large corporations.

In the end, it’s really hard not to follow the crowd. But… what exactly are smart contracts?

In general, smart contracts are simply self-executing computer programmes, deployed on the blockchain, that represent digitized version of paper contract.

Publishing them on the blockchain gives smart contracts several cool features and indeed makes them unique.

Most important features that smart contracts promise:

1. Removal of the middleman during contract negotiation(evaluation) & execution
2. Automatic enforcement of contracts
3. Trustlessness — (however arguable)
4. Immutability (whatever is deployed on the blockchain, cannot be changed)
5. Making lawyers redundant

Additional word of explanation - points three and five are tightly related to each other. Truestlessness basically means that smart contract stakeholders do not have to rely on a third party for execution of conditions included in code. Those conditions, once fulfilled are automatically triggered and executed. As smart contract code should be written accordingly to the rule of law, therefore at this stage lawyers are not needed.

However, it does not mean that they are not needed at all — after all, when smart contract is being created it has to be ensured that it is properly validated. This leads to need of either strong cooperation between developers and lawyers or having people who have both of those skills. Seems like along with smart contracts evolution, new jobs might emerge . How would you call yourself in such a situation? What comes from conjunction of developer/programmer with lawyer? — “lawmmer”? “lawper”? Just an idea.

Smart contract promises are extremely encouraging. However, even though I am a huge fan of applying smart contracts with all of the “luggage” they bring — we are yet far away from utopia. Especially, looking at contracts from the security perspective.

In this article I would like to scratch the tip of the iceberg, and briefly describe some challenges that significantly undermine smart contracts creation efficiency.

As nowadays, by far most popular and widely used blockchain platform for smart contracts (maybe except China) is Ethereum, I will focus directly on it.

Turing Completeness

A bunch of theory:

Turing-completeness is an attribute that can be linked to most of typical programming languages simply saying that they are fully general. According to the Church-Turing thesis programming language which is turing-complete can perform any calculations which can be done manually.

When comparing Ethereum to Bitcoin, both of them use smart contract languages — Script for Bitcoin, and Solidity for Ethereum. Main difference between those two is that Solidity is Turing-complete — it gives developers a possibility not only to create much more complex contracts, but basically to write virtually any given contract.

Smart contract

Turing-completeness is purely beneficial, right? After all, due to it we can simulate really complex situations with lots of business logic and rules included.

What possibly could go wrong with that?

In a perfect world, probably nothing. But… (yes, there always has to be “but”)… we are not living in such a world. When complexity grows, it makes it harder to analyze smart contract code for the presence of potential security issues. In a nutshell, it basically means being prepared to handle any malicious attack and every way contract might be executed. Unfortunately, more complex contract = more lines of code. Doubling number of smart contract code lines doesn’t explicitly increase number of potential halting points by factor of 2. — more likely we are talking here about exponential function.

Thus… ensuring contract security — not a trivial task — simply imagine creating a software that does not have ANY bugs at all. Even though it seems really challenging, definitely cannot be done cursorily as “costs” of overlooking it, as history shows, might be dramatic.

Solidity Coding

As for the smart contracts security, any fixes that happen after code deployment, might end up really badly. Therefore, first things first. To start addressing security “holes” we need to dive to the very bottom — and take a look at the coding level.

Writing a smart contract in Solidity, one might notice lots of similarities to JavaScript. From the other hand, it has even more features that have to be taken into account that were not really known in the past.

As mentioned earlier, code deployed with smart contract on the blockchain is immutable — it will be there to stay, permanently. Additionally, what is being frequently discussed when talking about smart contracts, is “code is a law” rule. When you read smart contract body, you can be sure that every particular function will do exactly the same what code says. Unfortunately, all those things leave developer-lawyers alone with huge responsibility leaving no place for error.

So what are the exemplary aspects present in Solidity code that make it so unique?

As a quick example, developer has to think about who and how will interact with functions inside a smart contract. From the security perspective — it is crucial.

In solidity there are four native “visibility modifiers” that decide where particular function can be called from . For example, adding an “internal” modifier to function implies that it can only be triggered by other function from this contract and contracts which inherit from it.

Additionally, there are also two native “state modifiers” that decide on how function interacts with blockchain… and unlimited amount of custom modifiers that might be created simply depending on particular demand.

From the security standpoint one of most important here are visibility modifiers and custom modifiers.

By default every function written in solidity is set to be “public”. It means that it can be called and triggered by everyone. More complex smart contract is, more functions it need, and every public function is a potential gateway for a malicious actions — therefore, the good practice is to limit amount of public functions to the necessary minimum.

Custom modifiers serves slightly different purpose and could be used for various of different reasons. One example is OpenZappelin onlyOwner modifier that once added to a function allows only one particular “owner” to execute that function.

What are examples of functions that might benefit from such modifier?

There might be various of different examples. Imagine a function that gives you ability to issue new tokens and therefore increases total amount of tokens on the market. Imagine a function that allows you to change smart contract logic… and so on. Usage of such modifier, without further explanation — definitely aims to increase smart contract security. (It would be not really a good practice allowing everyone to create tokens for themselves, would it?) What is more, it is commonly shared practice to use such a modifier. However, some cases show that it is still not perfect.

This leads to conclusion that practice once introduced as safe in the future might need some further development.

Conclusion

As mentioned, I am definitely a fan of smart contracts and I wish their level of adoption was much more significant than it is now. From the other hand, thinking about all of the discussions with regards to their most advantageous features and security issues, it sometimes leads to contradictory findings.

Fortunately, a lot is going on to secure and facilitate smart contracts creation. Websites like OpenZappelin provide huge libraries and secure solidity frameworks. Consensys provides extensive base of information about best practices and types of attacks which smart contracts should be prepared against. And those are not the only examples.

Smart contracts can actually be compared to glass cannons that are extremely easy to mess up, however benefit that might they bring is still way too big not to take that risk.

__________________________________________________________________

Did you like this article? Feel free to share your thoughts/comments.

Kamil Witkowski is an IS Analyst living in Krakow, Poland. You can always find him on LinkedIn and say Hello :)