Smart Contracts — road of a glass cannon* – Hacker Noon

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.


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.


read original article here