As a developer of a popular blockchain platform, we are sometimes asked whether Ethereum-like smart contracts take the multi-link line. I always answer: No, at least not yet.
But smart contracts can be all the rage in the world of blockchain hype, why not before? So the problem is that although we now understand the three strong use cases for Bitcoin blockchain (source, inter-company records and lightweight financing), we have not yet found the equivalent of Ethereum smart contracts.
This is not to say that people lack the idea of using smart contracts. On the contrary, many of these ideas are simply impossible to realize. You see, when savvy people hear the word "smart contract", their imagination tends to run wild. They think of automated intelligent software to integrate into this world and use their data to make up for the excitement.
Unfortunately, the reality of smart contracts is far more secular than these:
A smart contract is actually a piece of code stored on a blockchain, triggered by a blockchain transaction.
It reads and writes data in the blockchain database. This is the smart contract. Really. A smart contract is just a string of code with a peculiar name that runs on the blockchain and interacts with the blockchain state model. What is code? The code can be Pascal, Python, or PHP. It is Java, Fortran, and C ++. If we are talking about a database, it is a stored procedure written in extended SQL. All these languages are basically equivalent, and they solve the same kind of problems of the same type. Of course, every language has its strengths and weaknesses-you must be crazy to build a website in C or compress HD video in Ruby. But at least in principle, you can, as long as you want. You just paid a heavy price for convenience and performance.
The problem with smart contracts is not just that people ’s expectations are exaggerated. It is those expectations that cause many people to spend time and money on ideas that are impossible to achieve. It seems that large companies must have sufficient resources to go through a long journey-from the moment when senior managers encounter a new technology and truly understand its advantages and limitations. Perhaps our own experience can help shorten this time.
In the past nine months, we have invested in many smart contract use cases and have found our own response, time and time again, that they simply cannot do it. Finally, we have identified the three most common misunderstandings of smart contracts. None of these ideas are wrong because the technology is immature or the tools are not yet available. Instead, they misunderstood only the basic nature of running code in a decentralized manner in a database.
Contact external service
Usually, the smart contract proposed in the first use case is to change its behavior in response to some external events. For example, in a given month, agricultural insurance policies are paid based on the amount of rainfall. The imaginary process is probably like this: the smart contract waits for a predetermined time, it will retrieve the weather forecast from the external service, and perform appropriate actions based on the received data.
All this sounds simple, but at the same time impossible. why? Since the blockchain is a consensus-based system, this means that it will only work if every node reaches the same state after processing a transaction. All of this can only exist if the blockchain must be completely determined, and there are no possible differences. When two honest nodes disagree with the state of this chain, the entire system will become worthless.
Recall now 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 by each node separately. However, since the information source is outside the blockchain, there is no guarantee that every node will receive the same answer. Perhaps the source of information will change the response time of its requests between different nodes, or it may become temporarily unavailable. Either way, once the consensus is broken, the entire blockchain system will be paralyzed.
So, is there any solution? In fact, it is very simple. Instead of a smart contract, the external data retrieval is initiated and the data in the transaction chain is embedded in the retrieval creation of one or more trusted parties ("databases"). Each node will have an exact copy of the data, so it can be safely used in a smart computing contract. In other words, pushing data from the database to the blockchain is much better than dragging data out of smart contracts.
Similar issues arise when smart contracts involve triggering external events. For example, many people like the idea of calling a bank API in a smart contract to complete a transfer. If each node executes the code in the chain independently, who is responsible for calling this program interface? If the answer is a certain node, what happens if that particular node fails, can you take it easy? If the answer is every node, can we trust the password of each node and the interface? Do we really want this program interface to be called hundreds of times? Even worse, if the smart contract needs to know whether the interface call is successful, we are back to the problem of relying on external data.
As before, there is a simple solution. Instead, smart contracts call external APIs, and we use a trusted server to monitor the status of the blockchain and respond to certain operations. For example, the bank may look forward to the blockchain, and implement fund transfers and reflect on-chain transactions. There is no risk to the consensus of the blockchain, because the chain plays a completely passive role.
Looking at these two solutions, we can make some comments. First, they all need a reliable entity to deal with the interaction between the blockchain and the outside world. Although this is technically possible, it destroys the goal of a decentralized system. Second, the mechanism of using read and write databases in these solutions is a straightforward example. The database that provides external information simply writes this information into the chain. This reflects that the state of the blockchain is nothing more than reading data from the chain in the real world. In other words, any interaction between a blockchain and the outside world is limited to regular database operations. We will discuss this in detail later.
Enforce payment on the chain
We often hear a lot about another suggestion: use a smart contract to automate the payment of coupons, so-called "smart bonds". The idea is to automatically start the payment code of the smart contract at the appropriate time, which not only avoids the manual process, but also protects the issuer from default.
Of course, for this work, the funds used for repayment must be circulated within the blockchain as well, otherwise the smart contract cannot guarantee payment. Now recall that the blockchain is a database. In this case, the financial ledger contains bonds issued and a portion of cash. Therefore, when we talk about coupon payment, it is actually a database operation that occurs automatically within the agreed time.
Although this automation is technically feasible, it has always been plagued by financial difficulties. If the funds used to pay the bonds are controlled by the bond's smart contract, then these payments can indeed be guaranteed. But it also means that these funds cannot be used by bond issuers for other purposes. If these funds are not under the control of the smart contract, then there is no way to guarantee that the payment can be guaranteed.
In other words, smart bonds are either meaningless issuers or meaningless investors. If you think about it, this is an obvious result. From the perspective of investors, the focus of bonds is their attractive rate of return, but there is a certain default risk cost. For issuers, the purpose of bonds is to use similar funds for production, but some activities are risky, such as building a new factory. Therefore, there is no way for bond issuers to raise funds while ensuring that investors can be repaid. This is not a surprise. The original relationship between risk and reward is not a problem that blockchain can solve.
Hide confidential data
As I have written before, the biggest challenge for effective use of blockchain is that it provides too thorough transparency. For example, if ten banks build a blockchain together and two of them conduct a two-way transaction, the transaction will be immediately visible to the other eight. Although there are various strategies to alleviate this problem, there is no central database that can beat simple and effective unless a reliable administrator has full control over who can see what.
Some people think that smart contracts can solve this problem. They put forward the argument that each smart contract contains its own micro-database, believing that it has full control. Since all read and write operations in the 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 foundation of the popular object-oriented programming paradigm.)
So, if a smart contract cannot access other data, can we solve the problem of blockchain confidentiality? Is it meaningful 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 each blockchain participant, it is possible to control the memory or disk of a system. If when they want to read information from their system, what can stop them?
Hiding web page data in a smart contract is as safe as hiding it in HTML code. Of course, the average Internet user will not see it because it is not displayed in their browser window. However, all of this requires a web browser to add the "view source" function (because they all have), and the hidden information becomes generally visible. Similarly, for the data hidden in the smart contract, all that is needed is for someone to modify their blockchain software to display the full status of the contract, and you can see the hidden illusion. As long as a similar programmer can spend an hour or so.
What is a smart contract?
With so many things that smart contracts can't do, someone may ask what they actually are. But to answer this question, we need to return to the foundation of our own blockchain. To recap briefly, blockchain allows databases to be shared directly and securely by entities that do not trust each other, without the need for central management. The blockchain achieves data intermediation and significantly reduces complexity and a lot of costs.
All databases are changed 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 the financial ledger, Alice makes a payment to Bob, then the transaction appears as: (1) Check whether Alice has sufficient funds; (2) Deduct a certain amount equal to the transaction amount from Alice's account; C) Add 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 driven by a blockchain, transactions can be created by users of any blockchain. Moreover, because these users do not fully trust each other, the database must contain rules restricting transactions. For example, in a financial ledger of a peer-to-peer network, each transaction must keep the total amount of funds unchanged, otherwise, users can freely draw as much money as possible because they all like it.
You can imagine various ways of expressing these rules, but now there are two dominant models, which are launched with Bitcoin and Ethereum. We can call Bitcoin's method "transaction limit", which is to evaluate each transaction in several ways: (a) delete the database entry of the transaction, and (b) create an entry. In a financial ledger, the rule states that the total amount of funds for deleted entries must match the total amount created. (We think the modification of an existing entry is equivalent to deleting the entry and creating a new one in its place.)
The second model comes from Ethereum, which is a smart contract. This means that all data of the modified contract must be executed by its code. (In the context of traditional databases, we can think of this as a mandatory stored procedure.) To modify contract data, blockchain users will send requests to their code to decide whether and how to satisfy these requests. In this example, as the administrator of the smart contract center database of a financial ledger, there are also three steps to be performed: check whether there is sufficient funds, deduct funds from one account, and add to another account.
Both models are effective, and each has its advantages and disadvantages, as I discussed in depth earlier. In summary, transaction restrictions in the form of Bitcoin provide superior performance and concurrency, while Ethereum-style smart contracts provide greater flexibility. Therefore, the question back to what smart contracts are: Smart contracts cannot be implemented with transaction restrictions for blockchain use cases.
Given the standard of smart contracts, I haven't seen it become a powerful use case in line with the authority of the blockchain. All the persuasive blockchain applications I know use bitcoin transactions, which can handle management permissions and general data storage, as well as asset creation, transfer, escrow, transaction, and elimination. Nevertheless, new use cases are still emerging. Even if someone needs the power of smart contracts, I would not be surprised. In other words, at least an extension of the Bitcoin model.
Regardless of the answer, the key thing to remember is that smart contracts are just a way to restrict transactions conducted in the database. This is undoubtedly a useful thing, and is the key to making the database safe to share. But smart contracts cannot do anything, and of course they cannot escape the boundaries of their database.
