The 3 most common misconceptions about smart contracts

As a developer of a popular blockchain platform, we are sometimes asked if smart contracts like Ethereum are going multichain. I always answer: no, at least not yet.

But if smart contracts are all the rage in the hype-filled world of blockchain, why not before? The problem is that while we now know three strong use cases for the Bitcoin blockchain (provenance, inter-company records, and lightweight financing), we have yet to find the equivalent for Ethereum smart contracts.

It’s not that people don’t have ideas for using smart contracts. On the contrary, many of these ideas are simply impossible to implement. You see, when smart people hear the word “smart contracts”, their imaginations tend to run wild. They think of automated intelligent software that can integrate into the world and use its data to make things happen.

Unfortunately the reality of smart contracts is far more mundane than this:

A smart contract is actually a piece of code stored on a blockchain and triggered by blockchain transactions.

It reads and writes data to the blockchain database. That's a smart contract. Really. A smart contract is just a piece of code with a fancy name that runs on the blockchain and interacts with the blockchain state model. What is code? Code can be Pascal, it can be Python, it can be PHP. It can be Java, it can be Fortran, it can be C++. If we're talking about databases, it's stored procedures written in extended SQL. All of these languages ​​are basically equivalent, solving the same kinds of problems. Of course, each language has its strengths and weaknesses - you'd have to be crazy to build a website in C or compress HD video in Ruby. But at least in principle, you can, if you want. You just pay a heavy price in convenience and performance.

The problem with smart contracts isn’t just that expectations are exaggerated. It’s that those expectations have led many people to waste time and money on ideas that are unlikely to work. It seems that large companies with sufficient resources have a long road ahead of them — the moment when senior executives encounter a new technology and truly understand its benefits and limitations. Perhaps our own experience can help shorten that time.

Over the past nine months, we’ve pitched a number of use cases for smart contracts and have found our own response, time and again, that they simply can’t be done. Ultimately, we’ve identified three of the most common misconceptions about smart contracts. None of these ideas are wrong because the technology is immature or the tools aren’t available yet. Instead, they simply misunderstand the fundamental nature of running code in a decentralized manner in a database.

Contact external services

Typically, the first use case proposed for a smart contract is one that changes its behavior in response to some external event. For example, an agricultural insurance policy that pays out based on the amount of rainfall in a given month. The imagined process would look something like this: the smart contract waits until a predetermined time, retrieves a weather forecast from an external service, and behaves appropriately based on the data received.

All this sounds simple, but impossible at the same time. Why? Since blockchain is a consensus-based system, which means that it will only work if every node reaches the same state after processing a transaction. All this can only exist if the blockchain must be completely deterministic and there is no possibility of any discrepancy. The moment there are two honest nodes that disagree on the state of the chain, the whole system becomes worthless.

Now recall that smart contracts are executed independently by each node on the chain. Therefore, if the smart contract retrieves some information from an external source, it will be retrieved repeatedly and executed separately by each node. However, since the source of the information is external to the blockchain, there is no guarantee that each node will receive the same answer. Perhaps the source of the information will change its response time between requests from different nodes, or it will become temporarily unavailable. Either way, once consensus is broken, the entire blockchain system will be paralyzed.

So, what’s the solution? Actually, it’s pretty simple. Instead of having a smart contract initiate an external data retrieval, one or more trusted parties (“databases”) create the retrieval embedded in the transaction chain. Each node will have an identical copy of the data, so it can be safely used in a smart computation contract. In other words, it’s much better for a database to push data to the blockchain than for a smart contract to pull it out.

Similar problems arise when smart contracts involve causing external events. For example, many people like the idea of ​​a smart contract that calls a bank API to complete a transfer. If each node is independently executing the code in the chain, who is responsible for calling this API? If the answer is a certain node, what happens if that specific node fails, can you still be calm? If the answer is every node, can we trust each node with the password to the API? Do we really want this API to be called hundreds of times? Even worse, if the smart contract needs to know whether the API call was successful, we are back to the problem of relying on external data.

As before, there is a simple solution. Instead of the smart contract calling an external API, we use a trusted server to monitor the state of the blockchain and perform certain actions in response. For example, a bank might proactively watch the blockchain and perform a fund transfer and reflect the transaction on the chain. This does not pose any risk to the blockchain consensus, as the chain plays a completely passive role.

Looking at these two solutions, we can make a few observations. First, they both require a trusted entity to handle the interaction between the blockchain and the outside world. While this is technically possible, it defeats the goal of a decentralized system. Second, the mechanisms used in these solutions to read and write to a database are examples of straightforward. The database that provides external information simply writes this information to the chain. This reflects the state of the blockchain and in the real world, all that is done is read data from the chain. In other words, any interaction between a blockchain and the outside world is limited to regular database operations. We will discuss this in more detail later.

Enforce on-chain payments

Another suggestion we tend to hear a lot about is using a smart contract to automate the payment of coupons, so-called “smart bonds.” The idea is to automatically trigger the payment code of the smart contract at the appropriate time, avoiding the manual process while ensuring that the issuer cannot default.

Of course, for this to work, the funds used to repay must be circulated within the blockchain, otherwise the smart contract cannot guarantee payment. Now recall that a blockchain is a database, in this case a financial ledger containing the issued bonds and a portion of cash. So when we talk about coupon payments, we are actually talking about database operations that occur automatically at an agreed time.

While this automation is technically feasible, it is plagued by financial difficulties. If the funds used to pay the bond are controlled by the bond's smart contract, then those payments are indeed guaranteed. But this also means that those funds cannot be used for other purposes by the bond issuer. If those funds are not under the control of the smart contract, then there is no way to guarantee that payments can be guaranteed.

In other words, smart bonds are either pointless issuers or pointless investors. This is a completely obvious outcome if you think about it. From an investor’s perspective, the point of a bond is that it has an attractive rate of return, but there is a certain cost of default risk. For the issuer, the purpose of a bond is to raise funds for production, but some activities are risky, such as building a new plant. So there is no way for a bond issuer to raise funds and guarantee that investors will be repaid. This is not surprising. The relationship between risk and return is not a problem that blockchain can solve.

Hiding confidential data

As I've written before, the biggest challenge to using blockchain effectively is the transparency it provides. For example, if ten banks come together to build a blockchain, and two of them conduct a two-way transaction, that transaction will be immediately visible to the other eight. While there are various strategies to mitigate this problem, none can beat the simplicity of a central database, unless there is a reliable administrator who has complete control over who can see what.

Some people think smart contracts can solve this problem. They make the argument that each smart contract contains its own miniature database, which it has complete control over. Since all reads and writes to this database are mediated by the contract code, the contract cannot directly read other data. (This tight coupling between data and code is called embedding, and is the basis of the popular object-oriented programming paradigm.)

So, if a smart contract cannot access other data, can we solve the problem of blockchain confidentiality? Does it make sense to discuss hiding information in smart contracts? Unfortunately, the answer is no. Because even if a smart contract cannot read other data, the data is still stored on every node in the chain. For every participant of the blockchain, it is completely possible to control the memory or disk of a system. If and when they want to read information from their own system, what can stop them?

Hiding web data in a smart contract is just as secure as hiding it in HTML code. Of course, the average web user won’t see it because it’s not displayed in their browser window. However, all it takes is for a web browser to add a “view source” feature (because they all have one), and the hidden information becomes universally visible. Likewise, for data hidden in a smart contract, all it takes is for someone to modify their blockchain software to display the full state of the contract, and the semblance of secrecy can be seen. It only takes a decent programmer an hour or so to do it.

What are smart contracts?

With so many things smart contracts can't do, one might ask what they actually are. But to answer that question, we need to go back to the basics of blockchain. To recap, blockchain enables databases to be shared directly and securely by entities that don't trust each other, without the need for central management. Blockchain decentralizes data and significantly reduces complexity and a lot of costs.

All databases are modified through "transaction data", which contains a set of changes to the database, but it must be changed as a whole, regardless of success or failure. For example, in a financial ledger, Alice pays Bob, then the transaction is represented by: (a) checking whether Alice has sufficient funds; (b) deducting an amount equal to the transaction amount from Alice's account; (c) adding an equal amount to Bob's account.

In a conventional centralized database, these transactions are created by a single trusted authority. In contrast, in a shared database powered by a blockchain, transactions can be created by any user of the blockchain. And, because these users don’t fully trust each other, the database must contain rules that restrict the transactions that can be made. For example, in a peer-to-peer financial ledger, each transaction must keep the total amount of funds constant, otherwise users can freely give themselves as much money as they like.

One can imagine various ways of expressing these rules, but there are two dominant models today, launched with Bitcoin and Ethereum respectively. Bitcoin’s approach, which we can call “transaction constraints,” is to evaluate each transaction on several counts: (a) the database entries deleted by that transaction, and (b) the entries created. In a financial ledger, this rule states that the total amount of funds for deleted entries must match the total amount created. (We consider the modification of an existing entry to be equivalent to deleting that entry and creating a new one in its place.)

The second model comes from Ethereum, namely smart contracts. This means that all data of a contract must be modified before its code can be executed. (In the context of traditional databases, we can think of this as a mandatory stored procedure.) To modify the contract data, blockchain users send requests to its code, which decides whether and how to satisfy these requests. In this example, as an administrator of a smart contract central database for a financial ledger, the same three steps need to be performed: check whether there are enough funds, deduct funds from one account, and add to another account.

Both models are valid, and each has its pros and cons, as I discussed in depth above. In summary, Bitcoin-style transaction limits offer superior performance and concurrency, while Ethereum-style smart contracts offer greater flexibility. So, back to the question of what smart contracts are: the use case for smart contracts for blockchain cannot be achieved with transaction limits.

Given the standard for smart contracts, I have yet to see them become a strong use case for permissioned blockchains. All compelling blockchain applications I know of use the Bitcoin transaction model, which handles administrative permissions and general data storage, as well as the creation, transfer, custody, trading, and elimination of assets. Still, new use cases are emerging. I wouldn't be surprised if someone needs the power of smart contracts. Or at least an extension of the Bitcoin model.

Whatever the answer, the key thing to remember is that smart contracts are simply a way to constrain transactions that can take place within a database. This is undoubtedly a useful thing, and is key to making that database safe to share. But smart contracts can’t do everything, and they certainly can’t escape the boundaries of the database they’re in.

Original text: http://www.multichain.com/blog/2016/04/beware-impossible-smart-contract/#userconsent#
By Gideon Greenspan
Translator: nous
Reward address: 14Gdmj8FuC4RsuuKiEgjNirLXQXbp35SgH
Editor: Kyle
Source (translation): Babbitt Information (http://www.8btc.com/beware-the-impossible-smart-contract)