Ethereum smart contracts, according to the official website , are executed "exactly as programmed, without any possibility of downtime, censorship, fraud or third party interference." Today I will try to figure out whether everything is so rosy in fact, having considered some of the problems that users of smart contracts face in practice.
At the end of the article, I summarize my thoughts with a brief instruction on writing secure smart contracts.
- This article will focus only on Ethereum smart contracts. The community silently identified “smart contracts” with “Ethereum smart contracts”. Meanwhile, the first is rather a concept, and the second is implementation, and the question of how this implementation meets the concept can be discussed (as in principle, the very concept of smart contracts and other possible implementations). This topic is complex, undervalued and interesting, but this is not the topic of this article, so I’m referring interested people to the works of Nick Szabo . Accordingly, wherever I say “smart contracts”, I actually mean “Ethereum smart contracts”.
- The article will focus only on the language of the smart contracts Solidity as the most popular one and for Ethereum is essentially the only one at the moment.
Security issues of smart contracts
It will be about the problems that smart contract developers end up with, and not about the security of the platform itself (although a bit about it). Let's conditionally divide these problems into the following types:
- problems in the smart contract code;
- problems in the development process;
- language problems;
- problems in concept.
1. Problems in the smart contract code
By problems in the code of a smart contract here, I mean such problems that are solved by editing the .sol file. This, in particular:
- Known vulnerable constructions (for example, re-entrancy ).
Life example : re-entrancy, or, more broadly, a violation of the pattern of Checks-Effects-Interactions - even well-known (and previously exploited ) vulnerabilities continue to occur in new contracts. - Author's vulnerable constructs (in particular, errors in the logic of the code).
Example from life : MultiSig-wallet, which is not really MultiSig. In order to sign a transaction and transfer funds, you need a number of signatures of the owners of the wallet equal to required . At the same time, in order to change the required (for example, by one, in order to continue to sign the transactions yourself), it is enough to sign only one of the owners:
- Bad architecture.
Life example : an attempt to implement within a single contract and a token, wallet, and keystore. The contract turns out to be overly complicated, the code is difficult to maintain, audit, modify. As a result, safety also suffers. - Low quality code.
Example from life : contracts with different indents, arbitrary new line transitions and spaces. The code is hard to read, which means security suffers again. With that, for Solidity there are already linters ( Solium , Solhit ).
Problems in the code directly lead to attacks and loss of funds. The good news is that problems in the code can be identified during the audit process and eliminated. It is important to understand where they come from in order to avoid them in the future. Therefore, we proceed to the next item.
2. Problems in the development process
Problems in the code are primarily due to an incorrectly built development process. It would seem that software development is a matter that has long been studied, with well-established best practices. Nevertheless, the youth of the field of smart contracts, the disproportionately large amount of money and HYIP lead people to ignore standard procedures for one reason or another, which often leads to serious problems. From the most typical it is worth mentioning:
- TZ: most Ethereum smart contracts are written without a technical specification. What it may lead to, is unnecessary to explain.
- Terms: on average, very little time is allocated for development, about a month. An extreme example from my practice: the customer asked the developer to write a smart contract 3 days before ICO.
- Developer level: a lot of people come to the region, including no programming background at all.
- Understanding the ecosystem: and even if the background, then often the developers are not deeply immersed in the topic and do not understand the specifics of smart contracts.
- Development price: and yet, those who write smart contracts are few; even fewer who write them well. Hence the unreasonably high cost of development.
3. Problems in the language
Adds the very language Solidity. Initially, it was created more so that a large number of people could quickly master it, rather than so that it was convenient to write secure smart contracts on it. Here are just some of its features that interfere with security:
- Multiple inheritance,
using for , call / delegate call - all this starts the code not from the current source code, which means it reduces the readability and, as a result, the security of the code. - Checks-Effects-Interactions pattern - if constructs that violate CEI are unsafe, then why not ban them (and many others) just at the language level?
- By calling another contract, you can suddenly get into its fallback function with unexpected consequences.
It is clear that the Ethereum project is developing, and it is impossible to take everything into account in advance. But in the end, developers are forced to remember many features and use crutches to make their smart contract safe.
4. Problems in concept
However, the most serious problem is even deeper - that many do not understand well enough why smart contracts are needed, what they can, what they cannot and how they work. In the worst case, this results in a smart contract:
Not smart:
- Poorly written - does what is written, but not what is intended.
- Strongly tied to the backend and / or frontend - and this code is no longer a smart contract, it is executed in the usual way, and its execution is fully controlled by the server administrator.
Not a contract:
- It does not fix the obligations of the parties - for example, ICO sells its tokens for ETH, but tokens are essentially candy wrappers, since They do not impose any restrictions or obligations on the person who released them.
- Allows unilateral changes - and it turns out that one of the parties can change the contract after its signing.
Life example : the contract owner can arbitrarily change the capitalization, the rate and duration of the sale of a token:
Not needed:
- The smart contract was added not because it was technically necessary, but in attempts to figure out what to do on smart contracts and ride the hype wave;
- We tried to think up how to fasten smart contracts to an existing product.
Smart contract as a security threat to blockchain startups
What is the result? They wanted a fashionable, safe, blockchain, but we get expensive unsupported code that threatens security and is not needed at all. We wanted our smart contracts to be executed “exactly as they were programmed, without any possibility of downtime, censorship, fraud or third-party intervention”, and in the end they are really executed as they are written - they are only written with a vulnerability. And we can only wave the handle of their funds. Well, or make a hardfork (thus actually discrediting the original idea itself), if because of the vulnerability, the creators of Ethereum lost money.
How to write secure smart contracts
In fact, of course, everything is not so bad. I just exaggerate in trying to draw attention to some important, in my opinion, moments. In general, the region is developing, people learn, including security.
If the reader decides to write a smart contract, I would advise:
- understand why you need (and need) a smart contract;
- get from the customer or write their own TZ;
- calculate the time;
- use development and testing tools ( Truffle , Remix , SmartCheck , Solhint or Solium linter );
- write tests;
- conduct several independent audits and bug bounty;
- monitor the safety of the remaining components of the project (website, Twitter, etc.).
By following these simple recommendations, you can avoid most of the problems described above (from hard forks, however, this still will not save).
The article was created in collaboration with Evgeny Marchenko ( eMarchenko ).