Who Will Pay for Turing-Complete Smart Contracts?
Chris DeRose is a journalist, software developer, bitcoin evangelist, public speaker and lead developer of Drop Zone.
In this feature, DeRose discusses blockchain-based smart contracts, and why he believes the cost-benefits of this application of the technology are not widely understood.
Lost in our 'pie-in-the-sky' projections on the future of blockchains is the most important concern anyone should have on the technology: What are the opportunity costs?
Nowhere is that more pronounced in the current debates then in the case of the "smart contract".
While I believe that smart contracts will provide a number of efficiencies in our blockchain future, there's one category of smart contracts that I'm most skeptical of – that of the recently popular "Turing complete" smart contract.
All smart contract platforms in use today fall into roughly two broad categories that are divided along the lines of whether the platform is or isn't "Turing complete." So what does this feature enable? Turing completeness is a property of any programming language that allows a computer to simulate anything that our universe contains.
If a language is Turing complete, it can provide all of the logic we've grown accustomed to in our computers. Turing completeness enables a computer to 'loop' and process its own output in iteratively complex terms. This property is absent in nearly all public blockchains. But with the modern advent of Ethereum, this feature is now available to aspiring blockchain coders.
Though this feature is the innovation that Ethereum has advertised as its competitive advantage, it's a trivial switch to flip 'on'. So, why wasn't this feature included in earlier blockchains?
Bitcoin implemented the world's first smart contract system, and intentionally switched this feature 'off'. Bitcoin supports a number of simple contract types ranging from "multisig", (the transfer of value given approval by a number of parties); "check timelock" (contracts which authorize the spending of value after an amount of time has passed); and a handful of simpler contracts which closely resemble the functions of a paper check in assigning value to a recipient.
With Turing completeness, the possibilities for programming smart contracts are only limited to the amount of creativity and processing time for which a contract designer is willing to pay.
So, what's the problem with giving users more options?
Well, off the bat, there's the size and processing costs that come with allowing users to store more data on the blockchain. With bitcoin, even one megabyte every 10 minutes is controversially large. And with Turing-complete blockchains like Ethereum, the size and processing issues are enormously more pronounced.
This overhead reduces the ability for small computers and nodes to run the blockchain with low energy and bandwidth. This also impacts any node operating in a remote location. Though such low-end overhead support may seem trivial in the context of the aspirations of large banking projects, it's important to recognize the effects of this trade-off when applied to the primary reason to use blockchains – servicing the underserved.
To understand why blockchains have found an efficiency in servicing the underserved, one must understand why users 'mine', or expend costs in order to secure and process transactions on a blockchain network.
In bitcoin, mining acts as an incentive to reward those who may benefit from the utility of the system. People mine because they wish to convert "registered" value, electricity registered in their name, into "anonymous" value that they can use to transact on the Internet.
They may want to do so due to local currency restrictions or to have better access to an easier way to spend money online.
But the costs to the one providing this service must be supported by a high number of users who want to actually use that service.
Whether such demand exists for a Turing-complete blockchain network remains to be seen. Thus far, this proposition would appear dubious.
Such subsidies would require that an inordinate amount of underserved users are currently looking for Turing completeness, and not building smart contracts because of the lack of this feature.
While there are certainly many users being denied access to basic contract services, the question remains whether the value of the difference in service can pay for the inordinately higher overhead they require.
Put simply, there needs to be a lot more of these users than have been found using just the bitcoin network itself.
To date, all Turing-complete miners today are only mining for the speculative value for ether, the native token on the Ethereum network, and to date no such underserved utility has been found – the proposition would seem extraordinary.
Another finicky proposition in Turing-complete smart contracts is that of the "oracle".
In a smart contract, data needs to enter the blockchain from an outside source in order to be of use. The source of this information – whether it be the price of a commodity, or the outcome of a sporting event, needs to be broadcast by individuals.
These individuals are called "oracles".
In non-Turing complete smart contract platforms, these oracles are to be found in "multisig" contracts, where one of the parties is the oracle, and the other two parties are the contract participants. In a "two-of-three" multisig operation, for instance, the oracle merely enters a winner onto the blockchain without additional code attached.
In a Turing-complete model, the parties themselves broadcast the code onto the blockchain well in advance, and let the nodes on the blockchain determine the outcome at the time an oracle broadcasts the event outcome 'data'.
So what's the difference? Well, in a Turing-complete model, a secondary contract can be broadcast alongside the primary contract for the sole purpose of 'corrupting' the oracle. This means that participants in the Turing-complete contract can not only engage in a contract, but can also bribe the oracle with impunity, and without repercussion.
This problem becomes more pronounced as more individuals stand to gain by engaging in the bribery attempt. Though it's still possible for oracles to be bribed the old-fashioned way in a non-Turing arrangement, the delivery of value isn't guaranteed, and the risk of corruption is significantly mitigated.
Yet another major issue with Turing completeness is, perhaps ironically, their transparency implications.
As part of the requirements to evaluate a Turing-complete contract, the code to that contract must be publicly available. In Turing-complete blockchains, this code is presented at the time that its participants engage in an agreement.
While transparency can often be an advantage to some value-transfer propositions, the problems associated with broadcasting everyone's position are fairly obvious. Most financial contracts require that information be asymmetrically held between the involved parties, so that uninvolved traders cannot trade advantageously on these agreements.
Should a major bank be found taking a position in the market (say a futures contract), the risk to that institution is that the market can publicly trade on, and determine the future of that bank before the contract has executed. Though there are some theoretical fixes to the problems of disclosure, these solutions will be a long time coming, and may never arrive at all.
Decentralization is rarely efficient, and is generally only an efficiency when individuals have exhausted all other options. The most successful blockchains will be found where the degree of decentralization occurs around the areas that match the regulatory arbitrage requirements they need, without any additional waste.
Thus far, evaluating code itself has yet to incur enough risk to justify the inordinate overhead and complexity needed to sustain this cost. Currently, most of the actors that need such services are finding that payment transfer alone entirely wraps the risk.
Offshore gambling institutions and blockchain users have been able to operate code on their websites with little fear of reprisal from countries friendly to their service. And it would be expected that for occurrences where the risk of default is impacting their ability to retain users, "check timelock" contracts will suffice.
Blockchains are an amazing tool for servicing those that the regulatory environment requires that they service.
However, as the hype cycle begins in this new phase of blockchain, it's important to remember that as we look back, the question of "Who needs Turing complete smart contracts?" may very well turn out to be "No one".
Follow Chris DeRose on Twitter.
Check image via Shutterstock
Disclaimer: The views expressed in this article are those of the author and do not necessarily represent the views of, and should not be attributed to, CoinDesk.
The 9 Mistakes I Made When Bringing Blockchain to My Startup
Why Many Smart Contract Use Cases Are Simply Impossible