From vending machines to sophisticated algorithms that have driven human beings off the trading floor of NASDAQ, business logic coded as software has been automating and revolutionizing the world around us, long before the materialization of virtual currencies. In essence, smart contracts are here to stay.
Blockchain has a substantial promise of application in executing contractual obligations and undeniably multiple organizations are exploring different use cases for smart contracts. Applying blockchain technology enables the production of smart contracts with full automation in determining and enforcing contractual obligations without the need for third parties.
Bitcoin’s growth and adoption is proof that smart contracts can work in a public environment. Bitcoin’s cryptographic primitives based on simple scripting language allow the currency itself to exist. It would be sensible then to expect Ethereum and its fully-fledged language—Turing-complete—to open up a whole world of new possibilities.
However, there are fundamental challenges facing smart contracts. And until these challenges are overcome, it is still premature to presuppose their capabilities in enforcing actual legal contracts that have been concluded by parties.
Hurdles Facing Smart Contracts
Below are at least five hurdles are facing smart contracts.
#1: There is no guarantee of transaction execution
Miners wrap transactions into blocks that are sent around the network for different nodes to confirm and run smart contracts. However, there is no contractual requirement that compels a miner to include the transaction in a block. You can attach a high fee with the transaction but it can still be disregarded by miners because of censorship, collusion, or just plain bad luck.
This means that some business models will not work. For instance, E-Trade provides a “2-second execution guarantee” which is not possible in bitcoin or Ethereum systems where transaction execution is based on game theory instead of service levels.
#2: Smart contracts are still slow
Bitcoin acts as a public ledger for keeping track of balances. The mathematical operation of addition is commutative (i.e., when crediting the balance, x+y=y+x, and when debiting the balance, x+ (-y) = (-y) +x)). Therefore, it does not matter how miners package their transactions in the block since the net result will always be the same.
There could be a dependency chain, but usually transactions will be isolated from one another to allow a node to process transactions immediately as they arrive instead of waiting for the mined block to be received.
However, things are quite different with the Ethereum smart contracts.
Consider a simple calculator that has a balance of 500.
If two incoming transactions tell the calculator to divide the balance by 100 and subtract 3, the result will be 2. However, if the order of transactions were to be reversed, the output will be 4.7. Because a Turing-complete smart contract can theoretically perform anything to the global state, smart contracts can only be executed in chronological order—parallel processing isn’t supported.
The net result is that a node in the Ethereum network must sit idle waiting for a new block to arrive and the exact order of transactions must be known. Otherwise, early processing will produce results that are inconsistent with that of the other nodes. With both Ethereum and bitcoin, if a computer is unable to finish its computations before the next block arrives, that computer will fall behind the rest of the network.
Ethereum’s target of new blocks arriving every 15 seconds is quite ambitious and can raise the risks of a node drowning in the backlog of work. And the trade-off is clear—smart contracts will yield slow Blockchains.
#3: Scaling is a hurdle
The Ethereum network has been referred to as a “world computer.” Yet its model where every node must execute every smart contract just doesn’t scale. This is the complete opposite of what the “world computer” should be. The launch of Cryptokitties and its impact on traffic has raised more controversies about the future of Ethereum protocol.
Decades of research into real-world grid computing and parallel processing teaches us that when there is a lot of work to be processed, it is best to divide it into small tasks which are then distributed amongst the network nodes. This isn’t the case with Ethereum smart contracts.
The Ethereum community is aware of this hurdle and one proposed solution is to shard the computations by namespace i.e. split the network into smaller networks. Other ideas that have been mooted include fee markets for off-chain computations. Bitcoin protocol faces similar scaling hurdles and ideas such as sidechains and lightning, if deployed, can effectively shard the network too.
However, it remains to be seen whether any of the proposed solutions can maintain the key selling points of a public blockchain—decentralized, trustless, and permissionless.
#4: Public blockchains are struggling to remain decentralized
In the recent past, centralization has been the blockchain’s burning issue. End users prefer to execute lightweight software that prunes transactions to focus on their own. The number of fully-validating computers has been declining and this presents a danger to the security model of the public blockchain.
Ethereum faces the same hurdles as it gains popularity and greater demands are placed on the network, proof of this already being seen in the proposal towards sharding of smart contract execution. So, here’s a question that we should ask ourselves: “If decentralization isn’t a fundamental obligation, why jump through the hoops when we can deploy smart contracts on private blockchains or conventional servers?”
#5: Oracles can break the trust model
The bitcoin protocol can operate as a pure trustless network because its primary function is to help move an internal token around a closed system. However, for smart contracts to be useful they have to execute computations using real-world data such as election results, stock prices, or football score.
Oracles—entities that provide this data—may not be trustworthy. In other words, can we trust oracles? And how will their reputation be determined? Who will record the potentially vast volumes of data to be used by an Oracle so that a particular node can replay the blockchain from the genesis block?
Public blockchains are so far transparent but are yet to provide the level of privacy that consumers and businesses are accustomed to with regard to enforcing contractual obligations. Human involvement is still required to settle the legal disputes that may arise. Centralized systems provide vastly superior performance in terms of response time.
The absence of a clear use case, compelling business advantage or even social benefits seems to be little reason to deploy an application into production based on smart contracts on a blockchain – a technology that is still in embryonic phase.
Featured image courtesy of Shutterstock.
Feedback or Requests?