Dr. Lewin Boehnke, Head of Research, Crypto Finance Group
The term ‘smart contract’ was coined by Nick Szabo already in the 90s. In a series of blog posts he described self-enforcing contracts that require no judiciary body, as there is no space for interpretation in the application of the meaning of and the interpretation of the inputs to the contract. Examples are some financial products or automatic refusal of usage rights of e.g. a car based on delay an installment. The prime example though is a simple vending machine which, provided that any party interacting with it has the full possibility to audit every detail of the device, leaves no doubt over the result of an action. Coins put into the machine will, just by the mechanic of the machine and not by legal interpretation, yield the desired beverage.
This original meaning of a smart contract, notably defined over a decade before the invention of the first blockchain, is far removed from the understanding of a smart contract as we have it today. Today ‘smart contract’ is, in the widest meaning, used for any type of logic executed on a blockchain. Given some of the characteristics are still fulfilled.
A blockchain helps to execute code reliably and deterministically, with many different parties coming to a mutual understanding over the result of the execution. The drawback though is that in order to be used as inputs to the smart contract, information needs to be on the blockchain. And, the result can also only influence the state of information on the blockchain.
In order to make a smart contract execution dependent on real-world inputs, e.g. on a stock price, the outcome of an election, or the delay of a flight, this information needs to be put onto the blockchain. This requires either a party that takes up this tasks or complicated incentive structures to reach this goal in a decentralized way. As of today the latter, despite many attempts, is still an unsolved problem. The former requires trust in this party, which should not be taken for granted, especially if the value of derivatives on the blockchain becomes large.
In the other direction, in order to get turn results from a smart contract execution into real world events, it requires an enforcing party in this real world. Having a token in a smart contract that is meant to represent the ownership of e.g. a car is only faithfully executed if the holder of the token will actually receive the car in the real world. To whom can the new holder of the token complain if the previous owner of the car refuses to hand over the keys? Enforcement is a manual process for the time being. Automating this is subject to a lot of legal and technological challenges. The last big attempt at this was undertaken by Slock.it and (indirectly) led to a persistent fork in the Ethereum blockchain.
To make smart contracts practical for wider uses, both problems need to be solved, a blockchain-native approach will not suffice. This makes it an under-appreciated fact that Thompson Reuters launched data feeds onto blockchains, at least in beta states. The trustworthiness of the oracle will have a big impact on the scope of uses. The other problem is a bit harder though. Enforcement is reserved for state agencies, who might take on that role for uses with a sound legal basis. This poses a challenge for many tokenization projects or equity emitting ICOs that use the blockchain for regulatory arbitrage to circumvent tedious work (e.g. writing a proper prospectus for their offering) and legal burdens. Since tokenization projects—knowingly or not—have to rely on the legal system to become a valuable asset for their investors, a next generation of those projects will need to focus on taking the regulators and respective legal systems with them for the journey.