Why many cases of application of smart contracts are simply not feasible
One of the purposes of smart contracts is to automate payment transactions between counterparties. Our payment blockchain service, Wirex, also operates in this market. Despite the promise of smart contracts, the author of the material analyzes the shortcomings of this technology.
As a developer of a popular blockchain platform, I am sometimes asked if the development plans of our Multichain service include a place for smart contracts like those used in Ethereum. The answer always says: "No, or in any case, not now."
But after all, in the noisy HYIP world of blockchains, smart contracts are considered something very cool. Why is the answer always not? Well, the problem is that if in the case of controlled blockchains that work like Bitcoin, we know at least three powerful scenarios of their practical application (tracing the origin history, storing company documents, facilitating the organization of financial systems), then for on- air smart contracts of equivalent effectiveness cases simply do not exist.
The point is not that people do not understand what they want from smart contracts. The problem is rather that very many of these ideas are simply not feasible. When smart people hear the term smart contracts, they tend to give vent to their imagination. They draw pictures of intelligent, autonomous software in their heads, riding the data wave and connecting to solving real-world problems. Unfortunately, the real picture of the work of smart contracts is much more prosaic.
A smart contract is a piece of code stored in a blockchain. It is driven by blockchain transactions and reads from the blockchain or writes data to it. That's all. No more, no less.
A smart contract is just a sonorous code name that works on the blockchain and interacts with its state. What is this code? This is Pascal, Python or PHP. Or maybe Java, Fortran or C ++. If you think of the format of the database, then it can be represented in the form of procedures written in any extension of SQL.
Fundamentally, all these languages are equivalent, they solve the same kinds of problems, using the same methods of solving them. Of course, each of them has strengths and weaknesses. You would be crazy trying to create a C website or compress HD video in Ruby. But at least theoretically, you could do it if you wanted. You would just have to pay a high price in terms of convenience, performance, and very likely lose a lot of hair on your head.
The problem of smart contracts lies not only in excessively high expectations, but also in the fact that these expectations lead to the fact that a considerable number of people spend time and money on ideas that can hardly be realized in practice.
Practice shows that large companies, as a rule, have enough resources to go a long way from the moment when top management learns about a new technology to the moment when its advantages and limitations are truly understood.
Over the past nine months, we listened to a lot of pitches on possible scenarios for the use of smart contracts and it just so happened that time after time we answered their authors that these ideas simply could not be realized in real life.
As a result, we have identified the top three most common misconceptions about smart contracts. These ideas are wrong, not because the technology is not mature enough or not because we do not yet have some tools.
Instead, they are based on a misunderstanding of the fundamental properties of code that lives in a database and is processed in a decentralized way.
You can often hear a suggestion to use smart contracts that change their behavior in response to some external event. For example, an agricultural insurance policy that makes payments based on the amount of precipitation that fell in a particular month.
According to the idea of the authors of the idea, the process proceeds approximately as follows: a smart contract waits for some predetermined time, receives weather reports from an external service and behaves in accordance with the data obtained.
Sounds pretty simple. Simple and at the same time impossible. Why? Because the blockchain is a consensus-based system, which means that it will work only if each network node reaches the same state after processing each transaction and each block.
All operations occurring in the blockchain must be fully determined, without the slightest probability that any difference will creep into his work. As soon as two honest nodes occupy different positions on the state of the chain, the whole system becomes useless.
And now I remind you that each node of the chain executes smart contracts independently. This means that if a smart contract receives some information from an external source, then each node repeats the procedure for obtaining data on its own. But since the source is outside the blockchain, there is no guarantee that each node will receive the same answer.
Perhaps the source will change its response at some point in time between requests from two different nodes, or it may become temporarily unavailable. Anyway, consensus will not be reached and the whole blockchain will stop working.
What is the way to find a way out of the situation? And the way out is really very simple. It is only necessary to replace the process of applying a smart contract to an external source on one or several trusted parties (the so-called oracles) creating a transaction that writes the necessary data to the chain. Then each node will have an identical copy of the data, and they can be used in the calculations of a smart contract.
In other words, instead of a smart contract that “pulls up” data from the outside, the oracle will enter this same data into the blockchain.
Similar problems arise when it comes to smart contracts that initiate certain events in the outside world. For example, many people like the idea of smart contracts, referring to the bank API for transferring money. But if each node executes the chain code independently, which node will be responsible for the API call?
If it is any one node, then what happens if this particular node, intentionally or involuntarily, starts to fail? And if all the nodes will apply, can we trust each node the password from the API? And is it justified to make hundreds of appeals instead of one? And what's even worse: if a smart contract needs to determine the success of an API call, then again we are faced with the problem of dependence on external data.
And here, too, there is a simple way out. Instead of entrusting an external API with a smart contract, we can use a trusted service that monitors the state of the blockchain and performs certain actions in response to the data. For example, a bank could proactively monitor the blockchain and make money transfers that correspond to the transactions approved in the chain. Such an approach does not create any risks for reaching a consensus, since the chain in this model plays an absolutely passive role.
Having considered the proposed exits from the situations described above, we can draw some conclusions.
First, both approaches require the presence of some trusted third party to manage the interactions between the blockchain and the outside world. Despite the theoretical possibility of implementing such a model, any decentralization within its framework loses all meaning.
Secondly, the mechanisms used in these examples are direct examples of reading and writing to the database. The oracle that provides external information simply writes it to the chain. A service that repeats the state of the blockchain in the real world is nothing more than reading from this chain. In other words, any interaction between the blockchain and the outside world in this case is reduced to normal database operations.
In more detail we will reveal this fact further in the material.
Another proposal that we hear quite often: the use of smart contracts to automate the payment of coupons of so-called smart bonds. The essence of the idea is to automatically initiate the payment at the right time, performed by a smart contract. This will avoid manual processing of the payment and ensures that the issuer will not be able to default.
Of course, for this idea to work, the funds used for payouts must also be inside the blockchain. Otherwise, a smart contract simply cannot guarantee payment.
Let's remember that blockchain is just a database. In our case, there is a financial register containing issued bonds and some cash. Therefore, when we talk about coupon payments, we are actually talking about database operations that are performed automatically at an agreed time.
Despite the fact that from a technical point of view, such automation is feasible, difficulties arise with the financial aspect of the model. If the funds used for coupon payments are managed by a smart bonded contract, then these payments can indeed be guaranteed. But in this case, the issuer of the bonds will not be able to use these funds for any other purposes. A withdrawal of funds from the control of a smart contract, makes any guarantee of their payment void.
In other words, a smart bond is meaningless for either the issuer or the investor. If you reflect on this situation, then such a conclusion becomes quite obvious.
From the investor’s point of view, the essence of bond purchases is the ability to make an attractive profit, if there is some acceptable risk of default. For the issuer, the meaning of issuing bonds is to raise funds for productive but somewhat risky activities, such as building a new factory.
For the issuer there is no way to raise funds, and at the same time uniquely guarantee payments to investors. I think no one will be surprised by the fact that the regularity between risk and profitability is not included in the list of tasks that blockchains can solve.
As I wrote earlier, the most serious challenge that we face when deploying blockchains is the extreme degree of transparency they provide.
For example, if a group of 10 banks wants to create a blockchain together, any bilateral transactions in this blockchain immediately become visible to the eight other participants. Despite the existence of various strategies to level this effect, none of them can surpass the simplicity and effectiveness of a centralized database managed by a certain proxy who has full control over the levels of visibility and access of all participants.
Some people believe that smart contracts can solve this problem. Their reasoning begins with the fact that each smart contract contains its own miniature database and manages it completely. All read and write operations in this database take place with the full mediation of the contract code, which excludes the situation when one contract reads the data of another. (This close connection between data and code is called encapsulation. It underlies the popular paradigms of object-oriented programming.)
So no smart contract can access data from other smart contacts. But does this solve the problem of confidentiality inside the blockchain? Does it make sense to talk about hiding information inside a smart contract? Unfortunately, the answer is no.
Yes, a smart contract cannot read data from other contracts, however these copies of this data are still in each individual node of the network. Each participant keeps this data in his memory or on the hard disk of the system, which is under his complete control. As a result, nothing stops this participant from reading information in his own system, if and when he wants to do it.
Attempts to hide data in a smart contract are comparable in security level to an attempt to hide it in the HTML code of a web page. Of course, ordinary web users will not see such information, since it will not be displayed in the browser window. But for its disclosure, you only need to click on the button to display the "source code", which is in all modern browsers and the data immediately become at a glance.
Similarly, in the case of data hidden in a smart contract, you only need to make changes to the software for working with the blockchain so that it displays the full status of the contract and all the appearance of secrecy will immediately disappear.
Any average programmer will cope with this task in no more than an hour.
After all that has been written above, a reasonable question arises: where in general can smart contracts be used? But in order to answer this question, we need to mentally return to the basic concepts of blockchains. In short, the blockchain allows a group of individuals who do not trust each other to work together directly, and safely with the database without the need to seek help from a certain main administrator.
Blockchains allow you to abandon the mediation of working with data, which can lead to a significant simplification and cost reduction.
To make a change to any database, you must perform a so-called transaction that contains a set of changes in the database, which will either be successfully applied or rejected all together. Take, for example, the situation with the financial registry, when Alice makes a payment in favor of Bob. The payment is in the form of a transaction that: a) checks if Alice has enough funds in her account, b) deducts a specified amount of funds from Alice's account, and c) adds the same amount to Bob's account.
In a conventional centralized database, these transactions are created by some single trusted manager. In contrast, in a public blockchain-type database, transactions can be created by any blockchain user. And since there is no absolute trust between these users, there should be rules in the database that impose restrictions on the execution of transactions.
For example, in a financial registry, all nodes of which are in the same position, the parameters of each transaction should not disrupt the overall balance of funds. Otherwise, participants will be able to freely allocate as much money as they like.
Ways to comply with these rules can come up with a great many, but currently dominated by two paradigms, which became widespread under the influence of Bitcoin and Ethereum. The Bitcoin method, which can be called “transaction restriction” in a different way, evaluates each transaction from the point of view of: a) records in the database deleted using this transaction and b) records created.
The financial register uses the rule: the total amount of funds in deleted records should not conflict with the total amount in the created ones. (a change in a record is considered to be the deletion of this record and its re-creation with the necessary values).
The second paradigm originating in Ethereum is smart contracts. According to it, all changes in the contract data must be carried out by its code. (In the context of traditional databases, we can assume that this is a mandatory stored procedure) To change contract data, blockchain users send requests to its code, which determines whether to execute the request and how it should be done.
In the light of the above example, a smart contract for a financial registry performs the same tasks as a centralized database administrator: checking for sufficient funds, subtracting them from one account and adding them to another.
Both paradigms work efficiently, and each has its own advantages and disadvantages. In short, the restriction of bitcoin-type transactions allows for better simultaneous availability and performance, while smart ethereal contracts allow for greater flexibility.
Therefore, returning to the question of why smart contracts are intended: they are necessary when it is not possible to implement a blockchain case using transactional restrictions.
But even having decided on this criterion for the use of smart contracts, I still find it difficult to name at least one scenario of their use for closed blockchains, where the traditional bitcoin approach really would not be applicable.
All really interesting blockchain projects that I know can be implemented using the bitcoin approach, within which you can implement both separation of access rights and data storage, and creation of assets, their movement, deposit, exchange and destruction. Anyway, new user cases appear regularly and I won’t be surprised if some of them really need the power of smart contracts. Or at least the broader Bitcoin paradigm.
One way or another, the key rule in any situation is to remember that smart contracts are just one of the methods for restricting the execution of transactions in a database.
They are undoubtedly a very useful thing and play an important role in ensuring the security of database sharing. However, smart contracts are not capable of anything else. And certainly they can not go beyond the database in which they exist.
As a developer of a popular blockchain platform, I am sometimes asked if the development plans of our Multichain service include a place for smart contracts like those used in Ethereum. The answer always says: "No, or in any case, not now."
But after all, in the noisy HYIP world of blockchains, smart contracts are considered something very cool. Why is the answer always not? Well, the problem is that if in the case of controlled blockchains that work like Bitcoin, we know at least three powerful scenarios of their practical application (tracing the origin history, storing company documents, facilitating the organization of financial systems), then for on- air smart contracts of equivalent effectiveness cases simply do not exist.
The point is not that people do not understand what they want from smart contracts. The problem is rather that very many of these ideas are simply not feasible. When smart people hear the term smart contracts, they tend to give vent to their imagination. They draw pictures of intelligent, autonomous software in their heads, riding the data wave and connecting to solving real-world problems. Unfortunately, the real picture of the work of smart contracts is much more prosaic.
A smart contract is a piece of code stored in a blockchain. It is driven by blockchain transactions and reads from the blockchain or writes data to it. That's all. No more, no less.
A smart contract is just a sonorous code name that works on the blockchain and interacts with its state. What is this code? This is Pascal, Python or PHP. Or maybe Java, Fortran or C ++. If you think of the format of the database, then it can be represented in the form of procedures written in any extension of SQL.
Fundamentally, all these languages are equivalent, they solve the same kinds of problems, using the same methods of solving them. Of course, each of them has strengths and weaknesses. You would be crazy trying to create a C website or compress HD video in Ruby. But at least theoretically, you could do it if you wanted. You would just have to pay a high price in terms of convenience, performance, and very likely lose a lot of hair on your head.
The problem of smart contracts lies not only in excessively high expectations, but also in the fact that these expectations lead to the fact that a considerable number of people spend time and money on ideas that can hardly be realized in practice.
Practice shows that large companies, as a rule, have enough resources to go a long way from the moment when top management learns about a new technology to the moment when its advantages and limitations are truly understood.
Over the past nine months, we listened to a lot of pitches on possible scenarios for the use of smart contracts and it just so happened that time after time we answered their authors that these ideas simply could not be realized in real life.
As a result, we have identified the top three most common misconceptions about smart contracts. These ideas are wrong, not because the technology is not mature enough or not because we do not yet have some tools.
Instead, they are based on a misunderstanding of the fundamental properties of code that lives in a database and is processed in a decentralized way.
1. Interaction with external services
You can often hear a suggestion to use smart contracts that change their behavior in response to some external event. For example, an agricultural insurance policy that makes payments based on the amount of precipitation that fell in a particular month.
According to the idea of the authors of the idea, the process proceeds approximately as follows: a smart contract waits for some predetermined time, receives weather reports from an external service and behaves in accordance with the data obtained.
Sounds pretty simple. Simple and at the same time impossible. Why? Because the blockchain is a consensus-based system, which means that it will work only if each network node reaches the same state after processing each transaction and each block.
All operations occurring in the blockchain must be fully determined, without the slightest probability that any difference will creep into his work. As soon as two honest nodes occupy different positions on the state of the chain, the whole system becomes useless.
And now I remind you that each node of the chain executes smart contracts independently. This means that if a smart contract receives some information from an external source, then each node repeats the procedure for obtaining data on its own. But since the source is outside the blockchain, there is no guarantee that each node will receive the same answer.
Perhaps the source will change its response at some point in time between requests from two different nodes, or it may become temporarily unavailable. Anyway, consensus will not be reached and the whole blockchain will stop working.
What is the way to find a way out of the situation? And the way out is really very simple. It is only necessary to replace the process of applying a smart contract to an external source on one or several trusted parties (the so-called oracles) creating a transaction that writes the necessary data to the chain. Then each node will have an identical copy of the data, and they can be used in the calculations of a smart contract.
In other words, instead of a smart contract that “pulls up” data from the outside, the oracle will enter this same data into the blockchain.
Similar problems arise when it comes to smart contracts that initiate certain events in the outside world. For example, many people like the idea of smart contracts, referring to the bank API for transferring money. But if each node executes the chain code independently, which node will be responsible for the API call?
If it is any one node, then what happens if this particular node, intentionally or involuntarily, starts to fail? And if all the nodes will apply, can we trust each node the password from the API? And is it justified to make hundreds of appeals instead of one? And what's even worse: if a smart contract needs to determine the success of an API call, then again we are faced with the problem of dependence on external data.
And here, too, there is a simple way out. Instead of entrusting an external API with a smart contract, we can use a trusted service that monitors the state of the blockchain and performs certain actions in response to the data. For example, a bank could proactively monitor the blockchain and make money transfers that correspond to the transactions approved in the chain. Such an approach does not create any risks for reaching a consensus, since the chain in this model plays an absolutely passive role.
Having considered the proposed exits from the situations described above, we can draw some conclusions.
First, both approaches require the presence of some trusted third party to manage the interactions between the blockchain and the outside world. Despite the theoretical possibility of implementing such a model, any decentralization within its framework loses all meaning.
Secondly, the mechanisms used in these examples are direct examples of reading and writing to the database. The oracle that provides external information simply writes it to the chain. A service that repeats the state of the blockchain in the real world is nothing more than reading from this chain. In other words, any interaction between the blockchain and the outside world in this case is reduced to normal database operations.
In more detail we will reveal this fact further in the material.
2. Making payments within a chain
Another proposal that we hear quite often: the use of smart contracts to automate the payment of coupons of so-called smart bonds. The essence of the idea is to automatically initiate the payment at the right time, performed by a smart contract. This will avoid manual processing of the payment and ensures that the issuer will not be able to default.
Of course, for this idea to work, the funds used for payouts must also be inside the blockchain. Otherwise, a smart contract simply cannot guarantee payment.
Let's remember that blockchain is just a database. In our case, there is a financial register containing issued bonds and some cash. Therefore, when we talk about coupon payments, we are actually talking about database operations that are performed automatically at an agreed time.
Despite the fact that from a technical point of view, such automation is feasible, difficulties arise with the financial aspect of the model. If the funds used for coupon payments are managed by a smart bonded contract, then these payments can indeed be guaranteed. But in this case, the issuer of the bonds will not be able to use these funds for any other purposes. A withdrawal of funds from the control of a smart contract, makes any guarantee of their payment void.
In other words, a smart bond is meaningless for either the issuer or the investor. If you reflect on this situation, then such a conclusion becomes quite obvious.
From the investor’s point of view, the essence of bond purchases is the ability to make an attractive profit, if there is some acceptable risk of default. For the issuer, the meaning of issuing bonds is to raise funds for productive but somewhat risky activities, such as building a new factory.
For the issuer there is no way to raise funds, and at the same time uniquely guarantee payments to investors. I think no one will be surprised by the fact that the regularity between risk and profitability is not included in the list of tasks that blockchains can solve.
3. The need to hide sensitive data
As I wrote earlier, the most serious challenge that we face when deploying blockchains is the extreme degree of transparency they provide.
For example, if a group of 10 banks wants to create a blockchain together, any bilateral transactions in this blockchain immediately become visible to the eight other participants. Despite the existence of various strategies to level this effect, none of them can surpass the simplicity and effectiveness of a centralized database managed by a certain proxy who has full control over the levels of visibility and access of all participants.
Some people believe that smart contracts can solve this problem. Their reasoning begins with the fact that each smart contract contains its own miniature database and manages it completely. All read and write operations in this database take place with the full mediation of the contract code, which excludes the situation when one contract reads the data of another. (This close connection between data and code is called encapsulation. It underlies the popular paradigms of object-oriented programming.)
So no smart contract can access data from other smart contacts. But does this solve the problem of confidentiality inside the blockchain? Does it make sense to talk about hiding information inside a smart contract? Unfortunately, the answer is no.
Yes, a smart contract cannot read data from other contracts, however these copies of this data are still in each individual node of the network. Each participant keeps this data in his memory or on the hard disk of the system, which is under his complete control. As a result, nothing stops this participant from reading information in his own system, if and when he wants to do it.
Attempts to hide data in a smart contract are comparable in security level to an attempt to hide it in the HTML code of a web page. Of course, ordinary web users will not see such information, since it will not be displayed in the browser window. But for its disclosure, you only need to click on the button to display the "source code", which is in all modern browsers and the data immediately become at a glance.
Similarly, in the case of data hidden in a smart contract, you only need to make changes to the software for working with the blockchain so that it displays the full status of the contract and all the appearance of secrecy will immediately disappear.
Any average programmer will cope with this task in no more than an hour.
What is the purpose of smart contracts?
After all that has been written above, a reasonable question arises: where in general can smart contracts be used? But in order to answer this question, we need to mentally return to the basic concepts of blockchains. In short, the blockchain allows a group of individuals who do not trust each other to work together directly, and safely with the database without the need to seek help from a certain main administrator.
Blockchains allow you to abandon the mediation of working with data, which can lead to a significant simplification and cost reduction.
To make a change to any database, you must perform a so-called transaction that contains a set of changes in the database, which will either be successfully applied or rejected all together. Take, for example, the situation with the financial registry, when Alice makes a payment in favor of Bob. The payment is in the form of a transaction that: a) checks if Alice has enough funds in her account, b) deducts a specified amount of funds from Alice's account, and c) adds the same amount to Bob's account.
In a conventional centralized database, these transactions are created by some single trusted manager. In contrast, in a public blockchain-type database, transactions can be created by any blockchain user. And since there is no absolute trust between these users, there should be rules in the database that impose restrictions on the execution of transactions.
For example, in a financial registry, all nodes of which are in the same position, the parameters of each transaction should not disrupt the overall balance of funds. Otherwise, participants will be able to freely allocate as much money as they like.
Ways to comply with these rules can come up with a great many, but currently dominated by two paradigms, which became widespread under the influence of Bitcoin and Ethereum. The Bitcoin method, which can be called “transaction restriction” in a different way, evaluates each transaction from the point of view of: a) records in the database deleted using this transaction and b) records created.
The financial register uses the rule: the total amount of funds in deleted records should not conflict with the total amount in the created ones. (a change in a record is considered to be the deletion of this record and its re-creation with the necessary values).
The second paradigm originating in Ethereum is smart contracts. According to it, all changes in the contract data must be carried out by its code. (In the context of traditional databases, we can assume that this is a mandatory stored procedure) To change contract data, blockchain users send requests to its code, which determines whether to execute the request and how it should be done.
In the light of the above example, a smart contract for a financial registry performs the same tasks as a centralized database administrator: checking for sufficient funds, subtracting them from one account and adding them to another.
Both paradigms work efficiently, and each has its own advantages and disadvantages. In short, the restriction of bitcoin-type transactions allows for better simultaneous availability and performance, while smart ethereal contracts allow for greater flexibility.
Therefore, returning to the question of why smart contracts are intended: they are necessary when it is not possible to implement a blockchain case using transactional restrictions.
But even having decided on this criterion for the use of smart contracts, I still find it difficult to name at least one scenario of their use for closed blockchains, where the traditional bitcoin approach really would not be applicable.
All really interesting blockchain projects that I know can be implemented using the bitcoin approach, within which you can implement both separation of access rights and data storage, and creation of assets, their movement, deposit, exchange and destruction. Anyway, new user cases appear regularly and I won’t be surprised if some of them really need the power of smart contracts. Or at least the broader Bitcoin paradigm.
One way or another, the key rule in any situation is to remember that smart contracts are just one of the methods for restricting the execution of transactions in a database.
They are undoubtedly a very useful thing and play an important role in ensuring the security of database sharing. However, smart contracts are not capable of anything else. And certainly they can not go beyond the database in which they exist.
All Articles