5 Challenges Facing Your Smart Contract Project

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.

3 thoughts on “5 Challenges Facing Your Smart Contract Project

  1. > 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.
    This is probabilistically possible. E-Trade would have to set penalties based on probabilities and can reduce these likelihoods and costs by running miners (transaction processors) that work to process transactions faster.

    > it doesn’t matter how miners order the transactions in a block because the net result will be the same
    Order does matter in Bitcoin. If I have 5 BTC at an address and send two payment transactions simultaneously, one for 3 BTC and one for 4 BTC, only one of them will prevail, depending on order in which miners process them.

    > #4 Oracles break the trust model
    Some use cases require complete trust, some don’t. Oracles and other mechanisms will be very valuable for enabling many use cases.

    > #5 Public blockchains struggle to stay decentralized
    Any time systems create value, they become a target. Ethereum’s proof of stake direction is one good approach to maintaining decentralization on the platform. It will be VERY expensive to capture the majority of ETH.


  2. Thanks for your feedback.

    Oracles are interesting because if you trust an external entity to provide data, why not also trust them to perform computations, as some are suggesting with smart oracles? Conceptually then, we would be moving to a model which looks remarkably similar to calling a web API on a trusted server.

    With regards to the Bitcoin double spend scenario you mention, until the recent introduction of opt-in RBF, typically the first transaction seen in the mempool was deemed valid and the second one discarded. Regardless, it doesn’t stop a node processing all transactions as they arrive in the mempool to show pending net balances because most transactions are independent of one another.

    However, transaction order is much more critical for Turing-complete smart contracts because you don’t know what each contract will do to the global state – they could even psuedo-randomly (using deterministic blockchain data) generate an account address or contract address to use as part of its computation. So any processing of smart contracts before a mined block arrives are wasted cpu cycles since the results cannot be trusted to be consistent with that of other nodes.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s