Original link：https://medium.com/@skloe/smart-contracts-e970a89f0695
Smart contracts are supposedly the next big thing applying blockchain technology, and start-ups in this area — notably Ethereum and Eris Industries have been repeatedly in the news recently. So what is this all about?
What are smart contracts?
From a user point of view, smart contracts can mostly be thought of as automated escrow accounts, ie objects that release and transfer funds if and when certain conditions are met. In their current manifestations they are implemented on top of a blockchain that also carries crypto currency units, which means that those fund transfers can easily be implemented with certainty.
From a technical point of view, smart contracts can be thought of as (web)servers, just that they are not located on the Internet using an IP address, but on a blockchain. It is possible to send messages to those contracts, and they in turn can send messages back (or to some other participants, or other contracts), determined by the code they are running, and their internal state that is persistent between calls.
Contrary to web servers — but in line with real-life contracts — smart contracts (ie their code, as well as their internal state) can be read by all participants (in fact, as both smart code and state are kept on the blockchain and — assuming this chain is publicly accessible — they are world-readable). Also, contrary to webservers, smart contracts do not reside on any particular hardware. In fact, their code will be executed on each and every machine that is mining blocks for the associated block chain (this also means that the computation power that can go into every single contract is somewhat limited, even though smart mining-difficulty adjustments could somewhat mitigate this effect).
Smart contracts are coded on the blockchain in bytecode, ie an assembler-like, platform-independent programming language. Whilst not impossible, humans will not usually write bytecode themselves, but it is compiled from higher level languages, notably from Solidity, a purpose-built language that is similar to Javascript. The bytecode (and the higher level languages) do provide hooks into the blockchain functionality, so that code can easily interact with it, eg to transfer crypto currency and to log events.
Code execution is atomic: either it succeeds, or all state changes are reversed (including those in the contracts that have been sending messages to or receiving messages from the failed contract in the current cycle. This is important because it allows to avoid situations where the contract has been only partially executed (eg think of a securities purchase where the ownership of the security has been transferred, but the associated transfer of crypto currency failed). This is particularly important in a blockchain environment because there is no easy way to undo the damage done by faulty execution (and possibly no way at all if the relevant counterparties do not cooperate).
Examples for smart contracts
Here a few examples what could be done with smart contracts:
Securities registrar and clearing house. The contract’s state can contains a representation of security ownership, either ADR-style, where it references a fixed pool of securities held in escrow in the real world, or as primary record of ownership. If the registered owner of a security notifies the contract that this security has been sold to another participant in exchange for a certain consideration, and the other participant sends the cryptocurrency corresponding to the consideration then the security register is updated and the currency is forwarded. Depending on which message arrives first, the security or the crypto cash will be kept in an escrow account to avoid double usage, probably with some timeout after which the transaction is cancelled and the escrow is cancelled.
Bank current account. Of course the blockchain itself already implements a crypto currency current account, so there is no need for smart contracts here. However, people living in the real world might want say a EUR or USD account which could be implemented just like the securities registrar account above, with the security being EUR or USD. With this contract here is a counterparty risk like with any bank in the real world. This risk could be mitigated by counterparty regulation, or removed if the real-world escrow is the central bank itself (which could ensure compliance with a contract of its own).
Derivatives, Betting. Provided the counterparties can agree on a data source that is accessible via the Internet they can contract arbitrary derivative contracts / bets on the value(s) of those data sources. For example, the contract could poll the Reuters closing rate of the USDEUR and settle a call option on this pair (it could either settle it directly in the crypto currency, or could be hooked up to a current account contract where it can effectively settle in EUR or USD).
Prepayments and recharges. A contract could be linked to a mobile SIM card, a prepaid electricity account, a prepaid card etc that is getting recharged whenever crypto currency is received.
Some issues with smart contracts
Smart contracts are in their infancy, and they are still not ready for prime time. A key issue is the issue of the degree of trust, which is similar to the one affecting the underlying blockchain implementations: those systems are designed for a zero trust environment, which means that some errors can not be rectified. For example, in the blockchain world, if you send currency to an address there is no way for you to reverse this operation. So if you are dealing with a fraudulent counterparty — or you have sent money to the wrong address — then this money is irretrievably lost.
Smart contracts can mitigate the issue of fraudulent counterparties — in fact, that was one of the reasons they have been designed: whenever the contract can reliably monitor execution of the parties’ duties under the contract (either externally, or because the contract itself is running the relevant ledger) then the parties can no longer cheat.
However, the issue has not gone away, but it is now at a different level: for example, the contract could have a bug that erroneously transfers the ownership of the securities but does not transfer the money (or, worse, transfers it to the wrong account). In the real world, those things can usually be easily undone because of the central authority implementing the system (and the courts, if necessary) but if you design a system to do away with those then you might be on your own if something happens.
Similarly, there is the issue of fraud: someone needs to design (=program) the contract and it is far from trivial to ensure absence of fraud when the contract is being designed. At the very least the parties must be assured that
the behaviour of the high level (eg Solidity) code adequately describes the intention of the parties to the contract
the bytecode in the code actually corresponds to the high level code that has been audited before entering into the contract
the message to the contract is well understood so that no “fat finger” errors occur (eg, people quote their rate the wrong way round — say USD/EUR instead of EUR/USD —leading to significant losses due to off-market execution)
Many of those issues could in principle be dealt with ex-post, through the courts if necessary, as is the case in the real-world system, but this would go against the fundamental “trustless” design principle of the proof-of-work driven block chain: it is questionable why one would want to rely on a proof-of-work system (whose underlying principle is to waste so much energy on the process of mining that it is uneconomic to attack it) rather than using a centrally run open ledger if ultimately one wants to rely on central authorities — the state, courts etc — to enforce contracts.
References
A tutorial on smart contracts and solidity (parts two, three) by Eris Industries
The Ethereum Wiki (section on contracts)
Blythe Masters’ keynote speech
Some thoughts on smart contracts and criminal use (here at MIT)
Eris’ announcement for open backend release