In this article, we will look at what smart contracts are, what they are, we will get acquainted with different smart contract platforms, their features, and also discuss how they work and what advantages they can bring. This material will be very useful for readers who are not well acquainted with the topic of smart contracts, but want to get closer to understanding it.
How did this work before the advent of smart contracts? Imagine a group of people who want to establish certain rules and conditions for the distribution of values, as well as a certain mechanism to guarantee the implementation of this distribution according to the given rules and conditions. Then they would get together, draw up a paper on which they wrote down their identification details, the terms, the values involved, date them and sign them. This contract was also certified by a trusted party, such as a notary. Further, these people went in different directions with their paper copy of such a contract and began to perform some actions that might not correspond to the contract itself, that is, they did one thing, but on paper it was certified that they should do something completely different. And how to get out of this situation? In fact, one of the group members needs to take this paper, take some evidence, take it to court and achieve compliance between the contract and actual actions. Quite often, it is difficult to achieve fair implementation of this contract, which leads to unpleasant consequences.
What can be said about smart contracts? They combine both the possibility of writing the terms of the contract and the mechanism for their strict implementation. If the conditions have been set and the corresponding transaction or request has been signed, then once that request or transaction has been accepted, it is no longer possible to change the conditions or affect their implementation.
There is one validator or an entire network, as well as a database that stores all smart contracts that were submitted for execution in strict chronological order. It is also important that this database must contain all the trigger conditions for executing the smart contract. In addition, it must take into account the very value whose distribution is described in the contract. If this applies to some digital currency, then this database should take it into account.
In other words, smart contract validators must have access to all the data that the smart contract operates on. For example, a single database should be used to simultaneously account for digital currencies, user balances, user transactions, and timestamps. Then, in a smart contract, the condition may be the user’s balance in a certain currency, the arrival of a certain time, or the fact that a certain transaction has been carried out, but nothing more.
Smart contracts imply that some automation of value distribution is performed, which can only depend on those conditions that are predetermined in advance. In its simplest form, it looks like a contract with strictly defined terms, which is signed by certain parties.
Smart contracts are designed to minimize trust in third parties. Sometimes the decision-making center on which everything depends is completely excluded. In addition, such contracts are easier to audit. This is a consequence of some design features of such a system, but most often we understand by a smart contract a decentralized environment and the presence of functions that allow anyone to analyze the database and conduct a full audit of the execution of contracts. This ensures protection against retroactive data changes that would entail changes in the performance of the contract itself. Digitization of most processes when creating and launching a smart contract often simplifies the technology and cost of their implementation.
It can also be implemented using Bitcoin, although right now Bitcoin can still hardly be called a full-fledged platform for smart contracts. So, we have some buyer and we have an online store. A customer wants to buy a monitor from this store. In the simplest case, the buyer completes and sends a payment, and the online store accepts it, confirms it, and then ships the goods. However, in this situation there is a need for great trust - the buyer must trust the online store for the entire cost of the monitor. Since an online store may have a low reputation in the eyes of the buyer, there is a risk that for some reason, after accepting the payment, the store will refuse service and will not send the goods to the buyer. Therefore, the buyer asks the question (and, accordingly, the online store asks this question) what can be applied in this case in order to minimize such risks and make such transactions more reliable.
In the case of Bitcoin, it is possible to allow the buyer and seller to independently select a mediator. There are many people who are involved in resolving controversial issues. And our participants can choose from a general list of mediators the one they will trust. Together they create a 2 of 3 multisignature address where there are three keys and two signatures with any two keys are required to spend coins from that address. One key will belong to the buyer, the second to the online store, and the third to the mediator. And to such a multisignature address the buyer will send the amount necessary to pay for the monitor. Now, when the seller sees that money is blocked for some time at a multisignature address that depends on him, he can safely send the monitor by mail.
Next, the buyer receives the parcel, inspects the goods and makes a decision on the final purchase. He may completely agree with the service provided and sign the transaction with his key, where he transfers coins from a multisignature address to the seller, or he may be dissatisfied with something. In the second case, he contacts a mediator to put together an alternative transaction that will distribute those coins differently.
Let's say the monitor arrived a little scratched and the kit did not include a cable for connecting to the computer, although the online store website said that the cable should be included in the kit. Then the buyer collects the evidence necessary to prove to the mediator that he was deceived in this situation: he takes screenshots of the site, takes a photo of the mail receipt, takes a photo of the scratches on the monitor and shows that the seal was broken and the cable was pulled out. The online store, in turn, collects its evidence and transfers it to the mediator.
The mediator is interested in simultaneously satisfying both the buyer’s indignation and the interests of the online store (it will become clear why later). It constitutes a transaction in which coins from a multisignature address will be spent in some proportion between the buyer, the online store and the mediator, since he takes a portion for himself as a reward for his work. Let's say 90% of the total amount goes to the seller, 5% to the mediator and 5% compensation to the buyer. The mediator signs this transaction with his key, but it cannot yet be applied, because it requires two signatures, but only one is worth it. It sends such a transaction to both the buyer and the seller. If at least one of them is satisfied with this option for redistributing coins, then the transaction will be pre-signed and distributed to the network. To validate it, it is enough that one of the parties to the transaction agrees with the mediator’s option.
It is important to initially choose a mediator so that both participants trust him. In this case, he will act independently of the interests of one or the other and objectively assess the situation. If the mediator does not provide an option for distributing coins that will satisfy at least one participant, then, having agreed together, both the buyer and the online store can send the coins to a new multisignature address by putting their two signatures. The new multisignature address will be compiled with a different mediator, who may be more competent in the matter and provide a better option.
Let's say there are three guys who recently moved into the same dorm room. The three of them are interested in buying a refrigerator for their room that they can use together. One of them volunteered to collect the necessary amount to buy a refrigerator and negotiate with the seller. However, they only recently met each other and there is not enough trust between them. Obviously, two of them are taking a risk by giving money to the third. In addition, they need to reach an agreement in choosing a seller.
They can use the escrow service, that is, choose a mediator who will monitor the execution of the transaction and resolve controversial issues if any arise. Then, having agreed, they draw up a smart contract and prescribe certain conditions in it.
The first condition is that before a certain time, say within one week, the corresponding smart contract account must receive three payments from certain addresses for a certain amount. If this does not happen, the smart contract stops executing and returns the coins to all participants. If the condition is met, then the values of the seller and mediator identifiers are set, and the condition is checked that all participants agree with the choice of the seller and mediator. When all conditions are met, then the funds will be transferred to the specified addresses. This approach can protect participants from fraud from any side and generally eliminates the need to trust.
We see in this example the very principle that this ability to step-by-step set parameters for fulfilling each condition allows you to create systems of any complexity and depth of nested levels. In addition, you can first define the first condition in the smart contract, and only after its fulfillment can you set parameters for the next condition. In other words, the condition is formally written, and parameters for it can be set already during its operation.
Smart contracts can be distinguished by their execution environment, which can be either centralized or decentralized. In the case of decentralization, we have much greater independence and fault tolerance when executing smart contracts.
They can also be distinguished by the process of setting and fulfilling conditions: they can be freely programmable, limited or predefined, i.e. strictly typed. When there are only 4 specific smart contracts on the smart contract platform, the parameters for them can be set in any way. Accordingly, setting them is much simpler: we select a contract from the list and pass the parameters.
According to the initiation method, there are automated smart contracts, that is, when certain conditions occur, they are self-executing, and there are contracts in which the conditions are specified, but the platform does not automatically check their fulfillment; for this they need to be initiated separately.
In addition, smart contracts vary in their level of privacy. They can be either completely open, partially or completely confidential. The latter means that third-party observers do not see the terms of smart contracts. However, the topic of privacy is very broad and it is better to consider it separately from the current article.
Below we will take a closer look at the first three criteria to bring more clarity to the understanding of the current topic.
Based on the execution environment, a distinction is made between centralized and decentralized smart contract platforms. In the case of centralized digital contracts, a single service is used, where there is only one validator and there may be a backup and recovery service, which is also centrally managed. There is one database that stores all the necessary information to set the terms of the smart contract and distribute the value that is taken into account in this very service database. Such a centralized service has a client who sets conditions with certain requests and uses such contracts. Due to the centralized nature of the platform, authentication mechanisms may be less secure than in cryptocurrencies.
As an example, we can take mobile communication providers (different mobile operators). Let's say a certain operator keeps a centralized record of traffic on its servers, which can be transmitted in different formats, for example: in the form of voice calls, SMS transmission, mobile Internet traffic, and according to different standards, and also keeps records of funds on user balances. Accordingly, the mobile communications provider can draw up contracts for accounting for the services provided and their payment with different conditions. In this case, it is easy to set conditions like “send an SMS with such and such a code to such and such a number and you will receive such and such conditions for traffic distribution.”
One more example can be given: traditional banks with expanded functionality of Internet banking and such very simple contracts as regular payments, automatic conversion of incoming payments, automatic deduction of interest to a specified account, etc.
If we are talking about smart contracts with a decentralized environment execution, then we have a group of validators. Ideally, anyone can become a validator. Due to the database synchronization protocol and reaching consensus, we have some common database that will now store all transactions with strictly described contracts, and not some conditional queries, the formats of which often change, and there is no open specification. Here, transactions will contain instructions to execute the contract according to a strict specification. This specification is open and, therefore, platform users themselves can audit and validate smart contracts. Here we see that decentralized platforms are superior to centralized ones in terms of independence and fault tolerance, but their design and maintenance are much more complex.
There are also arbitrary smart contracts, but not Turing complete ones. This includes Bitcoin and Litecoin with their own script. This means that you can use only certain operations in any order, but you can no longer write loops and your own algorithms.
In addition, there are smart contract platforms that implement pre-defined smart contracts. These include Bitshares and Steemit. Bitshares has a range of smart contracts for trading, account management, management of the platform itself and its parameters. Steemit is a similar platform, but it is no longer focused on issuing tokens and trading, like Bitshares, but on blogging, i.e. it stores and processes content in a decentralized manner.
Arbitrary Turing-complete contracts include the Ethereum platform and RootStock, which is still under development. Therefore, below we will dwell in a little more detail on the Ethereum smart contract platform.
For smart contracts that are freely programmed, execution is not automated. To initiate such a smart contract, at virtually every step you need to create a new transaction, which will call the next execution stage or the next smart contract method, pay the appropriate commission and wait for the transaction to be confirmed. Execution may complete successfully or not, because the smart contract code is arbitrary and some unpredictable moments may appear, such as an eternal loop, a lack of some parameters and arguments, unhandled exceptions, etc.
The user account is controlled only by the personal key of the electronic signature. The account owner generates his own key pair for electronic signature using the ECDSA (Elliptic Curve Digital Signature Algorithm) algorithm. Only transactions signed with this key can change the state of this account.
A separate logic is provided for the smart contract account. It can only be controlled by pre-defined software code that completely determines the behavior of the smart contract: how it will manage its coins under certain circumstances, at the initiative of which user and under what additional conditions these coins will be distributed. If some points are not provided for by the developers in the program code, problems may arise. For example, a smart contract may receive a certain state in which it does not accept initiation of further execution from any of the users. In this case, the coins will actually be frozen, because the smart contract does not provide for exiting this state.
Please note that the account identifier in Ethereum is encoded in hex without applying a checksum, unlike Bitcoin and many other systems, where the address is encoded in a base 58 number system with the addition of a checksum. This means that you need to be careful when working with account identifiers in Ethereum: even one mistake in the identifier is guaranteed to lead to the loss of coins.
There is an important feature and it is that a user account at the general database level is created at the moment when he accepts the first incoming payment.
Creating a smart contract account takes a completely different approach. Initially, one of the users writes the source code of the smart contract, after which the code is passed through a compiler special for the Ethereum platform, obtaining bytecode for its own Ethereum virtual machine. The resulting bytecode is placed in a special field of the transaction. It is certified on behalf of the initiator's account. Next, this transaction is propagated throughout the network and places the smart contract code. The commission for the transaction and, accordingly, for the execution of the contract is withdrawn from the balance of the initiator’s account.
Each smart contract necessarily contains its own constructor (of this contract). It may be empty or it may have content. After the constructor is executed, a smart contract account identifier is created, using which you can send coins, call certain smart contract methods, etc.
An Ethereum transaction consists of several fields. The first of these, nonce, is a certain serial number of the transaction relative to the account itself that distributes it and is its author. This is necessary in order to distinguish double transactions, that is, to exclude the case when the same transaction is accepted twice. By using an identifier, each transaction has a unique hash value.
Next comes a field such as gas price . This indicates the price at which the Ethereum base currency is converted into gas, which is used to pay for the execution of the smart contract and the allocation of the virtual machine resource. What does it mean?
In Bitcoin, fees are paid directly by the base currency—Bitcoin itself. This is possible thanks to a simple mechanism for calculating them: we pay strictly for the amount of data contained in the transaction. In Ethereum the situation is more complicated, because it is very difficult to rely on the volume of transaction data. Here, the transaction may also contain program code that will be executed on the virtual machine, and each operation of the virtual machine may have a different complexity. There are also operations that allocate memory for variables. They will have their own complexity, on which the payment for each operation will depend.
The cost of each operation in gas equivalent will be constant. It is introduced specifically in order to determine the constant cost of each operation. Depending on the load on the network, the gas price will change, that is, the coefficient according to which the base currency will be converted into this auxiliary unit to pay the commission.
There is one more feature of a transaction in Ethereum: the bytecode that it contains for execution in a virtual machine will be executed until it completes with some result (success or failure) or until a certain amount of coins allocated runs out to pay the commission. It is in order to avoid a situation where, in the event of some error, all the coins from the sender’s account were spent on commission (for example, some kind of eternal cycle started in a virtual machine), there is the following field - start gas (it is often called gas limit) - it defines the maximum amount of coins that the sender is willing to spend to complete a specific transaction.
The next field is called destination address . This includes the address of the recipient of the coins or the address of a specific smart contract whose methods will be called. It is followed by the value field , where the amount of coins that are sent to the destination address is entered.
Next is an interesting field called data, where the whole structure fits. This is not a separate field, but a whole structure in which the code for the virtual machine is defined. You can place arbitrary data here - there are separate rules for this.
And the last field is called signature . It simultaneously contains both the electronic signature of the author of this transaction and the public key with which this signature will be verified. From the public key you can obtain the account identifier of the sender of this transaction, that is, uniquely identify the sender’s account in the system itself. We found out the main thing about the structure of the transaction.
Above is a simplified source code that can hold users' coins and return them on demand.
So, there is a Bank smart contract that performs the following functions: it accumulates coins on its balance, that is, when a transaction is confirmed and such a smart contract is placed, a new account is created that can contain coins on its balance; it remembers users and the distribution of coins between them; has several methods for managing balances, that is, it is possible to replenish, withdraw and check the user’s balance.
Let's go through each line of source code. This contract has constant fields. One of them, with type address, is called owner. Here the contract remembers the address of the user who created this smart contract. Further, there is a dynamic structure that maintains correspondence between user addresses and balances.
This is followed by the Bank method - it has the same name as the contract. Accordingly, this is its constructor. Here the owner variable is assigned the address of the person who placed this smart contract on the network. This is the only thing that happens in this constructor. That is, msg in this case is exactly the data that was transferred to the virtual machine along with the transaction containing the entire code of this contract. Accordingly, msg.sender is the author of this transaction that hosts this code. He will be the owner of the smart contract.
The deposit method allows you to transfer a certain number of coins to the contract account by transaction. In this case, the smart contract, receiving these coins, leaves them on its balance sheet, but records in the balances structure who exactly was the sender of these coins in order to know who they belong to.
The next method is called withdraw and it takes one parameter - the amount of coins that someone wants to withdraw from this bank. This checks whether there are enough coins in the balance of the user who calls this method to send them. If there are enough of them, then the smart contract itself returns that number of coins to the caller.
Next comes the method for checking the user's current balance. Whoever calls this method will be used to retrieve this balance in the smart contract. It is worth noting that the modifier of this method is view. This means that the method itself does not change the variables of its class in any way and it is actually only a read method. No separate transaction is created to call this method, no fee is paid, and all calculations are performed locally, after which the user receives the result.
The kill method is needed to destroy the state of the smart contract. And here there is an additional check whether the caller of this method is the owner of this contract. If so, then the contract self-destructs, and the destruction function takes one parameter - the account identifier to which the contract will send all the coins remaining on its balance. In this case, the remaining coins will automatically go to the address of the contract owner.
A full node on the Ethereum network must have at least four modules.
The first, as for any decentralized protocol, is the P2P networking module - a module for network connection and work with other nodes, where blocks, transactions, and information about other nodes are exchanged. This is a traditional component for all decentralized cryptocurrencies.
Next, we have a module for storing blockchain data, processing, selecting a priority branch, adding blocks, unlinking blocks, checking these blocks, etc.
The third module is called EVM (Ethereum virtual machine) - this is a virtual machine that receives bytes code from Ethereum transaction. This module takes the current state of a particular account and makes changes to its state based on the received bytecode. The virtual machine version on each network node must be the same. The calculations that take place on each Ethereum node are exactly the same, but they occur in an asynchronous manner: someone checks and accepts this transaction earlier, that is, executes all the code contained in it, and someone later. Accordingly, when a transaction is created, it is distributed to the network, the nodes accept it, and at the time of verification, in the same way that Bitcoin Script is executed in Bitcoin, the bytecode of the virtual machine is executed here.
A transaction is considered verified if all the code contained in it has been executed, a new state of a certain account has been generated and saved until it is clear whether this transaction has been applied or not. If the transaction is applied, then this state is considered not only completed, but also current. There is a database that stores the state of each account for each network node. Due to the fact that all calculations occur in the same way and the state of the blockchain is the same, the database containing the states of all accounts will also be the same for each node.
Let's look at the restrictions that are imposed on a virtual machine, and, accordingly, dispel some myths about smart contracts. On a virtual machine, which can be not only in Ethereum, but also in similar platforms, you can perform truly arbitrary logical operations, that is, write code and it will be executed there, you can additionally allocate memory. However, the fee is paid separately for each operation and for each additional unit of memory allocated.
Next, the virtual machine can read data from the blockchain database in order to use this data as a trigger to execute one or another smart contract logic. The virtual machine can create and send transactions, it can create new contracts and call methods of other smart contracts that are already published on the network: existing, accessible, etc.
The most common myth is that Ethereum smart contracts can use information from any Internet resources under your own conditions. The truth is that a virtual machine cannot send a network request to some external information resource on the Internet, that is, it is impossible to write a smart contract that will distribute value between users depending on, say, what the weather is like outside, or who won some championship, or based on what other incident happened in the outside world, because information about these incidents is simply not in the database of the platform itself. That is, there is nothing on the blockchain about this. If it does not appear there, then the virtual machine cannot use this data as triggers.
The second disadvantage is that the virtual machine itself is not perfect, since it is also written by people. It can execute arbitrary commands, and therein lies the vulnerability: a number of commands can be configured in a certain way that will lead to consequences that were unforeseen in advance. This is a very complex area, but there are already several studies that show that these vulnerabilities exist in the current version of the Ethereum network and they can lead to the failure of many smart contracts.
Another big difficulty, it can be considered a disadvantage. It lies in the fact that you can practically or technically come to the conclusion that if you compile the bytecode of a contract that will be executed on a virtual machine, you can determine some specific order of operations. When performed together, these operations will greatly load the virtual machine and slow it down disproportionately to the fee that was paid for performing these operations.
In the past, there was already a period in the development of Ethereum, when many guys who understood in detail the operation of a virtual machine found such vulnerabilities. In fact, transactions paid a very small fee, but practically slowed down the entire network. These problems are very difficult to solve, since it is necessary, firstly, to determine them, secondly, to adjust the price for performing these operations and, thirdly, to carry out a hard fork, which means updating all network nodes to a new version of the software, and then simultaneous activation of these changes.
As for Ethereum, a lot of research has been carried out, a lot of practical experience has been gained: both positive and negative, but nevertheless there remain difficulties and vulnerabilities that still have to be dealt with somehow.
So, the thematic part of the article is completed, let’s move on to questions that arise quite often.
The answer here will be twofold. Why? Because on the one hand, a smart contract is defined once and it no longer implies any changes, and on the other hand, it can have pre-written logic that provides for a complete or partial change of some conditions. That is, if you want to change something in your smart contract, then you must prescribe the conditions under which you can update these conditions. Accordingly, only in such a prudent manner can the renewal of the contract be organized. But here, too, you can run into trouble: make some mistake and get a corresponding vulnerability. Therefore, such things need to be very detailed and carefully designed and tested.
— What if the mediator enters into an agreement with one of the participating parties: escrow or smart contract? Is a mediator required in a smart contract?
A mediator is not required in a smart contract. It may not exist. If, in the case of escrow, the mediator enters into a conspiracy with one of the parties, then yes, this scheme then sharply loses all its value. Therefore, mediators are selected in such a way that they are trusted by all parties involved in this process at the same time. Accordingly, you simply will not transfer coins to a multisignature address with a mediator that you do not trust.
— Is it possible with one Ethereum transaction to transfer many different tokens from your address to different target addresses, for example, exchange addresses where these tokens are traded?
This is a good question and it concerns the Ethereum transaction model and how it differs from the Bitcoin model. And the difference is radical. If in the Ethereum transaction model you simply transfer coins, then they are only transferred from one address to another, no change, just the specific amount you specified. In other words, this is not a model of unspent outputs (UTXO), but a model of accounts and corresponding balances. It is theoretically possible to send several different tokens in one transaction at once if you write a cunning smart contract, but you will still have to make many transactions, create a contract, then transfer tokens and coins to it, and then call the appropriate method. This requires effort and time, so in practice it doesn’t work like that and all payments in Ethereum are made in separate transactions.
— One of the myths about the Ethereum platform is that it is impossible to describe conditions that will depend on data from an external Internet resource, so what to do then?
The solution is that the smart contract itself can provide one or more so-called trusted oracles, which collect data about the state of things in the outside world and transmit it to the smart contracts through special methods. The contract itself considers the data that it received from trusted parties to be true. For greater reliability, simply choose a large group of oracles and minimize the risk of their collusion. The contract itself may not take into account data from oracles that contradict the majority.
One of the lectures in the online course on Blockchain, “Introduction to Smart Contracts,” is devoted to this topic.
Regular contract vs. smart contract
Before we delve into the details, let's take an example of the differences between a regular contract, which is specified on paper, and a smart contract, which is represented digitally.
How did this work before the advent of smart contracts? Imagine a group of people who want to establish certain rules and conditions for the distribution of values, as well as a certain mechanism to guarantee the implementation of this distribution according to the given rules and conditions. Then they would get together, draw up a paper on which they wrote down their identification details, the terms, the values involved, date them and sign them. This contract was also certified by a trusted party, such as a notary. Further, these people went in different directions with their paper copy of such a contract and began to perform some actions that might not correspond to the contract itself, that is, they did one thing, but on paper it was certified that they should do something completely different. And how to get out of this situation? In fact, one of the group members needs to take this paper, take some evidence, take it to court and achieve compliance between the contract and actual actions. Quite often, it is difficult to achieve fair implementation of this contract, which leads to unpleasant consequences.
What can be said about smart contracts? They combine both the possibility of writing the terms of the contract and the mechanism for their strict implementation. If the conditions have been set and the corresponding transaction or request has been signed, then once that request or transaction has been accepted, it is no longer possible to change the conditions or affect their implementation.
There is one validator or an entire network, as well as a database that stores all smart contracts that were submitted for execution in strict chronological order. It is also important that this database must contain all the trigger conditions for executing the smart contract. In addition, it must take into account the very value whose distribution is described in the contract. If this applies to some digital currency, then this database should take it into account.
In other words, smart contract validators must have access to all the data that the smart contract operates on. For example, a single database should be used to simultaneously account for digital currencies, user balances, user transactions, and timestamps. Then, in a smart contract, the condition may be the user’s balance in a certain currency, the arrival of a certain time, or the fact that a certain transaction has been carried out, but nothing more.
Definition of a smart contract
In general, the terminology itself was coined by researcher Nick Szabo and first used in 1994, and was documented in 1997 in an article that describes the very idea of smart contracts.Smart contracts imply that some automation of value distribution is performed, which can only depend on those conditions that are predetermined in advance. In its simplest form, it looks like a contract with strictly defined terms, which is signed by certain parties.
Smart contracts are designed to minimize trust in third parties. Sometimes the decision-making center on which everything depends is completely excluded. In addition, such contracts are easier to audit. This is a consequence of some design features of such a system, but most often we understand by a smart contract a decentralized environment and the presence of functions that allow anyone to analyze the database and conduct a full audit of the execution of contracts. This ensures protection against retroactive data changes that would entail changes in the performance of the contract itself. Digitization of most processes when creating and launching a smart contract often simplifies the technology and cost of their implementation.
A simple example - Escrow service
Let's look at a very simple example. It will help you come closer to understanding the functionality of smart contracts, as well as better understand in which cases they should be used.It can also be implemented using Bitcoin, although right now Bitcoin can still hardly be called a full-fledged platform for smart contracts. So, we have some buyer and we have an online store. A customer wants to buy a monitor from this store. In the simplest case, the buyer completes and sends a payment, and the online store accepts it, confirms it, and then ships the goods. However, in this situation there is a need for great trust - the buyer must trust the online store for the entire cost of the monitor. Since an online store may have a low reputation in the eyes of the buyer, there is a risk that for some reason, after accepting the payment, the store will refuse service and will not send the goods to the buyer. Therefore, the buyer asks the question (and, accordingly, the online store asks this question) what can be applied in this case in order to minimize such risks and make such transactions more reliable.
In the case of Bitcoin, it is possible to allow the buyer and seller to independently select a mediator. There are many people who are involved in resolving controversial issues. And our participants can choose from a general list of mediators the one they will trust. Together they create a 2 of 3 multisignature address where there are three keys and two signatures with any two keys are required to spend coins from that address. One key will belong to the buyer, the second to the online store, and the third to the mediator. And to such a multisignature address the buyer will send the amount necessary to pay for the monitor. Now, when the seller sees that money is blocked for some time at a multisignature address that depends on him, he can safely send the monitor by mail.
Next, the buyer receives the parcel, inspects the goods and makes a decision on the final purchase. He may completely agree with the service provided and sign the transaction with his key, where he transfers coins from a multisignature address to the seller, or he may be dissatisfied with something. In the second case, he contacts a mediator to put together an alternative transaction that will distribute those coins differently.
Let's say the monitor arrived a little scratched and the kit did not include a cable for connecting to the computer, although the online store website said that the cable should be included in the kit. Then the buyer collects the evidence necessary to prove to the mediator that he was deceived in this situation: he takes screenshots of the site, takes a photo of the mail receipt, takes a photo of the scratches on the monitor and shows that the seal was broken and the cable was pulled out. The online store, in turn, collects its evidence and transfers it to the mediator.
The mediator is interested in simultaneously satisfying both the buyer’s indignation and the interests of the online store (it will become clear why later). It constitutes a transaction in which coins from a multisignature address will be spent in some proportion between the buyer, the online store and the mediator, since he takes a portion for himself as a reward for his work. Let's say 90% of the total amount goes to the seller, 5% to the mediator and 5% compensation to the buyer. The mediator signs this transaction with his key, but it cannot yet be applied, because it requires two signatures, but only one is worth it. It sends such a transaction to both the buyer and the seller. If at least one of them is satisfied with this option for redistributing coins, then the transaction will be pre-signed and distributed to the network. To validate it, it is enough that one of the parties to the transaction agrees with the mediator’s option.
It is important to initially choose a mediator so that both participants trust him. In this case, he will act independently of the interests of one or the other and objectively assess the situation. If the mediator does not provide an option for distributing coins that will satisfy at least one participant, then, having agreed together, both the buyer and the online store can send the coins to a new multisignature address by putting their two signatures. The new multisignature address will be compiled with a different mediator, who may be more competent in the matter and provide a better option.
Example with a dormitory and a refrigerator
Let's look at a more complex example that displays the capabilities of a smart contract more explicitly.
Let's say there are three guys who recently moved into the same dorm room. The three of them are interested in buying a refrigerator for their room that they can use together. One of them volunteered to collect the necessary amount to buy a refrigerator and negotiate with the seller. However, they only recently met each other and there is not enough trust between them. Obviously, two of them are taking a risk by giving money to the third. In addition, they need to reach an agreement in choosing a seller.
They can use the escrow service, that is, choose a mediator who will monitor the execution of the transaction and resolve controversial issues if any arise. Then, having agreed, they draw up a smart contract and prescribe certain conditions in it.
The first condition is that before a certain time, say within one week, the corresponding smart contract account must receive three payments from certain addresses for a certain amount. If this does not happen, the smart contract stops executing and returns the coins to all participants. If the condition is met, then the values of the seller and mediator identifiers are set, and the condition is checked that all participants agree with the choice of the seller and mediator. When all conditions are met, then the funds will be transferred to the specified addresses. This approach can protect participants from fraud from any side and generally eliminates the need to trust.
We see in this example the very principle that this ability to step-by-step set parameters for fulfilling each condition allows you to create systems of any complexity and depth of nested levels. In addition, you can first define the first condition in the smart contract, and only after its fulfillment can you set parameters for the next condition. In other words, the condition is formally written, and parameters for it can be set already during its operation.
Classification of smart contracts
For classification, you can set different groups of criteria. However, at the moment of technology development, four of them are relevant.Smart contracts can be distinguished by their execution environment, which can be either centralized or decentralized. In the case of decentralization, we have much greater independence and fault tolerance when executing smart contracts.
They can also be distinguished by the process of setting and fulfilling conditions: they can be freely programmable, limited or predefined, i.e. strictly typed. When there are only 4 specific smart contracts on the smart contract platform, the parameters for them can be set in any way. Accordingly, setting them is much simpler: we select a contract from the list and pass the parameters.
According to the initiation method, there are automated smart contracts, that is, when certain conditions occur, they are self-executing, and there are contracts in which the conditions are specified, but the platform does not automatically check their fulfillment; for this they need to be initiated separately.
In addition, smart contracts vary in their level of privacy. They can be either completely open, partially or completely confidential. The latter means that third-party observers do not see the terms of smart contracts. However, the topic of privacy is very broad and it is better to consider it separately from the current article.
Below we will take a closer look at the first three criteria to bring more clarity to the understanding of the current topic.
Smart contracts by runtime
Based on the execution environment, a distinction is made between centralized and decentralized smart contract platforms. In the case of centralized digital contracts, a single service is used, where there is only one validator and there may be a backup and recovery service, which is also centrally managed. There is one database that stores all the necessary information to set the terms of the smart contract and distribute the value that is taken into account in this very service database. Such a centralized service has a client who sets conditions with certain requests and uses such contracts. Due to the centralized nature of the platform, authentication mechanisms may be less secure than in cryptocurrencies.
As an example, we can take mobile communication providers (different mobile operators). Let's say a certain operator keeps a centralized record of traffic on its servers, which can be transmitted in different formats, for example: in the form of voice calls, SMS transmission, mobile Internet traffic, and according to different standards, and also keeps records of funds on user balances. Accordingly, the mobile communications provider can draw up contracts for accounting for the services provided and their payment with different conditions. In this case, it is easy to set conditions like “send an SMS with such and such a code to such and such a number and you will receive such and such conditions for traffic distribution.”
One more example can be given: traditional banks with expanded functionality of Internet banking and such very simple contracts as regular payments, automatic conversion of incoming payments, automatic deduction of interest to a specified account, etc.
If we are talking about smart contracts with a decentralized environment execution, then we have a group of validators. Ideally, anyone can become a validator. Due to the database synchronization protocol and reaching consensus, we have some common database that will now store all transactions with strictly described contracts, and not some conditional queries, the formats of which often change, and there is no open specification. Here, transactions will contain instructions to execute the contract according to a strict specification. This specification is open and, therefore, platform users themselves can audit and validate smart contracts. Here we see that decentralized platforms are superior to centralized ones in terms of independence and fault tolerance, but their design and maintenance are much more complex.
Smart contracts by the method of setting and fulfilling conditions
Now let’s take a closer look at how smart contracts can differ in the way they set and fulfill conditions. Here we turn our attention to smart contracts that are randomly programmable and Turing complete. A Turing-complete smart contract allows you to set almost any algorithms as conditions for the execution of the contract: write cycles, some functions for calculating probabilities, and the like - right down to your own electronic signature algorithms. In this case, we mean truly arbitrary writing of logic.There are also arbitrary smart contracts, but not Turing complete ones. This includes Bitcoin and Litecoin with their own script. This means that you can use only certain operations in any order, but you can no longer write loops and your own algorithms.
In addition, there are smart contract platforms that implement pre-defined smart contracts. These include Bitshares and Steemit. Bitshares has a range of smart contracts for trading, account management, management of the platform itself and its parameters. Steemit is a similar platform, but it is no longer focused on issuing tokens and trading, like Bitshares, but on blogging, i.e. it stores and processes content in a decentralized manner.
Arbitrary Turing-complete contracts include the Ethereum platform and RootStock, which is still under development. Therefore, below we will dwell in a little more detail on the Ethereum smart contract platform.
Smart contracts by initiation method
Based on the method of initiation, smart contracts can also be divided into at least two groups: automated and manual (not automated). Automated ones are characterized by the fact that, given all known parameters and conditions, the smart contract is completely executed automatically, that is, it does not require sending any additional transactions and spending an additional commission on each subsequent execution. The platform itself has all the data to calculate how the smart contract will complete. The logic there is not arbitrary, but predetermined and all this is predictable. That is, you can estimate in advance the complexity of executing a smart contract, use some kind of constant commission for it, and all processes for its implementation are more efficient.For smart contracts that are freely programmed, execution is not automated. To initiate such a smart contract, at virtually every step you need to create a new transaction, which will call the next execution stage or the next smart contract method, pay the appropriate commission and wait for the transaction to be confirmed. Execution may complete successfully or not, because the smart contract code is arbitrary and some unpredictable moments may appear, such as an eternal loop, a lack of some parameters and arguments, unhandled exceptions, etc.
Ethereum Accounts
Ethereum Account Types
Let's look at what types of accounts there can be on the Ethereum platform. There are only two types of accounts here and there are no other options. The first type is called a user account, the second is a contract account. Let's figure out how they differ.The user account is controlled only by the personal key of the electronic signature. The account owner generates his own key pair for electronic signature using the ECDSA (Elliptic Curve Digital Signature Algorithm) algorithm. Only transactions signed with this key can change the state of this account.
A separate logic is provided for the smart contract account. It can only be controlled by pre-defined software code that completely determines the behavior of the smart contract: how it will manage its coins under certain circumstances, at the initiative of which user and under what additional conditions these coins will be distributed. If some points are not provided for by the developers in the program code, problems may arise. For example, a smart contract may receive a certain state in which it does not accept initiation of further execution from any of the users. In this case, the coins will actually be frozen, because the smart contract does not provide for exiting this state.
How accounts are created on Ethereum
In the case of a user account, the owner independently generates a key pair using ECDSA. It is important to note that Ethereum uses exactly the same algorithm and exactly the same elliptic curve for electronic signatures as Bitcoin, but the address is calculated in a slightly different way. Here, the result of double hashing is no longer used, as in Bitcoin, but single hashing is provided with the Keccak function at a length of 256 bits. The least significant bits are cut off from the resulting value, namely the least significant 160 bits of the output hash value. As a result, we get an address in Ethereum. In fact, it takes up 20 bytes.Please note that the account identifier in Ethereum is encoded in hex without applying a checksum, unlike Bitcoin and many other systems, where the address is encoded in a base 58 number system with the addition of a checksum. This means that you need to be careful when working with account identifiers in Ethereum: even one mistake in the identifier is guaranteed to lead to the loss of coins.
There is an important feature and it is that a user account at the general database level is created at the moment when he accepts the first incoming payment.
Creating a smart contract account takes a completely different approach. Initially, one of the users writes the source code of the smart contract, after which the code is passed through a compiler special for the Ethereum platform, obtaining bytecode for its own Ethereum virtual machine. The resulting bytecode is placed in a special field of the transaction. It is certified on behalf of the initiator's account. Next, this transaction is propagated throughout the network and places the smart contract code. The commission for the transaction and, accordingly, for the execution of the contract is withdrawn from the balance of the initiator’s account.
Each smart contract necessarily contains its own constructor (of this contract). It may be empty or it may have content. After the constructor is executed, a smart contract account identifier is created, using which you can send coins, call certain smart contract methods, etc.
Ethereum Transaction Structure
To make it clearer, we will begin to look at the structure of an Ethereum transaction and an example smart contract code.
An Ethereum transaction consists of several fields. The first of these, nonce, is a certain serial number of the transaction relative to the account itself that distributes it and is its author. This is necessary in order to distinguish double transactions, that is, to exclude the case when the same transaction is accepted twice. By using an identifier, each transaction has a unique hash value.
Next comes a field such as gas price . This indicates the price at which the Ethereum base currency is converted into gas, which is used to pay for the execution of the smart contract and the allocation of the virtual machine resource. What does it mean?
In Bitcoin, fees are paid directly by the base currency—Bitcoin itself. This is possible thanks to a simple mechanism for calculating them: we pay strictly for the amount of data contained in the transaction. In Ethereum the situation is more complicated, because it is very difficult to rely on the volume of transaction data. Here, the transaction may also contain program code that will be executed on the virtual machine, and each operation of the virtual machine may have a different complexity. There are also operations that allocate memory for variables. They will have their own complexity, on which the payment for each operation will depend.
The cost of each operation in gas equivalent will be constant. It is introduced specifically in order to determine the constant cost of each operation. Depending on the load on the network, the gas price will change, that is, the coefficient according to which the base currency will be converted into this auxiliary unit to pay the commission.
There is one more feature of a transaction in Ethereum: the bytecode that it contains for execution in a virtual machine will be executed until it completes with some result (success or failure) or until a certain amount of coins allocated runs out to pay the commission. It is in order to avoid a situation where, in the event of some error, all the coins from the sender’s account were spent on commission (for example, some kind of eternal cycle started in a virtual machine), there is the following field - start gas (it is often called gas limit) - it defines the maximum amount of coins that the sender is willing to spend to complete a specific transaction.
The next field is called destination address . This includes the address of the recipient of the coins or the address of a specific smart contract whose methods will be called. It is followed by the value field , where the amount of coins that are sent to the destination address is entered.
Next is an interesting field called data, where the whole structure fits. This is not a separate field, but a whole structure in which the code for the virtual machine is defined. You can place arbitrary data here - there are separate rules for this.
And the last field is called signature . It simultaneously contains both the electronic signature of the author of this transaction and the public key with which this signature will be verified. From the public key you can obtain the account identifier of the sender of this transaction, that is, uniquely identify the sender’s account in the system itself. We found out the main thing about the structure of the transaction.
Example smart contract code for Solidity
Let's now take a closer look at the simplest smart contract using an example.
Code:
contract Bank {
address owner;
mapping(address => uint) balances;
function Bank() {
owner = msg.sender;
}
function deposit() public payable {
balances[msg.sender] += msg.value;
}
function withdraw(uint amount) public {
if (balances[msg.sender] >= amount) {
balances[msg.sender] -= amount;
msg.sender.transfer(amount);
}
}
function getMyBalance() public view returns(uint) {
return balances[msg.sender];
}
function kill() public {
if (msg.sender == owner)
selfdestruct(owner);
}
}Above is a simplified source code that can hold users' coins and return them on demand.
So, there is a Bank smart contract that performs the following functions: it accumulates coins on its balance, that is, when a transaction is confirmed and such a smart contract is placed, a new account is created that can contain coins on its balance; it remembers users and the distribution of coins between them; has several methods for managing balances, that is, it is possible to replenish, withdraw and check the user’s balance.
Let's go through each line of source code. This contract has constant fields. One of them, with type address, is called owner. Here the contract remembers the address of the user who created this smart contract. Further, there is a dynamic structure that maintains correspondence between user addresses and balances.
This is followed by the Bank method - it has the same name as the contract. Accordingly, this is its constructor. Here the owner variable is assigned the address of the person who placed this smart contract on the network. This is the only thing that happens in this constructor. That is, msg in this case is exactly the data that was transferred to the virtual machine along with the transaction containing the entire code of this contract. Accordingly, msg.sender is the author of this transaction that hosts this code. He will be the owner of the smart contract.
The deposit method allows you to transfer a certain number of coins to the contract account by transaction. In this case, the smart contract, receiving these coins, leaves them on its balance sheet, but records in the balances structure who exactly was the sender of these coins in order to know who they belong to.
The next method is called withdraw and it takes one parameter - the amount of coins that someone wants to withdraw from this bank. This checks whether there are enough coins in the balance of the user who calls this method to send them. If there are enough of them, then the smart contract itself returns that number of coins to the caller.
Next comes the method for checking the user's current balance. Whoever calls this method will be used to retrieve this balance in the smart contract. It is worth noting that the modifier of this method is view. This means that the method itself does not change the variables of its class in any way and it is actually only a read method. No separate transaction is created to call this method, no fee is paid, and all calculations are performed locally, after which the user receives the result.
The kill method is needed to destroy the state of the smart contract. And here there is an additional check whether the caller of this method is the owner of this contract. If so, then the contract self-destructs, and the destruction function takes one parameter - the account identifier to which the contract will send all the coins remaining on its balance. In this case, the remaining coins will automatically go to the address of the contract owner.
How does a full node on the Ethereum network work?
Let's look schematically at how such smart contracts are executed on the Ethereum platform and how a full network node works.
A full node on the Ethereum network must have at least four modules.
The first, as for any decentralized protocol, is the P2P networking module - a module for network connection and work with other nodes, where blocks, transactions, and information about other nodes are exchanged. This is a traditional component for all decentralized cryptocurrencies.
Next, we have a module for storing blockchain data, processing, selecting a priority branch, adding blocks, unlinking blocks, checking these blocks, etc.
The third module is called EVM (Ethereum virtual machine) - this is a virtual machine that receives bytes code from Ethereum transaction. This module takes the current state of a particular account and makes changes to its state based on the received bytecode. The virtual machine version on each network node must be the same. The calculations that take place on each Ethereum node are exactly the same, but they occur in an asynchronous manner: someone checks and accepts this transaction earlier, that is, executes all the code contained in it, and someone later. Accordingly, when a transaction is created, it is distributed to the network, the nodes accept it, and at the time of verification, in the same way that Bitcoin Script is executed in Bitcoin, the bytecode of the virtual machine is executed here.
A transaction is considered verified if all the code contained in it has been executed, a new state of a certain account has been generated and saved until it is clear whether this transaction has been applied or not. If the transaction is applied, then this state is considered not only completed, but also current. There is a database that stores the state of each account for each network node. Due to the fact that all calculations occur in the same way and the state of the blockchain is the same, the database containing the states of all accounts will also be the same for each node.
Myths and limitations of smart contracts
As for the restrictions that exist for smart contract platforms similar to Ethereum, the following can be cited:- code execution;
- allocate memory;
- blockchain data;
- send payments;
- create new contract;
- call other contracts.
Let's look at the restrictions that are imposed on a virtual machine, and, accordingly, dispel some myths about smart contracts. On a virtual machine, which can be not only in Ethereum, but also in similar platforms, you can perform truly arbitrary logical operations, that is, write code and it will be executed there, you can additionally allocate memory. However, the fee is paid separately for each operation and for each additional unit of memory allocated.
Next, the virtual machine can read data from the blockchain database in order to use this data as a trigger to execute one or another smart contract logic. The virtual machine can create and send transactions, it can create new contracts and call methods of other smart contracts that are already published on the network: existing, accessible, etc.
The most common myth is that Ethereum smart contracts can use information from any Internet resources under your own conditions. The truth is that a virtual machine cannot send a network request to some external information resource on the Internet, that is, it is impossible to write a smart contract that will distribute value between users depending on, say, what the weather is like outside, or who won some championship, or based on what other incident happened in the outside world, because information about these incidents is simply not in the database of the platform itself. That is, there is nothing on the blockchain about this. If it does not appear there, then the virtual machine cannot use this data as triggers.
Disadvantages of Ethereum
Let's list the main ones. The first disadvantage is that there are some difficulties in designing, developing and testing smart contracts in Ethereum (Ethereum uses the Solidity language to write smart contracts). Indeed, practice shows that a very large percentage of all errors belong to the human factor. This is actually true for already written Ethereum smart contracts that have average or higher complexity. If for simple smart contracts the probability of an error is small, then in complex smart contracts there are very often errors that lead to the theft of funds, their freezing, destruction of smart contracts in an unexpected way, etc. Many such cases are already known.The second disadvantage is that the virtual machine itself is not perfect, since it is also written by people. It can execute arbitrary commands, and therein lies the vulnerability: a number of commands can be configured in a certain way that will lead to consequences that were unforeseen in advance. This is a very complex area, but there are already several studies that show that these vulnerabilities exist in the current version of the Ethereum network and they can lead to the failure of many smart contracts.
Another big difficulty, it can be considered a disadvantage. It lies in the fact that you can practically or technically come to the conclusion that if you compile the bytecode of a contract that will be executed on a virtual machine, you can determine some specific order of operations. When performed together, these operations will greatly load the virtual machine and slow it down disproportionately to the fee that was paid for performing these operations.
In the past, there was already a period in the development of Ethereum, when many guys who understood in detail the operation of a virtual machine found such vulnerabilities. In fact, transactions paid a very small fee, but practically slowed down the entire network. These problems are very difficult to solve, since it is necessary, firstly, to determine them, secondly, to adjust the price for performing these operations and, thirdly, to carry out a hard fork, which means updating all network nodes to a new version of the software, and then simultaneous activation of these changes.
As for Ethereum, a lot of research has been carried out, a lot of practical experience has been gained: both positive and negative, but nevertheless there remain difficulties and vulnerabilities that still have to be dealt with somehow.
So, the thematic part of the article is completed, let’s move on to questions that arise quite often.
FAQ
— If all parties to an existing smart contract want to change the terms, can they cancel this smart contract using multisig, and then create a new smart contract with updated terms of its execution?The answer here will be twofold. Why? Because on the one hand, a smart contract is defined once and it no longer implies any changes, and on the other hand, it can have pre-written logic that provides for a complete or partial change of some conditions. That is, if you want to change something in your smart contract, then you must prescribe the conditions under which you can update these conditions. Accordingly, only in such a prudent manner can the renewal of the contract be organized. But here, too, you can run into trouble: make some mistake and get a corresponding vulnerability. Therefore, such things need to be very detailed and carefully designed and tested.
— What if the mediator enters into an agreement with one of the participating parties: escrow or smart contract? Is a mediator required in a smart contract?
A mediator is not required in a smart contract. It may not exist. If, in the case of escrow, the mediator enters into a conspiracy with one of the parties, then yes, this scheme then sharply loses all its value. Therefore, mediators are selected in such a way that they are trusted by all parties involved in this process at the same time. Accordingly, you simply will not transfer coins to a multisignature address with a mediator that you do not trust.
— Is it possible with one Ethereum transaction to transfer many different tokens from your address to different target addresses, for example, exchange addresses where these tokens are traded?
This is a good question and it concerns the Ethereum transaction model and how it differs from the Bitcoin model. And the difference is radical. If in the Ethereum transaction model you simply transfer coins, then they are only transferred from one address to another, no change, just the specific amount you specified. In other words, this is not a model of unspent outputs (UTXO), but a model of accounts and corresponding balances. It is theoretically possible to send several different tokens in one transaction at once if you write a cunning smart contract, but you will still have to make many transactions, create a contract, then transfer tokens and coins to it, and then call the appropriate method. This requires effort and time, so in practice it doesn’t work like that and all payments in Ethereum are made in separate transactions.
— One of the myths about the Ethereum platform is that it is impossible to describe conditions that will depend on data from an external Internet resource, so what to do then?
The solution is that the smart contract itself can provide one or more so-called trusted oracles, which collect data about the state of things in the outside world and transmit it to the smart contracts through special methods. The contract itself considers the data that it received from trusted parties to be true. For greater reliability, simply choose a large group of oracles and minimize the risk of their collusion. The contract itself may not take into account data from oracles that contradict the majority.
One of the lectures in the online course on Blockchain, “Introduction to Smart Contracts,” is devoted to this topic.
