This article outlines the basic problem. If you want smart contracts that do anything off chain, there have to be connections to trusted services that provide information and take actions. If you have trusted services available, you may not need a blockchain.<p>The article points out that you can't construct an ordinary loan on chain, because you have no way to enforce paying it back short of tying up the loaned funds tor the duration of the loan. Useful credit fundamentally requires some way of making debtors pay up later. It's possible to construct various speculative financial products entirely on chain, and that's been done, but it's mostly useful for gambling, broadly defined.
I have been saying this for quite sometime on this forum - contracts have to deal with ambiguous circumstances and expressly contemplate being resolved in courts. Ambiguity of contracts is a <i>feature</i>, not a bug, as it is in the interest of <i>both</i> parties to be able to argue about certain unanticipated events when they occur.<p>Quoting my own comments from a while back:<p>> The vast majority of contracts do not have syntactically testable conditions. They just don't. Whether the conditions in a contract have been met is very often a matter of huge debate - this is what "law suits" are about. Unless you can create a condition that is testable by code, you cannot have a contract that self-enforces with the block chain. The conditions set forth in contracts are extremely complex and reasonable people can differ. I cannot imagine how you would have a contract be triggered on the insolvency of a privately held corporation - good luck defining insolvency and good luck getting access to the underlying books. Copyright infringement is also a preposterous idea - the amount of semantic judgment that must be made to determine if a work is infringing is enormous. Only the very simplest of conditions - comparing numbers, checking the time, can be reliably automated, and if you are getting a lawyer to write your contracts, odds are there is substantially more complexity in the agreements than this, which is why you hired the lawyer in the first place. In addition, a fair portion of contracts that can actually be set up to work this already are - and the blockchain is not necessary. They are things like credit cards and they work pretty good without the blockchain.
Even for things that smart contracts are capable of doing, the cost of doing them on a decentralised blockchain is often prohibitively expensive. For instace the Oraclize service, that does get external data into the contract, costs around $0.02, per API call. Which isn't much on its own, but they add up when compared to the number of API calls an average 'centralized' application makes.<p>I've often found that for quite a few applications, the cost of executing the contract on a blockchain outweigh the benefits of decentralisation.
This article is dated Apr 2016. "Oracles" seem to be the way now to inject external data. Oraclize[1] can apparently be provably kept trustable. Anyone with deeper knowledge of this?<p>[1] <a href="http://www.oraclize.it/" rel="nofollow">http://www.oraclize.it/</a>
It's one of the reasons why the use of the term contract is a misnomer and leads to awkward expectations as to what is possible.<p>Legally speaking, a contract is merely a promise enforceable in court.
The writer is lagging way behind bleeding edge blockchain research.<p>>1. Contacting external services
..Often, the first use case proposed is a smart contract that changes its behavior in response to some external event. For example, an agricultural insurance policy which pays out conditionally based on the quantity of rainfall in a given month.<p>The imagined process goes something like this: The smart contract waits until the predetermined time, retrieves the weather report from an external service and behaves appropriately based on the data received.<p>This all sounds simple enough, but it’s also impossible. Why? Because a blockchain is a consensus-based system, meaning that it only works if every node reaches an identical state after processing every transaction and block.<p>(see <a href="https://github.com/ethereum/wiki/wiki/Sharding-FAQ" rel="nofollow">https://github.com/ethereum/wiki/wiki/Sharding-FAQ</a>)<p>>3. Hiding confidential data
..Because even if one smart contract can’t read another’s data, that data is still stored on every single node in the chain. For each blockchain participant, it’s in the memory or disk of a system which that participant completely controls. And there’s nothing to stop them reading the information from their own system, if and when they choose to do so.<p>(see <a href="https://blog.ethereum.org/2017/01/19/update-integrating-zcash-ethereum/" rel="nofollow">https://blog.ethereum.org/2017/01/19/update-integrating-zcas...</a>)