Why many smart contract use cases are simply impossible

Rage Review : Dr. Gideon Greenspan is the founder and CEO of Coin Sciences. In his article, he discusses the current status, nature and classification of smart contracts. Through an in-depth analysis of the technology and the hype surrounding it, the author finally concluded that the ineffectiveness of smart contracts in many application cases is not because people have too high expectations, but because its essence is just a string of code. The operation of the system must also comply with the corresponding system procedures and rules.

Translation: Annie_Xu

Dr Gideon Greenspan is the founder and CEO of Coin Sciences, a company that supports the blockchain private chain platform MultiChain.

Dr Gideon Greenspan

In this article, Greenspan discusses blockchain smart contracts and the negative impact that high expectations may have on the technology’s adoption.

As a developer of a well-known blockchain platform, I am often asked whether MultiChain plans to have smart contracts like Ethereum. My answer has always been "no, or at least not yet".

But in this hyped blockchain space, where smart contracts are at the center, why do I keep saying no? The problem is that while we now know three important use cases for the permissioned Bitcoin blockchain (provenance, enterprise record keeping, microfinancing), we haven’t found an alternative to Ethereum smart contracts.

It’s not that people don’t already know what they want smart contracts to do, it’s that many of these ideas simply can’t be done. When smart people hear the term “smart contracts,” their imaginations run wild. They imagine autonomous, intelligent software that can take data around the world. Unfortunately, the reality of smart contracts is pretty boring.

A smart contract is a code on the blockchain that is activated by transactions on the blockchain and reads and writes data in its database. That’s all there is to a real blockchain.

A smart contract is just a fancy name for code that runs on a blockchain and interacts with the state of that blockchain. So what is that code? It can be Pascal, Python, PHP, Java, Fortran, C++. If a database is involved, its stored procedures are written in SQL with extensions.

All of the above programming languages ​​are fundamentally the same, and solve the same problems in the same way. Of course, they have their own pros and cons, and only a lunatic would write a website in C or a high-definition video in Ruby. But in principle, you can do whatever you want. It's just that you'll pay a high price in terms of convenience, performance, and even your hair.

Of course, the problem with smart contracts is not just that people have too high expectations, but that these expectations mislead people into wasting time and money on ideas that simply cannot be realized.

It seems that large companies have the resources to stretch the line from when executives stumble across a new technology to when they recognize its benefits and pitfalls. Perhaps our own experience can help shorten that process.

Over the past nine months, many new use cases for smart contracts have emerged; and we continue to discover that these applications are simply impossible to implement.

As a result, we can even summarize three common misconceptions about smart contracts. Of course, these misunderstandings are not because the technology is immature or the tools have not yet been developed.

Rather, it’s because they misunderstand the fundamental properties of the code that runs in a database in a decentralized manner.

1. Syndicate external services

The first use cases for smart contracts are usually to change their behavior based on some external event, for example, an agricultural insurance policy that pays a certain amount to the policyholder based on the amount of rainfall in a certain month.

The imagined process goes like this: the smart contract waits until the scheduled time, gets the weather report from the external service, and then takes appropriate action based on the data obtained.

It sounds simple, but it’s impossible to achieve. Why? Because blockchain is a consensus-based system; that is, smart contracts can only start running after every transaction and block is processed and every node reaches the same state.

Everything that happens on the blockchain must be deterministic so that there can be no disagreement. The moment two reputable nodes disagree on the state of the blockchain, the entire system becomes completely worthless.

Then, the smart contract is executed independently by each node on the chain, so if the smart contract obtains data from an external service, this data acquisition process is repeated and completed independently by each node. However, because this data comes from outside the blockchain, it cannot be guaranteed that each node will receive the same answer.

Perhaps these data sources will give different responses when receiving requests from different nodes, or simply become temporarily unavailable. In any case, the consensus is broken and the entire blockchain collapses.

So what is the solution? It’s actually quite simple. Instead of having a smart contract issue external data fetching instructions, one or more trusted parties (forecasters) conduct transactions that embed the required data into the blockchain. Every node has an identical copy of that data, so it can be used in smart contract calculations.

That is, the forecaster pushes the data into the blockchain instead of having the smart contract pull the data in.

And similar problems arise when smart contracts cause events in the outside world. For example, many people like the idea of ​​using a bank API to transfer funds, but if each node executes the blockchain code independently, who is going to get the bank API?

You might say that we can select a node to do this; but what if that node fails, whether intentional or not? If we select all nodes to complete the API acquisition, is each node trustworthy? How can we ensure the security of the API password? Moreover, do we want an API to be used frequently? Even worse, if the smart contract wants to know whether the API acquisition is successful, we will find that we are back to the embarrassing situation of over-reliance on external data.

Again, there is a simple solution. Smart contracts do not need to access external APIs, we use trusted services to monitor the blockchain state and then respond accordingly. For example, a bank can actively monitor the blockchain and then transfer funds corresponding to on-chain transactions. This will not pose a threat to the blockchain consensus because it is completely passive.

These two solutions can be summarized into the following conclusions.

First, interactions between the blockchain and the outside world require trusted services, which, while technically possible, could distort the goals of a decentralized system.

Second, the mechanisms used by these solutions are simple and direct examples of database reading and writing; the forecaster who provides external information simply writes the relevant information into the blockchain. The services in the real world that reflect the state of the blockchain only read the data of the blockchain. In other words, the interaction between the blockchain and the outside world is limited to regular database operations.

We will continue to discuss this issue later.

2. Execute on-chain payment

This proposal is one we often hear: using smart contracts to automatically execute coupon payments for so-called "smart bonds." That is, when appropriate, the smart contract code will automatically initiate payments, avoiding the complexity of manual procedures and ensuring the execution of the issuer.

Of course, in order to achieve the above functions, payment must be made with funds on the blockchain; otherwise, the smart contract cannot guarantee the completion of the payment.

Note that in this use case of a financial ledger that includes bonds and cash, the blockchain is just a database. So in the case of the coupon payment, we are talking about a database run that is automatically executed within a specified time.

While automation is technically possible, it is financially difficult. If the bond’s smart contract controls the funds used to pay the bond, those payments are guaranteed. This means that the issuer or anyone else cannot use the bonds. But if the funds are not controlled by the smart contract, the system cannot be guaranteed to make payments.

That is, smart bonds are either useless to issuers or useless to investors. This is an obvious outcome if you think about it casually.

From an investor's perspective, the whole point of a bond is its attractive rate of return, albeit with a certain risk of failure. For the issuer, the purpose of a bond is to finance a rewarding, but equally risky activity, such as building a factory. The issuer has no way of guaranteeing that the financing will be realized and that the investor will receive a return. It is not surprising that blockchain cannot resolve the link between risk and return.

3. Hide confidential data

As I’ve written before, the biggest challenge in deploying blockchain is its high level of transparency.

For example, if 10 companies jointly build a blockchain, and two of them conduct bilateral trade, the other eight companies can immediately see the relevant information. Although there are many ways to solve the problem, the simplicity and efficiency of a centralized database is unique. In which trusted managers have full control over information viewing channels.

Some people think that smart contracts can solve this problem, because first of all, each smart contract contains a small database that it can fully control. All reads and writes to this database are determined by the contract code, making it impossible for contracts to read data directly from each other (this close connection between data and code is called encapsulation, which is the basis of the popular object-oriented programming paradigm).

So, if one smart contract cannot access another’s data, can we still say that the blockchain confidentiality problem has been solved? Is there any point in discussing information hiding in smart contracts? Unfortunately, the answer is no.

Because even if one smart contract cannot read the data of another, the relevant data is still stored on each node of the blockchain. For each blockchain participant, they have full control over where the information is stored on the system disk or memory. There is nothing that can prevent them from reading the data in their own system unless they choose not to read it.

Hiding data in a smart contract is just as secure as hiding it in the HTML code of a web page. Of course, the average user cannot see the data because it is not displayed in their browser window. All they need to do is add a "view source code" option to their web browser (all browsers have this feature), and then the relevant information will be generally visible.

Likewise, a user who wants to view data hidden in a smart contract would need to modify its blockchain software to display the full state of the contract, and all confidentiality features would disappear.

Any decent programmer can do the above in an hour.

Uses of Smart Contracts

Since smart contracts can do so many things, some people may ask what its real purpose is. To answer this question, we need to go back to the basic principles of blockchain itself. In summary, blockchain allows databases to be directly and securely shared by groups that do not need mutual trust or a central administrator.

Blockchain supports the disintermediation of data, which can significantly reduce complexity and costs.

Transactions can modify any database, including changes to a database that must succeed or fail in their entirety. For example, in a financial ledger, a transaction that verifies that A has sufficient funds represents a payment from A to B, and then the funds taken from A's account are added to B's account.

These transactions in a regular database are created by a single trusted authority; in a blockchain-powered shared database, on the other hand, any blockchain user can create transactions. And because users do not fully trust each other, their database must contain specifications that restrict transactions.

For example, in a peer-to-peer financial ledger, each transaction must be fully funded; otherwise participants can allocate funds at will.

There are many ways to express these rules, but there are two main templates, Bitcoin and Ethereum. Bitcoin's approach can be called "transaction restrictions", which evaluates transactions based on the database entries deleted by the transaction and the entries created.

Financial ledger rules dictate that the total amount of funds in deleted entries must equal the amount of funds in created entries (assuming that modifications to existing entries are equivalent to deletions of entries and creation of new entries).

The second example is the smart contract from Ethereum, which stipulates that all modifications to the contract data must be executed by code (in the case of traditional databases, this can be called a stored execution process). To modify the contract data, blockchain users must submit requests to the code, which then decides whether and how to execute these requests.

For example, smart contracts on a financial ledger perform the same three tasks as managers of a centralized database: determine whether there are sufficient funds, subtract a certain amount from one account, and add that amount to another account.

Both of the above templates are valid and have their own advantages and disadvantages. In summary, Bitcoin-style transaction restrictions provide excellent performance and concurrency; while Ethereum-style smart contracts have good flexibility.

Then let’s go back to the question of the purpose of smart contracts at the beginning: smart contracts are used for application cases in the blockchain that cannot be executed due to transaction restrictions.

According to the standards of smart contract applications, it can be predicted that permissioned blockchains will have many application cases.

All the significant blockchain applications I know of can be accomplished with Bitcoin-style transactions, performing permissioning and general data storage; as well as asset creation, transfer, custody, trading, and cancellation. However, new use cases continue to emerge, and I would not be surprised if some seek to involve smart contracts. Or at least extend the Bitcoin paradigm.

Whatever the answer, it’s important to remember that smart contracts are just a way to constrain transactions in a database.

This is obviously useful, and necessary for secure database sharing; but smart contracts can’t do anything else, and they certainly can’t escape the scope of the database they reside in.