Definition Of Smart Contracts: What Are They And Why Do We Need Them?
Just like the words “blockchain”, “AI” and “cloud”, the term “smart contract” always gets a lot of hype. Indeed, it is much better to be sure of what is going to happen next than just to rely on the existing judicial system.
The main benefits of smart contracts are:
- Applying contracts automatically, fairly and trustfully.
- No need to involve an intermediate person in contract combination, proceeding and finalizing;
- (As a result) No lawyers.
What are the smart contracts though? Are they exclusively Ethereum based? Are they our future? In this article, we will figure out what smart contracts actually are and what they are not.
What is a smart contract?
First of all, let’s determine what a common contract is. It is a deal between two or more participants that obliges them to do something, for instance, to pay for a car rental, or to fix a damaged car in the future in return for a monthly insurance.
Unlike а common contract, а smart contract is supported by a computer code that checks all conditions and executes it automatically. So if a person (say ‘A’) agrees to deliver some goods to another person (‘B’) in three months, a code decides whether this deal is true (were the goods delivered in time?) and performs the required action (money transfer) without a possibility to step back.
The main peculiarity of smart contracts is that they need no trust. Hence, no intermediate person is required to check if all conditions are met. Instead of waiting for someone else to prove compliance with the deal or relying on governments and corporations, people can use smart contracts that will proceed with all these actions in time and unbiased.
Smart contracts are not intelligent
The word “smart” in fact has nothing to do with intelligence, as the contracts cannot have innate intelligence in principle. The “smart” stands for unnecessity for one of the parties to cooperate to meet the conditions of the agreement. While an intelligent contract would act like a judge who might take into consideration all mitigating circumstances, the spirit of the law and so on, a smart contract, on the contrary, is the letter of the law that removes any possible space for ambiguity, never changes rules and does not take into account any secondary conditions.
Smart contracts are complex
Since Ethereum based marketing is so popular, some may think that smart contracts exist only within the Ethereum space. But this is not true. From the very beginning, Bitcoin had Script, a language that allowed smart contracts to be written. Moreover, the very first smart contracts were written in 1995, which is long before Bitcoin was invented. What makes Bitcoin and Ethereum smart contracts different is language details. Solidity, the Ethereum language, is Turing complete, while Script is not. This is the reason why Ethereum smart contracts are more complicated and difficult to examine.
Complexity brings some unwanted consequences, for example, a potential security breach. This is similar to real life. The more complicated a contract is, the harder it is to predict all possible mistakes and drawbacks. When it comes to the smart contract, security must embrace all possible executions of the contract and all its outcomes. In some cases, even the author may be surprised by the contract’s behavior.
Turing completeness of the smart contracts' language causes problems during the analysis. This is due to the nature of such a kind of programing languages. To prove the reliability of a contract means to prove that is has no bugs as a program, which is almost impossible in case of a complex software. You would need several years to learn how to write down a paper contract correctly. Smart contracts require the same competence level. Many contracts written by unskilled people are not even close to being secure. There is a variety of those examined and analyzed.
Bitcoin overcomes this problem by having no opportunity to write a complex structure. It just cannot be too complex. Simple contracts are easy to check for validity and security.
Ethereum obliges all contract authors to be responsible for contract execution consequences.
ETH smart contracts are not really contracts
In theory, it is reasonable to shift the contract results responsibility to its authors. However, in practice, some centralization consequences appear.
One of Ethereum’s main features is “code is law”. This means that all results of the contract cannot be argued. The smart contract authors are to understand that they are on their own. Making a wrong smart contract is a punishment by itself. That is exactly what happened when the DAO crashed.
The DAO (Decentralized Autonomous Organization) is a foundation intended to show how complex Ethereum smart contracts can be. The DAO proposed its users to make deposits to get returns in accordance with the investments carried out by the Organization. The decisions themselves would be reached vs consensus between the stakeholders. With ETH worth of $20, the DAO could raise $150 million in ETH. Unfortunately, the code was not properly secured. Someone found how to break in, and the DAO lost all its funds.
Although, it is technically wrong to say that the DAO attackers were hackers. The core idea of hacking is to get into a system through its vulnerabilities. Indeed, the DAO was hacked by someone, but it was not a malfunction security breach. It was more like using an unforeseen system behavior, which is not hacking at all.
After that Ethereum abandoned the "Сode is law" dogma and rolled the system back returning all the money that was lost. In other words, Ethereum developers corrected all mistakes made by The DAO developers and investors.
That was the beginning of Ethereum Classic. Some network participants refused to step aside from the “Code is law” rule. Furthermore, its developers decided to remove the Turing-completeness as a potentially dangerous property. Common standards associated with smart contracts are ERC20 and ERC721. Both types of contracts can be created avoiding the Turing-completeness.
Smart contracts operate within digital world only
Smart contracts are good enough even without the Turing-completeness. It is much easier to use a smart contract instead of a real one. At least, they do not require going to the court in case of some problems.
For example, a person ‘A’ can prove giving the car for rent. A person ‘B’ can prove money was transferred and get the car in exchange. However, two problems appear here.
The first one comes from the fact that a centralized third party’s trust is unacceptable. Smart contracts cannot rely on a single source, it just makes no sense in the blockchain paradigm. Smart contracts must have a distributed behavior.
The second problem goes thereafter. Within the decentralization approach, smart contracts require a strict link to physical components. The digital world must be tied to the physical one. This problem is known as “the Oracle problem”.
An actual car transfer from ‘A’ to ‘B’ must be recorded in some way. There are several recording approaches but they all require the physical world centralization. Considering the car as an Ethereum-based token, we can imagine its transfer in an atomic ETH swap procedure. But ‘B’ has to believe that this token really correlates with the car. So there must be the Oracle which can guarantee that the token transfer actually means the official car transfer in real life.
Moreover, even if the government accepts the token as a car substitute, what happens if it is stolen or lost? Reissuing, retrievement or any other similar problems raise up a lot of questions.
Connecting the digital space to the real one is a very difficult issue. Real assets are subjected to the legislation which means that they are regulated in a centralized way. This makes digital and real possessions significantly different. Trusting a third party is unacceptable for smart contracts.
Digital objects, like music, movies or books, may face the same problem. They exist according to the “real” legislation and require Oracles for trust issues. Oracles in turn are simple examples of judges. Instead of the machine's simplicity, one needs to provide various outcomes as in real life. Hence, it is neither becomes simple nor trustful.
Only digital bearer instruments can work without Oracles. And this is true for all parties within the deal. A token cannot correlate to something outside blockchain. The only way to get a trustless environment is to have smart contracts as a digital bearer tool.
Unfortunately, smart contracts are not as useful as they might seem. They involve rather more problems than solutions in the described context. The Turing-completeness has made it all worse, leading to unforeseen consequences. Smart contracts cannot be properly secure, trustless, and independent. Unfortunately, as digital bearers they are still limited to decentralized Bitcoin-like protocols.