In this article, we will look at what smart contracts are, what they are, 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 familiar enough with the topic of smart contracts, but want to get closer to understanding it.
Regular contract vs. smart contract
Before we get into the details, let's use an example to understand the difference between a regular contract that is written on paper and a smart contract that is digital.
How did it work before the advent of smart contracts? Imagine a group of people who want to establish some rules and conditions for the distribution of values, as well as a certain mechanism to ensure that this distribution is carried out according to the given rules and conditions. Then they got together, drew up a piece of paper on which they wrote down their identity, conditions, values ββinvolved, dated and signed. This contract was also certified 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 might not correspond to the contract itself, that is, they did one thing, but on paper it was assured 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 a fair performance of this contract, which leads to unpleasant consequences.
What can be said about smart contracts? They combine both the ability to write 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 after accepting this request or transaction, it is no longer possible to change the conditions or influence their implementation.
There is one validator or a whole network, as well as a database that stores all smart contracts that came to be executed in strict chronological order. It is also important that this database must contain all trigger conditions 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, smart contract validators must have access to all the data that the smart contract operates on. For example, one database should be used to account simultaneously 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 onset of some time, or the fact of a certain transaction, but nothing more.
Definition of a smart contract
In general, the terminology itself was coined by researcher Nick Szabo and first applied 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 the distribution of value is performed, which can only depend on those conditions that are pre-set. At its simplest, this 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, such contracts are easier to audit. This is a consequence of some design features of such a system, but most often we understand a smart contract as 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. In this way, protection against retroactive changes to the data, which will entail changes in the execution of the contract itself, is guaranteed. Digitization of most processes during the creation and launch of a smart contract often simplifies the technology and the cost of their implementation.
A simple example - Escrow service
Let's look at a very simple example. It will help you get closer to understanding the functionality of smart contracts, as well as better understand when they should be used.
It can also be implemented using Bitcoin, although at present Bitcoin can hardly be called a full-fledged platform for smart contracts. So, we have some buyer and there is an online store. A customer wants to buy a monitor from this store. In the simplest case, the buyer draws up and sends a payment, and the online store accepts it, confirms it, 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 service and not send the goods to the buyer. Therefore, the buyer asks (respectively, 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, the buyer and seller can be given the opportunity to independently choose a mediator. There are many people who are engaged in solving controversial issues. And our participants can choose from the general list of mediators the one they will trust at the same time. Together they create a multisignature address 2 of 3 where there are three keys and two signatures with any two keys are needed 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 the buyer will send the amount necessary to pay for the monitor to such a multisignature address. Now, when the seller sees that the money is blocked for some time on 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 makes a decision 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 can be dissatisfied with something. In the second case, he contacts the mediator to compile an alternative transaction that will distribute these coins in a different way.
Let's say the monitor arrived a little scratched and the cable for connecting to the computer was not included in the kit, 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 receipt from the mail, 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 passes it to the mediator.
The mediator is interested in satisfying both the indignation of the buyer and the interests of the online store at the same time (it will be clear why later). He makes up a transaction in which coins with a multisignature address will be spent in some proportion between the buyer, the online store and the mediator, since he takes a part as a reward for his work. Let's say 90% of the total amount goes to the seller, 5% to the mediator and 5% of the compensation to the buyer. The mediator signs this transaction with his key, but it cannot be applied yet, because this requires two signatures, and only one costs. He sends such a transaction to both the buyer and the seller. If at least one of them is satisfied with this option of redistributing coins, then the transaction will be pre-signed and distributed to the network. For its validation, it is enough that one of the participants in the transaction agrees with the mediator's option.
At the same time, 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 such an option for the 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 a new multisignature address by putting their two signatures. A new multisignature address will be drawn up with another mediator, who may be more competent in the matter and provide a better option.
Example with a hostel 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, which they will share. One of them volunteered to collect the necessary amount to buy a refrigerator and negotiate with the seller. However, they relatively recently met each other and there is no sufficient trust between them. It is obvious that two of them take risks by 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 settle disputes, if any. Then, having agreed, they draw up a smart contract and prescribe certain conditions in it.
The first condition is that before a certain time, let's 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 its execution and returns the coins to all participants. If the condition is met, 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 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 for trust.
In this example, we see the very principle that such an opportunity to set parameters step by step for the fulfillment of 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 it is fulfilled, 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.
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 arbitrarily programmable, limited, or preset, that is, strongly 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 parameters.
According to the method of initiation, there are automated smart contracts, that is, when certain conditions occur, they are self-executing, and there are contracts in which the conditions are set, but the platform does not automatically check their execution, for this they need to be initiated separately.
In addition, smart contracts differ in terms of privacy. They can be either completely open, or 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 is best dealt with separately from the current article.
Below we will dwell on the first three criteria in more detail in order to bring more clarity to the understanding of the current topic.
Smart contracts by runtime
According to the execution environment, centralized and decentralized smart contract platforms are distinguished. 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 restore service that is also centrally managed. There is one database that stores all the necessary information to set the conditions for a smart contract and distribute the value that is taken into account in this very database of the service. Such a centralized service has a client who, by certain requests, sets the conditions and uses such contracts. Due to the fact that the platform is centralized, authentication mechanisms can be less reliable than in cryptocurrencies.
As an example, you can take mobile communication providers (different mobile operators). Suppose a certain operator keeps records of traffic on its servers in a centralized manner, 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 communication provider may draw up contracts for accounting for the services provided and their payment with different conditions. In this case, conditions are easily set 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 advanced Internet banking functionality and very simple contracts such 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 execution environment, 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 requests, the formats of which often change, and there is no open specification. Here, the transactions will contain instructions for executing 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 is much more difficult.
Smart contracts by way 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 pay attention to smart contracts that are arbitrarily programmable and Turing complete. A Turing-complete smart contract allows you to set almost any algorithms as conditions for the execution of the contract: prescribe cycles, some functions for calculating probabilities, and the like - up to your own digital signature algorithms. In this case, we mean really 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 an arbitrary order, but you can no longer write cycles and your own algorithms.
In addition, there are smart contract platforms that implement predefined smart contracts. These include Bitshares and Steemit. Bitshares has a range 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 issuing tokens and trading, like Bitshares, but on blogging, i.e. it stores and processes content in a decentralized way.
Arbitrary Turing-complete contracts include the Ethereum platform and RootStock, which is still under development. Therefore, further we will dwell on the Ethereum smart contract platform in a little more detail.
Smart contracts by initiation method
According to the method of initiation, smart contracts can also be divided into at least two groups: automated and manual (not automated). For automated ones, it is typical that with all the known parameters and the conditions that have come, the smart contract is fully executed automatically, that is, it does not require sending any additional transactions and spending an additional commission on each next execution. The platform itself has all the data to calculate how the smart contract will end. The logic there is not arbitrary, but predetermined and all this is predictable. That is, it is possible to estimate the complexity of the execution of a smart contract in advance, use some kind of constant commission for it, and all processes for its implementation are carried out in a more efficient way.
For smart contracts that are arbitrarily programmed, execution is not automated. To initiate such a smart contract, in fact, at each step, you need to create a new transaction that will call the next execution stage or the next smart contract method, pay the appropriate fee and wait for the transaction to be confirmed. The execution may or may not succeed, because the smart contract code is arbitrary and some unpredictable moments may appear, such as an eternal loop, lack of some parameters and arguments, unhandled exceptional moments, etc.
Accounts in Ethereum
Types of Ethereum Accounts
Consider what accounts can be on the Ethereum platform. There are only two types of accounts and there are no other options. The first type is called a user account, the second is a contract account. Let's see how they differ.
The user account is managed only by the personal key of the electronic signature. The account owner generates his/her electronic signature key pair using the ECDSA (Elliptic Curve Digital Signature Algorithm) algorithm. Only transactions signed by 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 a predefined program code that completely determines the behavior of the 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 points 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 Ethereum Accounts Are Created
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 signature as Bitcoin, but the address is calculated in a slightly different way. Here, the result of double hashing is no longer applied, as in Bitcoin, but a single hashing by the Keccak function is provided for a length of 256 bits. The least significant bits are cut off from the received value, namely the 160 least significant bits of the output value of the hash function. As a result, we get an address in Ethereum. In fact, it takes 20 bytes.
Note that the Ethereum account ID is encoded in hex without a checksum, unlike Bitcoin and many other systems, where the address is encoded in base 58 with the addition of a checksum. This means that you need to be careful when working with Ethereum account identifiers: even one mistake in the identifier is guaranteed to lead to the loss of coins.
There is an important feature and it lies in the fact that a user account at the level of the general 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 a compiler special for the Ethereum platform, obtaining the bytecode for its own Ethereum virtual machine. The resulting bytecode is placed in a special transaction field. It is certified on behalf of the initiator's account. Next, this transaction propagates over the network and places the smart contract code. The commission for the transaction and, accordingly, for the execution of the contract is removed from the balance of the initiator's account.
Each smart contract must contain its own constructor (of this contract). It can be empty, or it can have content. After the constructor is executed, a smart contract account ID is created, using which you can send coins, call certain smart contract methods, etc.
Ethereum transaction structure
To make it clearer, we will start looking at the structure of an Ethereum transaction and an example smart contract code.
An Ethereum transaction consists of several fields. The first of them is a nonce - this is some serial number of the transaction relative to the account itself, which distributes it and is its author. This is necessary in order to distinguish between duplicate 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.
This is followed by a field like gas prices. This is the price at which the Ethereum base currency 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, 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 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 can still contain program code that will run on the virtual machine, and each operation of the virtual machine can have 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-failure) or until a certain number of coins allocated to pay a commission. It is in order to avoid the situation when all the coins were spent on a commission from the sender's account in the event of some error (for example, some kind of eternal cycle started in a virtual machine), there is the following field - start gas (often called gas limit) - it determines the maximum amount of coins that the sender is willing to spend to complete a certain 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 a field value, where the amount of coins that are sent to the destination address is entered.
Next is an interesting field called date, 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 put 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 that will be used to verify this signature. From the public key, you can get the identifier of the sender's account of this transaction, that is, uniquely identify the sender's account in the system itself. By the structure of the transaction, we found out the main thing.
Solidity smart contract code example
Let's now take a closer look at the simplest smart contract using an 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);
}
}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 the 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. Next, there is a dynamic structure that stores the correspondence between user addresses and balances.
After that, the Bank method follows - it is named the same 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, which places this code. He will be the owner of the smart contract.
The deposit method allows you to transfer a certain number of coins in a transaction to a contract account. In this case, the smart contract, when receiving these coins, leaves them on its balance, 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. Here is a check if there are enough coins on the balance of the user who calls this method in order to send them. If there are enough of them, then the smart contract itself returns this number of coins to the caller.
Next comes the method to check the user's current balance. Whoever calls this method will be used to get 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 in fact only a read method. A separate transaction is not 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 in order to destroy the state of the smart contract. And here 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 ID 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 of the Ethereum network work?
Let's consider schematically how such smart contracts are executed on the Ethereum platform and how a 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 networking and working 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, choosing a priority branch, adding blocks, unhooking blocks, checking these blocks, etc.
The third module is called EVM (Ethereum virtual machine) - this is the virtual machine that receives the bytecode from Ethereum transactions. This module takes the current state of a specific account and performs changes to its state based on the received bytecode. The version of the virtual machine on each host must be the same. The calculations take place on each of the Ethereum nodes are exactly the same, but they take place in an asynchronous order: someone checks and accepts this transaction earlier, that is, it 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, just like 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 was 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 state of each account for each network node. Due to the fact that all calculations are the same 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 Ethereum-like smart contract platforms, 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.
Further, the virtual machine can read data from the blockchain database in order to use this data as a trigger for executing 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, available, etc.
The most common myth is that Ethereum smart contracts can use information from any Internet resource in their own terms. 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 such a smart contract that will distribute value between users depending on, say, what the weather is like outside, or who won in some championship, or based on what other incident happened in the outside world, because information about these incidents simply is not in the database of the platform itself. That is, there is nothing in 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 drawback 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 belongs to the human factor. This is actually true for already written Ethereum smart contracts, which are of medium 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 theft of funds, to their freezing, to the 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, as it is also written by people. It can execute arbitrary commands, and this is where the vulnerability lies: a number of commands can be configured in a certain way, which will lead to unforeseen consequences 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 define some specific order of operations. When performed in combination, these operations will 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 in the development of Ethereum, when many guys who understood in detail the operation of the virtual machine found such vulnerabilities. In fact, transactions paid a very small commission, but practically slowed down the entire network very much. These problems are very difficult to solve, since, firstly, they must be determined, secondly, the price for performing these operations must be adjusted, and thirdly, a hard fork must be carried out, 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 done, a lot of practical experience has been gained: both positive and negative, but nevertheless there are 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.
F.A.Q.
- If all parties to an existing smart contract want to change the conditions, can they cancel this smart contract using multi-signature, and then create a new smart contract with updated conditions for its execution?
Here the answer is twofold. Why? Because on the one hand, a smart contract is set once and it no longer implies any changes, and on the other hand, it can have predefined logic that provides for a complete or partial change in 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 the renewal of the contract be arranged. 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 colludes with one of the participating parties: escrow or smart contract? Is a mediator required in a smart contract?
The mediator is not required in a smart contract. It may not exist. If, in the case of escrow, the mediator colludes 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 coins to a multisignature address with a mediator that you do not trust.
β Is it possible to transfer many different tokens from your address to different target addresses, for example, exchange addresses where these tokens are traded, with one Ethereum transaction?
This is a good question and it is about the Ethereum transaction model and how it differs from the Bitcoin model. And the difference is cardinal. If in the Ethereum transaction model you just transfer coins, then they are transferred only from one address to another, without change, just a specific amount that 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 at once in one transaction if you write a tricky smart contract, but you 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, respectively, in practice it does not work this way 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 such conditions that will depend on the data of an external Internet resource, what then?
The solution is that the smart contract itself can provide for one or more so-called trusted oracles that collect data about the state of things in the outside world and transmit it to smart contracts through special methods. The contract itself considers the data that it received from trusted parties to be true. For greater reliability, they 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 of the online course on Blockchain is devoted to this topic - β".
Source: habr.com