In this article, we will look at what smart contracts are, what they are like, get acquainted with different platforms of smart contracts, their features, and also discuss how they work and what advantages they can carry. This material will be very useful for readers who are not familiar enough with the topic of smart contracts, but want to come closer to understanding it.
Regular contract vs. smart contract
Before we delve into the details, let's look at the differences between a regular contract, which is set on paper, and a smart contract, which is presented in digital form.
How did this work before the advent of smart contracts? Imagine a group of people who wish to establish certain rules and conditions for the distribution of values, as well as a certain mechanism to guarantee that this distribution is carried out according to the given rules and conditions. Then they gathered together, made up a paper on which they recorded their identification data, the conditions, the values involved, set a date and signed. This contract was also assured by a trusted party, such as a notary. Further, these people dispersed in different directions with their paper copy of such a contract and began to perform some actions that could not correspond to the contract itself, that is, they did one thing, and on paper it was certified that they should do something completely different. And how to get out of this situation? In fact, it is necessary for someone from the group to take this paper, take some evidence, bring it to court and seek compliance between the contract and the actual actions. Quite often, it is difficult to achieve fair fulfillment of this contract, which leads to unpleasant consequences.
What can be said about smart contracts? They combine in themselves the possibility of writing the terms of the contract, and the mechanism of their strict implementation. If the conditions have been set and the corresponding transaction or request has been signed, after accepting this request or transaction, it is no longer possible to change the conditions or affect their execution.
There is one validator or a whole network, as well as a database that stores all the smart contracts that were submitted for execution in a strict chronological sequence. It is also important that this database must contain all the conditions-triggers for the execution of a smart contract. In addition, it must take into account the very value, the distribution of which is described in the contract. If it concerns some digital currency, then this database should take it into account.
In other words, validators of smart contracts must have access to all the data with which the smart contract operates. For example, one database should be used to simultaneously account for digital currencies, user balances, user transactions, and time stamps. Then, in a smart contract, the condition may be the user's balance in a certain currency, the onset of some time, or the fact that a certain transaction is being performed, but no more.
Smart contract definition
In general, the terminology itself was invented by the researcher Nick Szabo and was first used in 1994, and was documented in 1997 in an article that describes the very idea of smart contracts.
Smart contracts imply that there is some automation of the distribution of value, which can depend only on those conditions that are predetermined in advance. In its simplest form, it looks like a contract with strictly defined conditions, 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, for such contracts easier to audit. This is a consequence of some features of the design of such a system, but most often we understand the smart contract as a decentralized environment and the presence of functions that allow anyone who wants to analyze the database and conduct a full audit of the implementation of contracts. In this way, protection against retroactive data changes is guaranteed, which will entail changes in the performance of the contract itself. Digitizing most processes when creating and launching a smart contract often simplifies the technology and the cost of their implementation.
Simple example - Escrow service
Let's look at a very simple example. It will help to get closer to understanding the functionality of smart contracts, as well as to better understand when they should be used.
It can also be implemented using Bitcoin, although now Bitcoin can hardly be called a full-fledged platform for smart contracts. So, we have some buyer and have an online store. The buyer wants to buy a monitor in this store. In the simplest case, the buyer draws up and sends the payment, and the online store accepts it, confirms, and then sends 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 the 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 to be serviced and will not send the goods to the buyer. Therefore, the buyer asks a question (respectively, and 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, you can give the buyer and the seller the opportunity to choose a mediator independently of each other. There are many people who are involved in solving controversial issues. And our participants can choose from the general list of mediators the one they will be trusted at the same time. Together they create a multisignature address of 2 out of 3, where there are three keys and two signatures are needed with any two keys in order to spend coins from this address. One key will belong to the buyer, the second - to the online store, and the third - to the mediator. And at such a multisignature address, the buyer will send the amount necessary to pay for the monitor. Now, when the seller sees that the money has been blocked for some time at the multisignature address, which depends on him, he can safely send the monitor by mail.
Further, the buyer receives the parcel, inspects the goods and decides on the final purchase. He can fully agree with the service provided and sign the transaction with his key, where he transfers the coins from the multisignature address to the seller, or he may be dissatisfied with something. In the second case, he contacts the mediator to create an alternative transaction, which would otherwise distribute these coins.
For example, the monitor came a little scratched and did not include a cable for connecting to a computer, although it was written on the website of the online store 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 check from the post office, takes a photo of scratches on the monitor and shows that the seal was torn off and the cable was pulled out. The online store in turn collects its evidence and transmits it to the mediator.
The mediator is interested in simultaneously satisfying the buyer's indignation and the interests of the online store (it will be clear later why). It constitutes a transaction in which coins with multisignature addresses will be spent in some proportion between the buyer, the online store and the mediator, as he takes a part as a reward for his work. Suppose that 90% of the total amount goes to the seller, 5% to the mediator and 5% compensation to the buyer. This transaction is signed by the mediator with its key, but it cannot be applied yet, because it requires two signatures, but only one is worth it. He sends such a transaction to both the buyer and the seller. If at least one of them is satisfied with this variant of the redistribution of coins, then the transaction will be pre-signed and distributed to the network. For its validation, it is enough that one of the parties to the transaction agrees with the variant of the mediator.
At the same time, it is important to initially select a mediator so that both participants trust him. In this case, he will act regardless of the interests of one or the other and objectively assess the situation. If the mediator does not provide such a distribution of coins that will satisfy at least one participant, then, having agreed together, both the buyer and the online store can forward the coins to the new multisignature address by putting their two signatures. A new multisignature address will be compiled with another mediator, who may be more competent in the question and will provide a better option.
Example with a hostel and a fridge
Let's look at a more complex example that displays the capabilities of a smart contract more clearly.
Suppose there are three guys who have recently settled in one room in a dormitory. The three of them are interested in buying a refrigerator in their room, which they will share. One of them volunteered to collect the necessary amount for the purchase of a refrigerator and to negotiate with the seller. However, they relatively recently met each other and there is not enough trust between them. Obviously, two of them take risks, giving money to the third. In addition, they need to reach agreement on the choice of the seller.
They can use the escrow service, that is, choose a mediator who will control the execution of the transaction and resolve contentious issues, if any. Then, having agreed, they constitute a smart contract and prescribe in it certain conditions.
The first condition is that before a certain time, for example, within one week, three payments from certain addresses for a certain amount must be received on the corresponding account of the smart contract. If this does not happen, the smart contract terminates and returns the coins to all participants. If the condition is satisfied, then the values of the identifiers of the seller and the mediator are set, and the condition is checked that all participants agree with the choice of the seller and the mediator. When all the conditions are met, then the funds will be transferred to the specified addresses. Such an approach can protect participants from fraud from any side and generally eliminates the need to trust.
We see in this example the principle itself that such an opportunity to set the parameters step by step to fulfill each condition allows you to create systems of any complexity and depths of nested levels. In addition, you can first define the first condition in the smart contract, and only after its fulfillment you can set the parameters for the next condition. In other words, the condition is formally prescribed, and the parameters for it can be set already during its operation.
Smart Contract Classification
For classification, you can specify different groups of criteria. However, at the moment of technological development, four of them are relevant.
Smart contracts can be distinguished by the execution environment, which can be either centralized or decentralized. In the case of decentralization, we have much greater independence and resiliency when executing smart contracts.
They can also be distinguished by the process of setting and fulfilling the conditions: they can be arbitrarily programmed, limited or preset, that is, strictly typed. When there are only 4 defined smart contracts on the smart contract platform, the parameters for them can be set arbitrarily. Accordingly, it is much easier to set them: we select a contract from the list and pass the parameters.
According to the initiation method, there are automated smart contracts, that is, upon the occurrence of certain conditions, they self-fulfill, and there are such contracts in which the conditions are set, but the platform does not automatically check their fulfillment, for this they need to be separately initiated.
In addition, smart contracts vary in their level of privacy. They can be either completely open, or partially, or completely confidential. The latter means that third-party observers do not see the conditions of smart contracts. However, the topic of privacy is very extensive and it is better to consider it separately from the current article.
Below we dwell on the first three criteria in more detail in order to bring more clarity to the understanding of the current topic.
Smart Contracts for Runtime
According to the runtime environment, there are centralized and decentralized smart contract platforms. In the case of centralized digital contracts, one service is used, where there is only one validator and there can be a backup and recovery service that is also centrally managed. There is one database that stores all the necessary information to set the conditions of a smart contract and the distribution of that value, which is taken into account in this very database of the service. Such a centralized service has a customer who sets up certain requests and uses such contracts. Due to the fact that the platform is centralized, authentication mechanisms may be less reliable than in cryptocurrencies.
As an example, you can take mobile providers (different mobile operators). For example, a certain operator on its servers in a centralized manner records traffic that can be transmitted in different formats, for example: in the form of voice calls, SMS transmissions, mobile Internet traffic, and according to different standards, and also keeps track of funds on user balances. Accordingly, the mobile service provider may draw up contracts for the accounting of the services provided and their payment with different conditions. In this case, conditions like “send an SMS with such a code to such and such a number will be easily set and you will receive such conditions of traffic distribution”.
You can give another example: traditional banks with enhanced Internet banking functionality and such very simple contracts as regular payments, automatic conversion of incoming payments, automatic deduction of interest on a specified account, etc.
If we are talking about smart contracts with a decentralized runtime environment, then we have a group of validators. In the ideal case, anyone can become a validator. Due to the database synchronization protocol and the achievement of consensus, we have some common database, which will now store all transactions with strictly described contracts, and not some conditional requests, the formats of which often change, but there is no open specification. Here transactions will contain instructions for executing a contract in accordance with a strict specification. This specification is open and, therefore, the users of the platform themselves can audit and validate smart contracts. Here we see that decentralized platforms are superior to those centralized in independence and resiliency, but their design and maintenance is much more complicated.
Smart contracts on how to set and fulfill conditions
Now let's take a closer look at how smart contracts may differ in the way they are set and fulfill conditions. Here we pay attention to the smart contracts that are programmed arbitrarily and Turing complete. A Turing-complete smart contract allows you to set almost any algorithms as conditions for the fulfillment of a contract: prescribe cycles, some functions for calculating probabilities, and so on - up to your own electronic signature algorithms. In this case, really arbitrary writing of logic is meant.
There are also arbitrary smart contracts, but not Turing complete. This could include Bitcoin and Lightcoin with its own script. It means that you can use only certain operations in an arbitrary order, but you can no longer write loops and your own algorithms.
In addition, there are smart contract platforms that implement pre-installed smart contracts. These include Bitshares and Steemit. Bitshares has a number of smart contracts for trading, managing accounts, managing the platform itself and its parameters. Steemit is a similar platform, but it is no longer focused on the production of tokens and commerce, like Bitshares, but on blogging, i.e. it stores and processes content in a decentralized way.
The arbitrary full Turing contracts include the Ethereum platform and RootStock, which is still under development. Therefore, we will further dwell on the Ethereum smart contract platform in a bit more detail.
Smart contracts by way of initiation
According to the initiation method, smart contracts can also be divided into at least two groups: automated and manual (not automated). For automated, it is characteristic that, for all known parameters and conditions, the smart contract is fully executed automatically, that is, it does not require sending any additional transactions and spending additional commission on each subsequent execution. The platform itself has all the data in order to calculate how the smart contract will end. The logic there is not arbitrary, but predetermined and everything is predictable. That is, you can estimate in advance the complexity of the implementation of a smart contract, use some kind of constant commission for it and all the processes for its implementation go through more efficiently.
For smart contracts that are programmed in an arbitrary way, execution is not automated. To initiate such a smart contract, virtually at every step you need to create a new transaction that will call the next stage of execution or the next method of smart contract, pay the appropriate commission and wait for confirmation of the transaction. Execution can be completed successfully or not, because the smart contract code is arbitrary and there can be some unpredictable moments, such as an eternal cycle, a lack of some parameters and arguments, unprocessed exceptional moments, etc.
Ethereum accounts
Ethereum Account Types
Consider what accounts 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. We will understand how they differ.
The user account is managed only by the private key of the electronic signature. The account owner generates his / her key pair for electronic signature using the ECDSA (Elliptic Curve Digital Signature Algorithm) algorithm. Only the transactions signed by this key can change the status of this account.
For a smart contract account there is a separate logic. It can only be controlled using a predefined program code that fully determines the behavior of a smart contract: how it will dispose of its coins under certain circumstances, at the initiative of which user and under what additional conditions these coins will be distributed. If some things are not provided by the developers in the program code, problems may arise. For example, a smart contract may receive some specific state in which it does not accept the 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 an exit from this state.
How accounts are created in Ethereum
In the case of a user account, the owner independently generates a pair of keys for ECDSA. It is important to note that Ethereum uses the exact same algorithm for the electronic signature and the exact same elliptical curve as Bitcoin, but the address is calculated in a slightly different way. There is no longer a double hash result, as in Bitcoin, but a one-time hash is provided by the Keccak function on a length of 256 bits. From the obtained value, the low-order bits are cut off, namely, the 160 low-order bits of the output hash value. As a result, we get the address in Ethereum. In fact, it takes 20 bytes.
Note that the account identifier in Ethereum is encoded in hex without using the checksum, unlike Bitcoin and many other systems, where the address is encoded into the base of 58 with the addition of the checksum. This means that you need to be careful 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 the user account at the level of the common database is created at the moment when he accepts the first incoming payment.
With regard to creating a smart contract account, a completely different approach is taken. Initially, one of the users writes the source code of the smart contract, after which the code is passed through the platform-specific compiler for Ethereum, receiving the bytecode for its own Ethereum virtual machine. The resulting bytecode is placed in a special field of the transaction. She is certified on behalf of the initiator account. Further, this transaction is distributed over the network and places the smart contract code. Commission for the transaction and, accordingly, for the implementation of the contract is removed from the account balance of the initiator.
Each smart contract must contain 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, and so on.
Ethereum transaction structure
To make it clearer, we will begin to consider the structure of the Ethereum transaction and the sample code of the smart contract.
The Ethereum transaction consists of several fields. The first of these nonce is a certain sequence number of the transaction relative to the account itself, which distributes it and is its author. This is necessary in order to distinguish the duplicates of transactions, that is, to exclude the case when the same transaction is accepted twice. Through the use of an identifier, each transaction has a unique hash value.
Next comes a field like
gas price . Here you can see the price at which the base currency of Ethereum is converted into gas, which pays for the execution of a smart contract and the allocation of a virtual machine resource. What does it mean?
In Bitcoin, commissions are paid directly by the base currency - by Bitcoin itself. This is possible thanks to a simple mechanism for calculating them: we pay strictly for the amount of data that is contained in the transaction. In Ethereum, the situation is more complicated, because it is very difficult to build on the volume of transaction data. Here, the transaction may still contain program code that will run 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 to determine the constant value 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 transaction feature in Ethereum: the byte code that it contains for execution in a virtual machine will be executed until it completes with some result (success-failure) or until a certain number of coins, selected to pay the commission. In order to avoid a situation where all the coins were spent on a commission from the sender’s account in the event of an error (for example, a perpetual cycle started in a virtual machine), there is the following field -
start gas (often called gas limit) - it defines The maximum amount of coins that the sender is willing to spend on performing a specific transaction.
The next field is called the
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. After it follows the
value field, where the amount of coins that go to the destination address fits.
Next is an interesting field called
data , where the whole structure fits. This is not a separate field, but an entire structure in which the code for the virtual machine is defined. You can put arbitrary data here - for this there are separate rules.
And the last field is called
signature . At the same time, it 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 get the ID of the sender account of this transaction, that is, uniquely identify the sender account in the system itself. According to the structure of the transaction, we found out.
Sample Solidity Smart Contract Code
Let's now take a closer look at the simplest smart contract by example.
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); } }
The 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 sheet, that is, when confirming a transaction and placing such a smart contract, a new account is created that can contain coins on its balance sheet; he remembers the users and the distribution of coins between them; It has several methods of managing balances, that is, there is the possibility of replenishing, withdrawing and checking the user's balance.
Let's go through each line of source code. There are constant fields in this contract. One of them, with the address type, is called the owner. Here the contract remembers the address of the user who created this smart contract. Further, there is a dynamic structure that preserves correspondences between user addresses and balances.
This is followed by the Bank method - it is called the same as the contract. Accordingly, this is his constructor. This is where 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 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 places this code. He will be the owner of a smart contract.
The deposit method allows a transaction to transfer a certain amount of coins to a contract account. In this case, a smart contract, receiving these coins, keeps them on its balance, but records in the structure of balances exactly who 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. Here there is a check if there are enough coins on the balance of the user who calls this method to send them. If there are enough of them, then the smart contract itself returns the number of coins to the caller.
Next is the method of checking the current balance of the user. Whoever calls this method will be used to obtain this balance in a smart contract. It should be noted that the modifier of this method is view. This means that the method itself does not change the variables of its class and it actually is only a reading method. A separate transaction is not created to call this method, the commission is not paid, and all calculations are performed locally, after which the user receives the result.
The kill method is needed in order to destroy the status of a smart contract. And then an additional check is written whether the caller of this method is the owner of this contract. If it is, 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 owner of the contract.
How does the full Ethereum network node work?
Consider schematically how these smart contracts are executed on the Ethereum platform and how the full network node works.
A complete Ethereum network node 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 there is an exchange of blocks, transactions, and information about other nodes. This is a traditional component for all decentralized cryptocurrencies.
Further, we have a blockchain data storage module, processing, selecting a priority branch, adding blocks, detaching blocks, checking these blocks, etc.
The third module is called EVM (Ethereum virtual machine) - this is the virtual machine that receives the byte code from the Ethereum transaction. This module accepts the current state of a particular account and makes changes to its state based on the received byte-code. The version of the virtual machine on each of the network nodes must be the same. Calculations occur on each of the Ethereum nodes are exactly the same, but they occur in an asynchronous order: someone checks and accepts this transaction earlier, that is, executes all the code contained in it, and someone later. Accordingly, when creating a transaction, it is distributed to the network, the nodes accept it and at the time of verification, just like Bitcoin Script is executed in Bitcoin, the virtual machine byte-code 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 already relevant. There is a database that stores the status of each account for each node on the network. Due to the fact that all the calculations are the same and the state of the blockchain is the same, then the database containing the status of all accounts will also be the same for each node.
Myths and limitations of smart contracts
As for the limitations 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 consider the limitations that are imposed on the virtual machine, and, accordingly, we will dispel some myths about smart contracts. On a virtual machine, which can be not only in Ethereum, but also on such 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 commission is charged separately for each operation and for each additional unit of memory allocated.
Further, the virtual machine can read data from the blockchain database in order to use this data as a trigger for the execution of a particular smart contract logic. A 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: there are available and so on.
The most common myth is that Ethereum smart contracts can use information from any Internet resources in their terms. The truth is that the virtual machine cannot send a network request to some external information resource on the Internet, that is, you cannot write a smart contract that will distribute the value between users depending on what the weather is like on the street or who won in some championship, or on the basis of what else 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 about this in the blockchain. 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 drawback is that there are some difficulties in designing, developing and testing smart contracts in Ethereum (Ethereum uses Solidity to write smart contracts). Indeed, practice shows that a very large percentage of all errors belong to the human factor. This is actually relevant for already-written Ethereum smart contracts, which have average or higher difficulty. If for simple smart contracts the error probability is small, then in complex smart contracts there are very often errors that lead to the theft of funds, freezing them, destroying smart contracts in an unexpected way, etc. Many such cases are already known.
The second drawback is that the virtual machine itself is not perfect, as it is also written by people. It can execute arbitrary commands and this is where the vulnerability lies: in a certain way, you can configure a series of commands that will lead to unforeseen consequences in advance. This is a very difficult 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 it is possible to come to a practical or technical point that if you compile the byte-code of a contract that will be executed on a virtual machine, you can determine some specific order of operations. When performed in the aggregate, these operations will very heavily load the virtual machine and slow it down disproportionately to the commission that was paid for performing these operations.
In the past, there was already such a period of development of Ethereum, when many guys who understood in detail the work of the virtual machine, found such vulnerabilities. In fact, transactions paid a very small commission, but practically slowed down the work of the entire network. These problems are very difficult to solve, because they need to, first, determine, secondly, adjust the price for these operations and, thirdly, conduct hardfork, which means updating all network nodes to the new software version, and then simultaneous activation of these changes.
As for Ethereum, a lot of research has been done, a lot of practical experience has been obtained: both positive and negative, but nevertheless there remain challenges and vulnerabilities that still need to be tackled.
So, the thematic part of the article is completed, we turn to the questions that arise quite often.
Frequently asked Questions
- If all parties to a valid smart contract want to change the conditions, can they cancel this smart contract using a multi-signature, and then create a new smart contract with updated conditions for its implementation?Here the answer will be twofold. Why? Because on the one hand, a smart contract is set once and it no longer implies any changes, but on the other hand, it can have a pre-written logic that provides for the 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 way can you update the contract. But here, too, you can run into trouble: make some mistake and get the corresponding vulnerability. Therefore, such things need to be very detailed and carefully designed and tested.
- And if the mediator enters into an agreement with one of the parties involved: escrow or a smart contract? Is the mediator required in a smart contract?The mediator is not required in the smart contract. It may not be. If in the case of escrow the mediator enters into collusion with one of the parties, then yes, this scheme then sharply loses all its value. Therefore, mediators are chosen in such a way that they are simultaneously trusted by all parties involved in this process. Accordingly, you simply will not transfer the coins to the multisignature address with the mediator you do not trust.
- Is it possible to transfer a lot of different tokens from one address to different target addresses, for example stock addresses, where these tokens are traded?This is a good question and it concerns the Ethereum transaction model and its difference from the Bitcoin model. And the difference is drastic. If in the Ethereum transaction model you simply transfer coins, they are transferred only from one address to another, without surrender, just a specific amount that you have indicated. In other words, this is not a model of unspent exits (UTXO), but a model of accounts and corresponding balances. It is theoretically possible to send several different tokens with one transaction at once, if you write a clever smart contract, but you still have to do a lot of transactions, create a contract, then transfer tokens and coins to it, and then call the appropriate method. This requires effort and time, respectively, in practice it does not work like this and all payments in Ethereum are made by separate transactions.
- One of the myths about the Ethereum platform is that it is impossible to describe such conditions that will depend on the data of an external Internet resource, what then?The solution is that the smart contract itself may provide for one or more so-called trusted oracles, which collect data on the state of things in the external world and transfer them to smart contracts through special methods. The contract itself considers true the data that it received from trusted parties. 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, which contradict the majority.
This topic is devoted to one of the lectures of the online course on Blockchain - “
Introduction to smart contracts ”.