In this article, we will explore what smart contracts are, the different types, get acquainted with various smart contract platforms, their features, and discuss how they work and the benefits they can offer. This material will be very useful for readers who are not very familiar with the topic of smart contracts but want to gain a better understanding.
Traditional Contract vs. Smart Contract
Before we delve into the details, let's examine the differences between a traditional contract, which is set down on paper, and a smart contract, which is represented digitally.
How did it work before the advent of smart contracts? Imagine a group of people who wish to establish rules and conditions for the distribution of values, while also implementing a certain mechanism to guarantee that this distribution follows the specified rules and conditions. They would gather together, draft a document outlining their identifying information, the conditions, the values involved, set a date, and sign it. This contract would also be validated by a trusted third party, such as a notary. Then, these individuals would go their separate ways with their paper copy of the contract and begin to take actions that might not correspond to the contract itself, meaning they did one thing while the paper stated they should be doing something entirely different. So, how do they resolve this situation? Essentially, one of the participants in the group would need to take that paper, gather some evidence, go to court, and seek to align the contract with their actual actions. Achieving fair enforcement of this contract can often be difficult, leading to unpleasant consequences.
What can be said about smart contracts? They combine the ability to write the terms of a contract with a strict mechanism for enforcing them. If the terms are set and a corresponding transaction or request is signed, then once this request or transaction is accepted, it becomes impossible to change the terms or influence their execution.
There is either a single validator or a whole network, as well as a database that stores all the smart contracts that come in for execution in strict chronological order. It is also important that this database contains all the trigger conditions for executing the smart contract. Furthermore, it must account for the very value whose distribution is described in the contract. If this involves a certain digital currency, then this database must account for it.
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 account for digital currencies, user balances, user transactions, and timestamps simultaneously. Then, a condition in the smart contract could be a user's balance in a certain currency, the occurrence of a specific time, or the fact of executing a certain transaction, but nothing more.
Definition of a smart contract
In fact, the terminology itself was coined by researcher Nick Szabo and was first applied in 1994, while it was documented in 1997 in an article that describes the very idea of smart contracts.
Smart contracts imply that a certain automation of value distribution is carried out, which can depend only on those conditions that are preset. In its simplest form, this looks like a contract with strictly defined conditions that 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 eliminated. Furthermore, auditing such contracts is simpler. This is a consequence of certain design features of such a system, but more often than not, we understand a smart contract to be a decentralized environment with functions that allow anyone interested to analyze the database and conduct a full audit of contract execution. This guarantees protection against retroactive data alterations that would lead to changes in the execution of the contract itself. Digitizing 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 consider a very simple example. It will help to understand the functional capabilities of smart contracts better and navigate when it’s appropriate to use them.
It can also be implemented using Bitcoin, although currently it's difficult to call Bitcoin a fully-fledged platform for smart contracts. So, we have a buyer and an online store. The buyer wants to purchase a monitor from this store. In the simplest case, the buyer makes and sends the payment, and the online store accepts it, confirms it, and then ships the product. However, in this situation, there is a significant trust requirement—the buyer must trust the online store for the full amount 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 may refuse service and not send the product to the buyer. Therefore, the buyer wonders (and consequently, the online store wonders as well) what can be applied in this case to minimize such risks and make these transactions more reliable.
In the case of Bitcoin, it is possible to allow the buyer and seller to independently choose a mediator. There are many people who deal with resolving disputes. Our participants can choose from a general list of mediators someone they mutually trust. Together, they create a 2 out of 3 multisignature address, where there are three keys and any two keys are required to sign in order 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. The buyer will send the amount necessary to pay for the monitor to this multisignature address. Now, when the seller sees that the funds are temporarily blocked in the multisignature address, which depends on him, he can confidently send the monitor by mail.
Next, the buyer receives the package, inspects the product, and decides on the final purchase. They may fully agree with the provided service and sign the transaction with their key, transferring coins from the multisignature address to the seller. However, they may also be dissatisfied. In the latter case, they contact the mediator to create an alternative transaction that reallocates these coins differently.
For instance, if the monitor arrives slightly scratched and the cable for connecting to the computer is missing, despite it being stated on the online store's website that the cable should be included, the buyer gathers the necessary evidence to prove to the mediator that they have been deceived in this situation: they take screenshots of the website, photograph the receipt from the post office, capture images of the scratches on the monitor, and show that the seal was broken and the cable was removed. Meanwhile, the online store collects its evidence and submits it to the mediator.
The mediator is interested in satisfying both the buyer's outrage and the interests of the online store (it will become clear later why). They draft a transaction in which coins from the multisignature address will be allocated in some proportion among the buyer, the online store, and the mediator, as they take a portion as a reward for their work. Suppose 90% of the total amount goes to the seller, 5% to the mediator, and 5% as compensation to the buyer. The mediator signs this transaction with their key, but it cannot yet be executed because it requires two signatures, and only one is present. This transaction is sent to both the buyer and the seller. If at least one of them is satisfied with this redistribution of the coins, the transaction will be co-signed and broadcast to the network. To validate it, it is sufficient for one of the participants in the deal to agree with the mediator's proposal.
It is essential to choose a mediator from the outset whom both participants trust. In this case, they will act independently of either party's interests and assess the situation objectively. If the mediator does not offer a distribution of coins that satisfies at least one participant, both the buyer and the online store can, by mutual agreement, transfer the coins to a new multisignature address, providing their two signatures. The new multisignature address will be set up with a different mediator who may be more competent and offer a better solution.
An example with a dormitory and a refrigerator
Let's consider a more complex example that clearly demonstrates the capabilities of a smart contract.
Suppose there are three guys who recently moved into a dorm room together. They are all interested in purchasing a refrigerator for their room to share. One of them volunteered to gather the necessary funds for the fridge and negotiate with the seller. However, they have only recently met, and there isn't sufficient trust between them. Clearly, two of them are at risk by giving money to the third. Additionally, they need to come to an agreement on choosing a seller.
They can use an escrow service, which means selecting a mediator to oversee the transaction and resolve any disputes that may arise. Then, by agreeing, they draft a smart contract and specify certain conditions in it.
The first condition is that by a certain time, for example within a week, three payments must be made to the respective smart contract account from specific addresses for a specified amount. If this does not happen, the smart contract ceases its execution and returns the coins to all participants. If the condition is met, then the identifiers of the seller and mediator are set, and it is verified that all participants agree on the choice of the seller and mediator. Once all conditions are fulfilled, the funds will be transferred to the specified addresses. This approach can protect participants from fraud from any side and entirely eliminates the need for trust.
We see from this example the principle that the ability to sequentially set parameters for each condition allows for the creation of systems of any complexity and depth of nested levels. Additionally, the first condition can be defined in the smart contract, and only after it is fulfilled, parameters for the next condition can be set. In other words, the condition is formally stated, while the parameters for it can be set during its operation.
Classification of Smart Contracts
For classification, different groups of criteria can be set. However, currently, four of them are relevant given the state of technology.
Smart contracts can be distinguished by the execution environment, which can be either centralized or decentralized. In the case of decentralization, we gain much greater independence and fault tolerance in the execution of smart contracts.
They can also be distinguished by the process of setting and executing conditions: they can be arbitrarily programmable, restricted, or predefined, i.e., strictly typed. When there are only four specific smart contracts on a smart contract platform, the parameters for them can be set arbitrarily. Accordingly, it is much easier to set them: we choose a contract from the list and pass the parameters.
By the method of initiation, there are automated smart contracts, which self-execute upon the occurrence of certain conditions. There are also contracts where the conditions are set, but the platform does not automatically check their fulfillment; they need to be initiated separately.
In addition, smart contracts differ in their level of privacy. They can be fully open, partially open, or completely confidential. The latter means that third-party observers cannot see the conditions of the smart contracts. However, the topic of privacy is vast and deserves separate examination from the current article.
Below, we will focus more on the first three criteria to provide greater clarity on the current topic.
Smart Contracts by Execution Environment
By execution environment, smart contract platforms are categorized into centralized and decentralized. In the case of centralized digital contracts, a single service is used, where there is only one validator, and there may be a central backup and recovery service that is also managed centrally. There is a single database that stores all the necessary information to specify the smart contract's conditions and distribute the value recorded in the service's database. This centralized service has clients who define conditions through specific requests and utilize such contracts. Due to the centralized nature of the platform, authentication mechanisms may be less secure than in cryptocurrencies.
An example can be taken from mobile service providers (various mobile operators). Suppose a certain operator keeps track of traffic in a centralized manner on their servers, which can be transmitted in various formats, such as voice calls, SMS transmissions, mobile internet traffic, and through different standards, while also tracking the funds on user balances. Accordingly, the mobile service provider can create contracts for accounting for provided services and their payment with various conditions. In such cases, conditions such as 'send an SMS with a certain code to a certain number and receive specific traffic distribution conditions' can be easily set.
Another example can be provided: traditional banks with enhanced online banking functionality and simple contracts such as recurring payments, automatic conversion of incoming payments, and automatic interest deductions to a specified account, etc.
When it comes to smart contracts within a decentralized execution environment, we have a group of validators. Ideally, anyone can be a validator. Through the database synchronization protocol and consensus achievement, we have a common database that will now store all transactions with clearly defined contracts, rather than some conditional requests, the formats of which often change with no open specification available. Here, transactions will contain instructions for executing the contract according to strict specifications. This specification is open, and consequently, the users of the platform can audit and validate smart contracts. We see that decentralized platforms outperform centralized ones in terms of independence and fault tolerance, but their design and maintenance are considerably more complex.
Smart contracts differentiated by the method of defining and executing conditions
Now let's explore in more detail how smart contracts can differ based on how conditions are defined and executed. Here, we will focus on smart contracts that are arbitrarily programmed and Turing-complete. A Turing-complete smart contract allows virtually any algorithms to be defined as execution conditions: it can stipulate loops, probability calculation functions, and so on — even its own electronic signature algorithms. In this case, we mean truly arbitrary logic writing.
There are also arbitrary smart contracts that are not Turing-complete. This includes Bitcoin and Litecoin with their scripts. It means that only specific operations can be used in arbitrary order, but loops and custom algorithms cannot be written.
Furthermore, there are smart contract platforms that implement pre-installed smart contracts. These include Bitshares and Steemit. Bitshares has a range of smart contracts for trading, account management, and managing the platform itself and its parameters. Steemit is a similar platform, but it focuses more on blogging rather than token issuance and trading, allowing for decentralized content storage and processing.
Platforms for arbitrary Turing-complete contracts include Ethereum and RootStock, which is still in development. Therefore, we will delve a little deeper into the Ethereum smart contract platform.
Smart contracts by initiation method
By method of initiation, smart contracts can be divided into at least two groups: automated and manual (non-automated). Automated contracts are characterized by being executed completely automatically when all known parameters and conditions are met, meaning that no additional transactions need to be sent, and no extra fees are incurred with each subsequent execution. The platform itself contains all the necessary data to calculate how the smart contract will conclude. Its logic is not arbitrary but predetermined, making outcomes predictable. Thus, the complexity of executing the smart contract can be assessed in advance, allowing a fixed fee to be utilized, and all processes related to its execution occur more efficiently.
For smart contracts programmed arbitrarily, execution is not automated. To initiate such a smart contract, a new transaction must be created at virtually every step, calling the next stage of execution or the next method of the smart contract, paying the corresponding fee, and waiting for transaction confirmation. Execution may end successfully or not, as the code of the smart contract is arbitrary, leading to unpredictable issues like infinite loops, lack of parameters and arguments, unhandled exceptions, etc.
Accounts in Ethereum
Types of Ethereum accounts
Let's explore what types of accounts exist on the Ethereum platform. There are only two types of accounts, and no other options. The first type is called a user account, and the second is a contract account. Let's look at how they differ.
A user account is controlled solely by a personal signature key. The account owner generates their key pair for digital signature using the ECDSA (Elliptic Curve Digital Signature Algorithm). Only transactions signed with this key can change the state of this account.
A smart contract account has its own distinct logic. It can only be managed through predefined program code that completely defines the behavior of the smart contract: how it will handle its coins under certain circumstances, initiated by which user, and under what additional conditions those coins will be distributed. If certain aspects are not accounted for by the developers in the program code, issues may arise. For example, a smart contract may reach a particular state where it does not accept initiation of further execution from any users. In such cases, coins can effectively become frozen because the smart contract does not provide a way out of this state.
How accounts are created in 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 the exact same algorithm and same elliptic curve for digital signatures as Bitcoin, but the address is computed in a slightly different manner. Here, the result of double hashing used in Bitcoin is not applied; instead, a single hash is performed using the Keccak function at 256 bits. From the resulting value, the lower bits are truncated, specifically the 160 least significant bits of the hash function's output. As a result, we obtain an address in Ethereum, which is actually 20 bytes long.
It is important to note that the account identifier in Ethereum is encoded in hex without the use of a checksum, unlike Bitcoin and many other systems where the address is encoded in a base-58 numbering system with the addition of a checksum. This means that one must work carefully with account identifiers in Ethereum: even a single mistake in the identifier will certainly result in the loss of coins.
There is an important feature, which is that the user's account at the level of the overall database is created at the moment when they receive their first incoming payment.
In relation to creating a smart contract account, a completely different approach is applied. Initially, one of the users writes the source code of the smart contract, after which the code is run through a special Ethereum platform compiler, obtaining bytecode for its own Ethereum virtual machine. The received bytecode is placed in a special transaction field. It is signed on behalf of the initiating account. Then, this transaction is propagated through the network and deploys the smart contract code. The transaction fee, and thus the contract execution fee, is deducted from the initiating account balance.
Each smart contract necessarily contains its own constructor (of this contract). It can be empty or it may contain content. After the constructor is executed, an account identifier for the smart contract is created, using which coins can be sent, specific methods of the smart contract can be called, etc.
Structure of an Ethereum transaction
To make it clearer, we will begin to examine the structure of an Ethereum transaction and an example of smart contract code.
An Ethereum transaction consists of several fields. The first one is nonce — this is a certain sequential number of the transaction relative to the very account that propagates it and is its author. This is necessary to distinguish duplicate transactions, that is, to eliminate the situation where the same transaction is accepted twice. Thanks to the identifier, each transaction has a unique hash value.
Next, there is a field called gas priceThis indicates the price at which the base currency Ethereum is converted into gas, which is used to pay for the execution of the smart contract and the allocation of virtual machine resources. What does this mean?
In Bitcoin, fees are paid directly in the base currency—Bitcoin itself. This is possible due to a simple calculation mechanism: we pay strictly for the volume of data contained in the transaction. In Ethereum, the situation is more complex because it is very difficult to base fees solely on the volume of data in the transaction. Here, the transaction may also contain code that will execute on the virtual machine, and each operation of the virtual machine can have different complexities. There are also operations that allocate memory for variables. They will have their own complexities, which will determine the payment for each operation.
The cost of each operation in gas equivalent will be constant. It is introduced specifically to define the constant cost of each operation. Depending on the network load, the gas price will change, which is the coefficient according to which the base currency will be converted into this auxiliary unit for paying fees.
There is another feature of transactions in Ethereum: the bytecode they contain for execution in the virtual machine will run until it completes with some result (success or failure), or until the amount of coins allocated for the fee runs out. This is to avoid a situation where all the coins sent from the sender's account are spent on fees in case of an error (for example, if an infinite loop occurs in the virtual machine); there is the following field— start gas (often referred to as gas limit) — it defines the maximum amount of coins that the sender is willing to spend on executing a specific transaction.
The next field is called destination address. Here, the recipient's address or the address of a specific smart contract whose methods will be called is entered. Following it is the field value, where the amount of coins being sent to the destination address is specified.
Next is an interesting field called data, where a whole structure fits in. This is not a separate field, but an entire structure that defines the code for the virtual machine. Arbitrary data can be placed here — there are specific rules for this.
The last field is called signature. It 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, the identifier of the sender's account of this transaction can be obtained, uniquely identifying the sender's account in the system. We have clarified the main structure of the transaction.
An example of a smart contract code in Solidity
Now, let's take a closer look at the simplest smart contract as 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 smart contract Bank that performs the following functions: it accumulates coins in its balance, meaning that when a transaction is confirmed and such a smart contract is deployed, a new account is created that can contain coins in its balance; it remembers users and the distribution of coins among them; has several methods for managing balances, allowing deposits, withdrawals, and balance checks for users.
Let's go through each line of the source code. This contract has constant fields. One of them, of type address, is called owner. Here, the contract remembers the address of the user who created this smart contract. Then, there is a dynamic structure that maintains the correspondence between user addresses and balances.
After this follows the method Bank — it has the same name as the contract. Therefore, this is its constructor. Here, the variable owner is assigned the address of the person who deployed this smart contract on the network. This is the only thing that happens in this constructor. Thus, msg in this case refers to the data passed to the virtual machine along with the transaction containing the entire code of this contract. Accordingly, msg.sender refers to the author of this transaction, who is deploying this code. He will be the owner of the smart contract.
The deposit method allows transferring a certain amount of coins to the contract's account through a transaction. In this case, the smart contract, upon receiving these coins, keeps them in its balance but records who the sender of these coins was in the balances structure to know to whom they belong.
The next method is called withdraw and it takes one parameter — the amount of coins that someone wants to withdraw from this bank. Here, it checks whether the user calling this method has enough coins in their balance to send them. If there are enough coins, the smart contract returns the specified amount to the caller.
Next comes the method for checking the current balance of the user. The one calling this method will be used to retrieve this balance in the smart contract. It is worth noting that the modifier for this method is view. This means that the method does not change any variables of its class and is essentially only a reading method. No separate transaction is created to call this method, no fee is paid, and all computations are performed locally, after which the user receives the result.
The kill method is necessary to destroy the state of the smart contract. An additional check is in place to determine if the caller of this method is the owner of the contract. If they are, the contract self-destructs, and the destruction function takes one parameter — the account identifier to which the contract will send all remaining coins on its balance. In this case, the remaining coins will automatically go to the contract owner's address.
How does a full node of the Ethereum network work?
Let's schematically consider how the execution of such smart contracts occurs on the Ethereum platform and how a full node of the network operates.
A full node of the Ethereum network must have at least four modules.
The first, as with any decentralized protocol, is the P2P networking module — the module for network connection and interaction 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 the blockchain data storage module, processing, priority branch selection, block addition, block detachment, verification of these blocks, etc.
The third module is called EVM (Ethereum Virtual Machine) — this is the virtual machine, which takes bytecode from an Ethereum transaction. This module receives the current state of a specific account and makes changes to its state based on the received bytecode. The version of the virtual machine on each network node must be the same. Computations occur on each Ethereum node in exactly the same way, but they happen asynchronously: some nodes verify and accept the transaction earlier, executing the code contained within, while others do so later. Accordingly, when a transaction is created, it spreads through the network, nodes accept it, and at the moment of validation, just as 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 within it has been executed, a new state for a specific account has been generated, and it is stored until it is clear whether this transaction has been applied or not. If the transaction is applied, then this state is considered not only executed but also current. There is a database that stores the state of each account for each network node. Since all computations occur identically and the blockchain state is the same, the database containing the states of all accounts will also be identical for each node.
Myths and limitations of smart contracts
Regarding the limitations that exist for smart contracts similar to Ethereum platforms, the following can be mentioned:
- code execution;
- allocate memory;
- blockchain data;
- send payments;
- create new contract;
- call other contracts.
Let's explore the limitations imposed on the virtual machine and dispel some myths about smart contracts. On a virtual machine, which can exist not only in Ethereum but also in similar platforms, it is possible to perform genuinely arbitrary logical operations; that is, you can write code that will execute there, and you can also allocate memory additionally. However, a fee is charged separately for each operation and for each additional unit of allocated memory.
Furthermore, the virtual machine can read data from the blockchain database in order to use this data as a trigger for executing certain smart contract logic. The virtual machine can create and send transactions, create new contracts, and call methods of other smart contracts that are already published on the network: they exist, are accessible, etc.
The most common myth is that Ethereum smart contracts can use information from any internet resources in their conditions. The truth is that the virtual machine cannot send a network request to any external information resource on the internet; that is, you cannot write a smart contract that distributes value among users based on, say, the weather outside, who won a certain championship, or any other event that occurred in the external world, because information about these events simply does not exist in the platform's database. In other words, there is nothing in the blockchain regarding this matter. If it does not appear there, then the virtual machine cannot use this data as triggers.
Disadvantages of Ethereum
Let’s outline the main issues. The first drawback is that there are certain challenges in designing, developing, and testing smart contracts in Ethereum (Ethereum uses the Solidity language for writing smart contracts). Indeed, practice shows that a very large percentage of all errors are attributed to human factors. This is indeed relevant even for already written Ethereum smart contracts that have medium or higher complexity. While the likelihood of errors is low for simple smart contracts, complex smart contracts often contain errors that can lead to the theft of funds, freezing them, or the unforeseen destruction of smart contracts, among other issues. There are already many known cases of this.
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 therein lies a vulnerability: it is possible to configure a series of commands in such a way that they lead to unforeseen consequences. This is a very complex area, but there are already several studies showing that these vulnerabilities exist in the current version of the Ethereum network and can lead to the failure of many smart contracts.
Another significant difficulty, which can also be seen as a drawback, is that practically or technically, one can reach a point where compiling the bytecode of a contract that will run on the virtual machine may define a specific order of operations. When executed together, these operations can heavily burden the virtual machine and slow it down disproportionately to the fee paid for carrying out these operations.
In the past, there was a development period for Ethereum when many individuals who understood the functioning of the virtual machine discovered vulnerabilities. In fact, transactions paid very small fees, but they significantly slowed down the entire network. These problems are very complex to resolve, as they must first be determined, secondly, the cost for executing these operations must be adjusted, and thirdly, a hard fork is required, which means updating all nodes in the network to a new software version and then simultaneously activating these changes.
As for Ethereum, a great deal of research has been conducted, and significant practical experience has been gained, both positive and negative. However, complexities and vulnerabilities remain that still need to be addressed.
So, the thematic part of the article is concluded; let's move on to frequently asked questions.
Frequently Asked Questions
— If all parties involved in an active smart contract want to change the terms, can they cancel this smart contract using a multi-signature and then create a new smart contract with updated execution conditions?
The answer to this will be twofold. Why? Because on one hand, a smart contract is defined once and does not imply any changes, while on the other hand, it can have pre-written logic that allows for complete or partial changes to certain conditions. So, if you want to modify something in your smart contract, you must specify the conditions under which you can update these terms in advance. Thus, only through such foresight can you organize the contract's update. However, this too can lead to complications: making some mistake may result in a corresponding vulnerability. Therefore, such things need to be designed and tested very carefully and thoroughly.
— What if the mediator colludes with one of the participating parties: an escrow or smart contract? Is a mediator mandatory in a smart contract?
A mediator is not mandatory in a smart contract. It can be absent. If in the case of escrow, the mediator colludes with one of the parties, then yes, this scheme loses all its value. Therefore, mediators are chosen in such a way that all parties involved in the process trust them simultaneously. Consequently, you simply will not transfer coins to a multisignature address with a mediator you do not trust.
— Is it possible to transfer many different tokens from your address to different target addresses, such as exchange addresses where these tokens are traded, with one Ethereum transaction?
This is a good question and relates to the model of Ethereum transactions and its difference from the Bitcoin model. And the difference is radical. In the Ethereum transaction model, you simply transfer coins; they are sent from one address to another without 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 multiple different tokens in one transaction if a clever smart contract is written, but you would still need to perform many transactions: create a contract, then transfer tokens and coins to it, and then call the corresponding method. This requires effort and time; therefore, in practice, it doesn't work that way, and all payments in Ethereum are made as separate transactions.
— One of the myths about the Ethereum platform is that it is impossible to describe conditions that depend on data from an external internet resource; what should be done then?
The solution is that the smart contract can provide for one or more so-called trusted oracles that gather information about the state of affairs in the external world and pass it to smart contracts through specific methods. The contract considers as true the data it receives from trusted parties. For greater reliability, a larger group of oracles is simply chosen to minimize the risk of collusion. The contract may ignore data from oracles that contradict the majority.
This topic is covered in one of the lectures of the online Blockchain course — “”.
Source: habr.com
