About smart contracts in simple words
Good day! Previously, we had blog posts on the blockchain topic, in which there were often discussions about distributed computing in the blockchain. Based on these discussions, this post appeared.
So let's try today to understand what smart contracts are (smart contracts). First, we will discuss the concept itself fairly generally, and then we will dig a little into the implementation of smart contracts using the example of the Ethereum blockchain.
The term “smart contract” has already been settled and, as a matter of fact, denotes a certain code that is executed on a blockchain platform in such a way that its execution is verified by independent parties.
What does it mean? Is this distributed computing? In the usual sense, we still do not.
')
When we talk about distributed computing, load distribution is usually implied. Let's say we have a task to count in the huge text file the occurrences of a certain word. We cut the file into several parts, distribute these parts to different nodes (for example, using Hadoop), each performs a count and gives an answer. We summarize the answers and get the result. Thus, we significantly speed up the task execution.
If we talk about smart contracts, then the situation is completely different. Here we don’t cut the file into separate parts, we give the entire file to each node, and each node gives us the same result (ideally). Let us return to our question: does such an action fall under the definition of distributed computing? Well, in general, why not? They are distributed and they are calculations? Only in this case we are not talking about load distribution, but about the distribution of trust.
And yes, it should be noted that such a concept is difficult to scale, because the necessary mechanisms were not originally incorporated into it. Why then may such a construction be necessary? The most obvious example is the creation of a social contract (contract) between two or more parties. Hence the name of the concept - “smart contract”. The parties fix the agreements and conditions for the implementation of a scenario of development of relations between themselves, using a programming language, so that the occurrence of certain events will automatically cause the execution of a predefined code.
A classic example of such a contract, described back in 1996 by Nick Sabo, is a vending machine. It always works automatically according to a strict set of rules: you deposit money, make a choice - the car gives the goods. Making money, you can not change your mind and ask them to return. In the case of a smart contract, the code becomes a kind of law, cannot be challenged, and it will always be executed when the necessary conditions are met.
Here it is necessary to clarify that the current implementation of smart contracts (hereinafter, we will talk about the Ethereum network) is, in essence, a story closed in a blockchain environment. What does it mean? You cannot write a contract that will receive data from the outside (for example, from weather data providers) and implement the logic on this data. There is some progress, for example, Microsoft is working on the concept of krypletov or there are so-called oracles, but for now, I think, there is room to grow.
Therefore, I will propose another example of a smart contract, which is fully closed in the blockchain. Lottery, and absolutely honest and transparent. You send a transaction to the address of a smart contract, and it follows the logic in advance (let it be some randomizer) that decides whether you won or not. If you win, you get all the money accumulated in the smart contract, and if you lose, your transaction goes to a common piggy bank for future players.
All these examples are relatively simple and somewhat divorced from real life. What benefits can be derived from the work of smart contracts, if you take them seriously? The concept of verifiable code execution allows you to build systems that were previously unavailable or their creation was very difficult.
Suppose you have a certain community in which you need to take some kind of decision. Suppose this decision is extremely important, and the community is not inclined to simply trust its individual members. Take as an example a consortium of banks. It is logical to assume that not a single member of the consortium will want to delegate the execution of calculations to one bank, especially when our “most important decision” will be made on the basis of these calculations. After all, having given both the data and the ability to carry out these calculations in one hand, you can put your business in a risky position, and even the open source code of calculations will not convince you of the correct execution of this code on another server. You will want to check this execution. And here we get the very benefit from the concept of the checked execution: participants are able to unite to perform a common task or make a decision without a central operator and thus increase the efficiency of their businesses.
Yes, smart contracts do not scale very much in current implementations, because they are not embedded in them. But even now it is possible to carry out heavy calculations outside the environment of smart contracts and fix in them only certain reference points, which the parties can agree on ashore, thus achieving the necessary speed of work in some scenarios.
Now let's try to talk about the technical side of the implementation of smart contracts on the example of the Ethereum blockchain. What is the process of writing, publishing and executing a smart contract?
In this network, Solidity is used to write smart contracts, which is somewhat similar to JS, and it is Turing-complete (that is, any computable function can be implemented on it).
The code itself is executed in the so-called Ethereum Virtual Machine (EVM). It should be noted that the code is executed and checked by all the participants in the system; therefore, a certain mechanism is needed, which somehow limits the resource consumption by each smart contract (otherwise you can write an infinite loop). Therefore, the essence of gas (fuel) is introduced in Ethereum. A contract in Ethereum can execute any instructions, call other contracts, write and read data, and so on. All these operations consume fuel, the fuel is paid for by cryptocurrency (Ether). The price of cryptocurrency fuel Ethe is formed dynamically by the market. A contract execution trigger is a transaction. The cost of fuel that is burned in a particular transaction is removed from the account that launched the transaction. In addition, there is a limit on fuel consumption, it is made in order to protect the account from errors in writing the contract, which can lead to uncontrolled combustion of the entire cryptocurrency on this account.
It is important to note that the smart contract environment is still very different from the code execution environment we are used to. The error can be very expensive, the operations themselves are expensive and slow. Difficult mechanism for updating the smart contract. You are essentially writing a new one and have to convince the parties to use this new smart contract. It cannot be said that there is no way to switch to a new version of your contract, but this is often a new social contract. If you think about it - a striking difference when you are used to simply rolling out updates of your centralized system to consumers, without being too interested in their opinion. Building some kind of system to work in real life scenarios on smart contracts, it is worth understanding these limitations.
So let's try today to understand what smart contracts are (smart contracts). First, we will discuss the concept itself fairly generally, and then we will dig a little into the implementation of smart contracts using the example of the Ethereum blockchain.
About the concept of smart contracts
The term “smart contract” has already been settled and, as a matter of fact, denotes a certain code that is executed on a blockchain platform in such a way that its execution is verified by independent parties.
What does it mean? Is this distributed computing? In the usual sense, we still do not.
')
When we talk about distributed computing, load distribution is usually implied. Let's say we have a task to count in the huge text file the occurrences of a certain word. We cut the file into several parts, distribute these parts to different nodes (for example, using Hadoop), each performs a count and gives an answer. We summarize the answers and get the result. Thus, we significantly speed up the task execution.
If we talk about smart contracts, then the situation is completely different. Here we don’t cut the file into separate parts, we give the entire file to each node, and each node gives us the same result (ideally). Let us return to our question: does such an action fall under the definition of distributed computing? Well, in general, why not? They are distributed and they are calculations? Only in this case we are not talking about load distribution, but about the distribution of trust.
And yes, it should be noted that such a concept is difficult to scale, because the necessary mechanisms were not originally incorporated into it. Why then may such a construction be necessary? The most obvious example is the creation of a social contract (contract) between two or more parties. Hence the name of the concept - “smart contract”. The parties fix the agreements and conditions for the implementation of a scenario of development of relations between themselves, using a programming language, so that the occurrence of certain events will automatically cause the execution of a predefined code.
A classic example of such a contract, described back in 1996 by Nick Sabo, is a vending machine. It always works automatically according to a strict set of rules: you deposit money, make a choice - the car gives the goods. Making money, you can not change your mind and ask them to return. In the case of a smart contract, the code becomes a kind of law, cannot be challenged, and it will always be executed when the necessary conditions are met.
Here it is necessary to clarify that the current implementation of smart contracts (hereinafter, we will talk about the Ethereum network) is, in essence, a story closed in a blockchain environment. What does it mean? You cannot write a contract that will receive data from the outside (for example, from weather data providers) and implement the logic on this data. There is some progress, for example, Microsoft is working on the concept of krypletov or there are so-called oracles, but for now, I think, there is room to grow.
Therefore, I will propose another example of a smart contract, which is fully closed in the blockchain. Lottery, and absolutely honest and transparent. You send a transaction to the address of a smart contract, and it follows the logic in advance (let it be some randomizer) that decides whether you won or not. If you win, you get all the money accumulated in the smart contract, and if you lose, your transaction goes to a common piggy bank for future players.
All these examples are relatively simple and somewhat divorced from real life. What benefits can be derived from the work of smart contracts, if you take them seriously? The concept of verifiable code execution allows you to build systems that were previously unavailable or their creation was very difficult.
Suppose you have a certain community in which you need to take some kind of decision. Suppose this decision is extremely important, and the community is not inclined to simply trust its individual members. Take as an example a consortium of banks. It is logical to assume that not a single member of the consortium will want to delegate the execution of calculations to one bank, especially when our “most important decision” will be made on the basis of these calculations. After all, having given both the data and the ability to carry out these calculations in one hand, you can put your business in a risky position, and even the open source code of calculations will not convince you of the correct execution of this code on another server. You will want to check this execution. And here we get the very benefit from the concept of the checked execution: participants are able to unite to perform a common task or make a decision without a central operator and thus increase the efficiency of their businesses.
Yes, smart contracts do not scale very much in current implementations, because they are not embedded in them. But even now it is possible to carry out heavy calculations outside the environment of smart contracts and fix in them only certain reference points, which the parties can agree on ashore, thus achieving the necessary speed of work in some scenarios.
The technical side of the issue
Now let's try to talk about the technical side of the implementation of smart contracts on the example of the Ethereum blockchain. What is the process of writing, publishing and executing a smart contract?
In this network, Solidity is used to write smart contracts, which is somewhat similar to JS, and it is Turing-complete (that is, any computable function can be implemented on it).
The code itself is executed in the so-called Ethereum Virtual Machine (EVM). It should be noted that the code is executed and checked by all the participants in the system; therefore, a certain mechanism is needed, which somehow limits the resource consumption by each smart contract (otherwise you can write an infinite loop). Therefore, the essence of gas (fuel) is introduced in Ethereum. A contract in Ethereum can execute any instructions, call other contracts, write and read data, and so on. All these operations consume fuel, the fuel is paid for by cryptocurrency (Ether). The price of cryptocurrency fuel Ethe is formed dynamically by the market. A contract execution trigger is a transaction. The cost of fuel that is burned in a particular transaction is removed from the account that launched the transaction. In addition, there is a limit on fuel consumption, it is made in order to protect the account from errors in writing the contract, which can lead to uncontrolled combustion of the entire cryptocurrency on this account.
It is important to note that the smart contract environment is still very different from the code execution environment we are used to. The error can be very expensive, the operations themselves are expensive and slow. Difficult mechanism for updating the smart contract. You are essentially writing a new one and have to convince the parties to use this new smart contract. It cannot be said that there is no way to switch to a new version of your contract, but this is often a new social contract. If you think about it - a striking difference when you are used to simply rolling out updates of your centralized system to consumers, without being too interested in their opinion. Building some kind of system to work in real life scenarios on smart contracts, it is worth understanding these limitations.
Source: https://habr.com/ru/post/337984/
All Articles