From vending machines to complex algorithms which have driven humans off the trading floor of the New York Stock Exchange, business logic codified in software has been automating and transforming the world around us, long before the emergence of cryptocurrencies. In essence, smart contracts are already here.
The question now is can smart contracts operate outside a private system and free of central authority? If yes, what can decentralized smart contracts offer us which centralized logic cannot? Are new business models possible?
Bitcoin is proof that smart contracts can function in a public environment. Bitcoin’s simple scripting language based around cryptographic primitives enables the currency itself to exist. It would be quite reasonable then to expect Ethereum and its fully-fledged programming language (Turing-complete) to open up a world of possibilities.
However, I believe there are fundamental challenges facing smart contracts on public blockchains. Until these hurdles are overcome, don’t hold your breath waiting for Uber to be disintermediated (it’s more likely to happen the old fashioned way).
#1 No guarantee of transaction execution
Miners package transactions into blocks which are sent around the network for nodes to validate and execute smart contracts on. However, there is no contractual obligation that says a miner must include your transaction in a block. You could attach a high fee with your transaction but it might still be ignored by miners due to collusion, censorship or plain bad luck. This means some business models won’t work. For example, E-Trade offers a “2-second execution guarantee” which isn’t possible under Bitcoin or Ethereum where transaction execution is based upon game theory rather than service levels.
#2 Turing-complete smart contracts are slow
Bitcoin acts a ledger to keep track of balances. Since the mathematical operation of adding is commutative i.e. when crediting your balance, a+b=b+a, and when debiting your balance, a+(-b)=(-b)+a, it doesn’t matter how miners order the transactions in a block because the net result will be the same. There may be a dependency chain, but typically transactions are isolated from one another. This allows a node to process transactions as soon as they arrive (hence pending balances and zero confirmation transactions) rather than having to wait for a mined block to be received.
However, things are quite different with Ethereum. Consider a simple calculator with a balance of 50. If two incoming transactions tell the calculator to divide by 10 and subtract 3, the result is 2. However, if the order of transactions is reversed, the result is 4.7. Since a Turing-complete smart contract could theoretically do anything to the global state, contracts can only be executed in sequential order; parallel processing is not allowed. The result is that a node must sit idle until a new block arrives and the exact order of transactions is known, otherwise, early processing will yield results inconsistent with that of other nodes.
With both Bitcoin and Ethereum, if a node is unable to complete its computations before the next block arrives, the node will fall behind the rest of the network. Ethereum’s target of a new block arriving every 12 seconds is quite ambitious and raises the risk of a node drowning under a backlog of work. The trade-off is clear: smart contracts make slow blockchains.
#3 Scaling is a moonshot
Ethereum has been referred to as a world computer or planetary scale computer, yet the model where every node executes every smart contract simply doesn’t scale. It’s the complete opposite of what should be done. Decades of research into parallel processing and real-world grid computing teach us that when there’s a lot of work to be processed, it’s best divided into small jobs and distributed amongst network nodes.
The community are aware of this problem and one proposed solution is to shard computations by namespace i.e. divide the network into a bunch of smaller networks. Other ideas being mooted include a fee market for off-chain computations. Bitcoin faces similar scaling issues and ideas such as Sidechains and Lightning, if deployed, would effectively shard the network too.
It remains to be seen whether or not any of these solutions can preserve the key selling points of a public blockchain i.e. its trustless, permissionless and decentralized nature.
#4 Oracles break the trust model
Bitcoin can operate as a pure trustless network since its primary function is to move an internal token around a closed system.
However, for many smart contracts to be useful, they’re going to have to run computations using real-world data such as a stock price, election result or football score. The entities which provide this data are commonly referred to as Oracles, but can you trust them? How is reputation determined? Who records the potentially gargantuan volumes of data spewed by an Oracle so that a node can replay the blockchain from genesis?
Putting aside implementation details, there is also a broader question here, namely if we accept that a trustless network benefits from trusted nodes, where do we draw the line? How far down the rabbit hole do we go?
#5 Public blockchains struggle to stay decentralized
Centralization is the blockchain’s boiling frog problem. Today, 80% of Bitcoin’s network hashing power resides in one country. End users prefer to run lightweight software which prunes transactions to focus on their own. The number of fully-validating nodes has been declining which presents a danger to the security model of the blockchain. Ethereum faces the same issues as it gains popularity and greater demands are put on the network, evidence of this already being the move towards sharding of smart contract execution.
So here’s a question every project owner should ask themselves: if decentralization is not a fundamental requirement, why jump through hoops when you can deploy the system on a private blockchain or traditional server?
Your Next Big Project
Just as databases have stored procedures, intuitively it makes sense for a blockchain to have some mechanism for logic processing, but can smart contracts move beyond novel experiments and deliver when it really matters?
Public blockchains are by nature transparent and have yet to provide the level of privacy which consumers and businesses have grown accustomed to. Human intervention is still required to settle legal disputes. Centralized financial systems offer vastly superior performance (in fact, they’re so fast, there are calls to slow them down).
Absent a clear use-case, social benefit or compelling business advantage, there appears to be little reason to deploy a system into production using smart contracts on a public blockchain – technology which today is still in an embryonic stage – when more competitive and prudent approaches exist.