Daily Archives: 2017-08-15

Dumb Contracts and Smart Scripts

Published by:

The rise of Ethereum and other “Smart Contract” platforms like Waves or Neo was very confusing for Bitcoin maximalists. They missed out on huge gains, meanwhile new investors were (and still are) cashing in on the hype. With Rootstock around the corner, I want to explore what “Turing Complete Smart Contracts” actually achieve. Are there any applications or is it really all BS?

What is a smart contract?

Smart contracts were first proposed by Nick Szabo back in 1996. To be clear: this is before the Blockchain Era. He defined a smart contract as follows:

A smart contract is a set of promises, specified in digital form, including protocols within which the parties perform on these promises. (…) The basic idea of smart contracts is that many kinds of contractual clauses (…) can be embedded in the hardware and software we deal with, in such a way as to make breach of contract expensive (…) for the breacher.

So Szabo envisioned contracts that had some kind of self-execution that is costly to attack. Obviously, once blockchain came around, people tried to implement smart contracts that were self executing and costly to attack using this new tech. After all, reversing transactions on a blockchain is expensive (if PoW is used) and provide censorship resistant transactions which could guarantee the self-execution. Enter Ethereum et al. They promised us Turning completeness, which means that “anything can be coded”.

All these new Smart Contract platforms are promising the users a new decentralized world: it would become possible to write and execute “unstoppable code” which could result in all kinds of futuristic innovations, like “a decentralized uber“, “a decentralized Air BnB” or “a decentralized Darknet Market“. Or more in general: decentralized computing. Ethereum tries to become “the world computer”. You can check the official Ethereum video below for more claims on what the Ethereum tech is supposed to enable:

eth_world_computer(click on image to start video in a new tab)

ISSUE 1: Real world assets

But when reading Szabo’s article, it becomes apparent that he was aware of the fact that trusted people and notaries were needed to be able to connect real world assets and actions to the smart contract. You can’t force someone using blockchain to hand over his car through software. You can’t force someone using blockchain to build an certain app according to the agreed upon specifications through software. You can’t force your drug dealer using blockchain to send you the weed you’ve paid for. It’s just impossible. In these cases, an arbitrator is clearly needed. Both parties need to trust a 3rd party who will decide on the settlement of the contract in case the parties don’t agree.

In these cases, when real world assets or services are being exchanged for a digital currency, it’s clear that “smart contracts” can’t add a lot. The only thing they can do is provide the logic for some kind of joint account. In most cases, this will be a simple “2/3 multisig”: The buyer, seller and a trusted third party create a joint account. When the buyer received the goods, he signs the transaction. The seller will sign as well and the money will be sent. If the buyer doesn’t want to sign because -according to him- something is wrong with the product or service, the trusted third party can do arbitration and issue a (partial) refund if he deems this appropriate. If the seller can prove he did deliver as was agreed upon beforehand, the arbitrator can decide to bypass the buyer and send the money.

But wait… What are we doing here? Isn’t this possible on Bitcoin for several years? Yes! This means that this whole use case is possible on Bitcoin as well. In this regard, Ethereum and other “smart contract platforms” aren’t adding anything useful. No need for “Turing complete platforms” it seems.

ISSUE 2: Trusted nodes

And what about the running of  websites or platforms? No real world assets are used in these projects. For sure there is more to this than just monetary transactions, right? Well, let’s think this through… Say we want to run a website on the Ethereum World Computer. This would enable the website to be “unstoppable”. Governments can’t shut it down because, presumably, the whole network is executing the code for the website. This sounds pretty vague. What could this mean in practice? The creators of the website put their code on the blockchain and all nodes download the code to open the website. If every node needs to download every website, this will result in huge bandwidth and storage costs. This seems pretty inefficient. If you don’t need the website, why should you download all the code for it? Usually, a user just downloads the needed files from the website’s server and opens it in a browser. What “Turing complete smart platforms” try to do, is the other way around.

Ok, so let’s say only certain nodes download the website content, other nodes are pruning it. What we are getting now is some kind of distributed servers to which casual users can connect to access the website. The users themselves won’t run full nodes to connect to their own version of the website. But… what is the incentive to run a full node? You only get paid for executing code, not for storing and broadcasting huge amounts of data. Let’s say that somehow the Smart Contract platform manages to code up a contract that makes a user pay for each data request to the node. [Note that this also requires something called “sharding” because when only certain nodes can deliver the requested data, only these nodes can verify the validity of the smart contract.]How is the user certain that he gets the correct version of the website and not an outdated version or, even worse, a faked version? This can’t be solved unless the user verifies the data with the original service. So either the user blindly trusts the node he connects to, or…

he just connects to the original node that put the website on the blockchain. So we’re back where we started… It’s clearly more efficient to just connect to a central server that serves the website. If you want an unstoppable website, just run it as a hidden service on the Tor or I2P network. No huge bandwidth and storage costs for the network, no need to trust nodes, no need to pay for access, … People tend to forget that the internet is pretty decentralized by itself. If you run your own server, you are running your website in a decentralized manner. It’s however more efficient and reliable to use a hosting company for your website 😉

ISSUE 3: Oracles

This brings us to the concept of oracles. An oracle is basically a trusted service that provides data. It’s a less radical idea compared to the pruned nodes being used as website servers, as the sole purpose of an oracle is serving a specific data input for a smart contract. Imagine a binary option on the EURUSD exchange rate. You can bet that the EUR will drop below 1 USD by the end of the year. The smart contract handles everything. All the code is running on the blockchain: you deposit an amount in the contract address and when the contract detects that when a euro indeed became worth less than a dollar, the contract executes and you’ll get double your money back. If this doesn’t happen by the end of the year, you lost your bet.

This seems pretty straight forward and easy to code, right? One little problem though… Where does the contract gets the data feed needed to check the EURUSD exchange rate? That data isn’t on the blockchain. It’s external. You can use for example a free API like this one to track the exchange rate and code that into your “smart contract”. But there is still a (huge) problem though… what happens when the data feed craps out and accidentally displays 0 as the EURUSD exchange rate for a minute? The smart contract would be executed automatically. The transaction is valid and immutable. So the creator of the binary option lost his money due to a bug in the oracle. You can probably use different oracles to provide data and ignore outliers. For example you use 3 data feeds and the smart contract automatically ignores the one that’s the furthest from the average and recalculates the average based on the remaining 2 oracles. This seems to have fixed the issue. If there is an outlier, it won’t affect the data used in the smart contract. But the weakness is still there. What if it’s december 31 and you are about to lose 10 million USD because the EURUSD exchange rate still didn’t drop below 1 USD. You now have a very big incentive to bribe 2 of the 3 oracles to display 0.9 USD as exchange rate for a minute. You pay them both 1 million to do this. The result? You’ll win the bet and receive 20 million! Oracles can also create bets themselves and deliberately create bugs in their software to profit from them.

Clearly, blockchains doesn’t solve this oracle problem, it makes it worse. While a wrong data feed on the NADAQ can be fixed by rolling back some trades, smart contracts on a blockchain can’t be rolled back (unless you are friends with Vitalik Buterin). I hope you now understand why I’m very skeptical on this whole notion of trusted oracles. You can trust an oracle if the stakes are low. If an error happens you either lose a small amount of money. If you trust your counterparty you may even get your money back if he’s acting honestly. But I’m sure that large corporations dealing with big transactions won’t trust these oracles. They will require someone signing off on the transaction. Yeah indeed, we’re back at trusted third parties.

If you don’t trust the oracle, can’t we just use a simple multisig transactions to decide who won the bet? The implementation is very easy: you run a “Smart Script” on a server. This server uses the oracles as input to decide when to trigger an alert that is sent to the arbitrator. The arbitrator manually checks if the data is indeed correct and if that’s the case, he signs the multisig transaction. If the arbitrator confirms wrong data, you can sue him and get your money back. So the oracle has an incentive to act correctly. This system is also very efficient, as the blockchain doesn’t need to check every “smart contract”, it only needs to verify the validity of the multisig transaction. Everything else happens off chain. I won’t go into the “innovations” that pretend to be building “decentralized oracles”. I’m pretty sure those are gameable as well, but this is beyond the scope of this article.

ISSUE 4: Scaling

Still not convinced that there is no real use case for “unstoppable code”? I’ll provide another example which does not require trusted oracles. One can imagine a gambling “dapp” (decentralized app) where the previous block hash is used as random number generator. You can bet on the hash being even or odd. The owner funds the smart contract with a pool of money. The gambler sends money in advance to the smart contract and bets on “even”. If the hash is indeed even, he gets 1.98x his wager back. When it’s odd, he gets nothing, so the house edge is 1%. This can all be coded and executed automatically. There is no need for a website, all this can be done on the blockchain. Often you would provide a (centralized – lol) website as a GUI for the clients, but it’s not required. The problem is: all this gambling transaction data still needs to flow through the whole Ethereum network. Every node needs to check all the games started by the users.

In the past, Satoshidice used to operate in a similar manner on the Bitcoin Network. You could send transactions to fixed gambling addresses and if you’d won, the website would automatically send coins back. But… you needed to trust the website to actually act honestly. They could in theory take your coins and run. This is an advantage of Ethereum then! Wait wait wait, not so fast. Satoshidice USED to operated as an “on blockchain” service, but it doesn’t anymore. Any guess why? The answer is simple: congestion. All those little transactions needed to be stored and forwarded by all the nodes. When in the early days Bitcoin wasn’t used much, there was enough block space for these low value transactions. But currently the fees are so high that such a service isn’t possible anymore. Thus Satoshidice switched to a centralized model: you first deposit bitcoin at the website an then you can start gambling. When you’re done, you withdraw your coins. It’s way more efficient to do it this way compared to the decentralized model. Been there, done that. It was fun, but it’s not sustainable for the network health in the long run. So no, Ethereum also doesn’t add anything useful here. By the way, Etherdice is currently unavailable due to… network congestion. Need more proof? Check this article on Microsoft dealing with Ethereum: they won’t use the blockchain itself, they need a more scalable solution which is off chain.

ISSUE 5: Miner incentives

Going back to the previous example, there is a second issue besides scaling: the miners can manipulate the block hash. They can bet and then only publish blocks with the desired hash. Actually, that’s why Etherdice uses the external data (probably random.org)  for their source of randomness:

The only external dependency is a source of randomness, as the deterministic nature of blockchains make it difficult to come up with random data within the chain in a secure way.

So if even a simple small gambling “smart contract” can’t even rely on the blockchain, how will big companies ever use this tech to create important and complicated smart contracts?

Need another example? I heard this story from someone in the Ether mining community: during a popular ICO, “investors” compete against eachother to get their transactions in a block as soon as possible, to not mis out on the fantastic “investing oppurtunity”. Some miners are being paid through a side channel to get their transactions in the blockchain. These miners reject other transactions. Or miners just buy the whole ICO themselves and exclude other investors. So mining incentives can lead to miner censorship to gain financially.

Need another one? At the moment, a decentralized exchange isn’t implemented yet. But imagine for example a miner that is able to censor certain buy or sell orders on a decentralized exchange and front run it with his own transactions? He would be the first to dump a certain token and thus be able to exit before the price crashes. It’s all possible.

So imho, “smart contracts” are not safe on a blockchain. You will need an arbitrator and a “smart script” on an external server to do these kind of things in a reliable, scaleable and efficient way.

Bearer assets only

So what we are left with are “smart contracts” that only use on chain data and don’t rely on the randomness of the block hashes, nor rely on the sequence of execution. The data that resides inside a blockchain is very limited in scope: transaction data, block hashes and timestamps. That’s it. So these “smart contracts” are actually just “dumb contracts”. They can’t do anything useful.

At the moment, the only on chain value is cryptocurrency. It’s impossible to blockchainify real world assets, as those assets are not digital in nature. Cryptocurrency is a so called “bearer asset”. The value is the token itself. You don’t need to trust an external platform. When you transfer the token, you transfer the value. There is a way in which we can broaden the scope of smart contracts: create new bearer assets.

At the moment this happens at a very high rate: the number of ICO’s on Ethereum is staggering. These tokens are representing the value itself. For most of them, trust in an underlying platform is needed, as the token will receive future profits as dividend. But the token still holds the (expected) value and should reflect the trust in the platform and the chances of ever receiving the dividend. So yeah, ICO’s are indeed a natural application of smart contracts. One could create a platform that has a revenue stream and the profits are automatically distributed to the token holders, without interference of the developers. This is a potential use case of smart contracts, but it’ll probably suffer from the same inefficiencies as we saw with the satoshidice example. It can’t operate at scale. If the owners/developers of the platform are manually approving dividend payouts, there is no advantage for using a “Turing complete smart contract platform”. This can be done on Bitcoin as well through the Colored Coins protocol. No need for Ethereum. Also consider the potential legal risk for these ICO’s. Most of them will be shut down by regulation. The remaining ones will be shady “decentralized companies” (darknet markets) and investing in them may by itself be a risk.

There is also a more interesting type of bearer assets: cryptofiat. If governments ever decide to issue fiat on the blockchain, then the token can represent the value itself. In that case in theory more interesting smart contracts will become possible. If you are able to create a decentralized exchange you could, theoretically, have on chain exchange rate data, removing the need for oracles. But as we saw blockchains can’t safely implement on chain trading. And again,  blockchains are very inefficient and any large scale trading won’t be possible anyway. It all sounds nice, but it’s not possible in practice. And besides that, I don’t think governments will ever put fiat on a blockchain. They dislike bearer assets and prefer registered value for tax purposes.

Turing completeness is adding more risk than benefits

So in my opinion, blockchains aren’t really useful for smart contracts. The (very limited) added benefits are not worth it because we also need to consider the risks. The fact that the platform is Turing complete, makes it very hard to build secure applications. We’ve seen this with the DAO fiasco. I rather trust a solid blockchain that focuses on being money than trying to apply “smart contracts” on a blockchain with in most cases no benefit at all and substantially more risk.

So “smart contracts” are possible…

… but only in very specific circumstances. Scaling issues prevent widespread use. The only “smart contracts” that can function on a blockchain are contracts that are easy to compute, don’t require much storage and bandwidth and aren’t executed very often. So in practice, this can only apply to large transactions. It’s economically infeasible to execute a lot of small value transactions using smart contracts on a blockchain. If you still want to scale the number of transactions, you’ll need to use “smart scripts” running on an external server and settling periodically to the blockchain. The smart contract also comes with a risk if you use oracles, so you are better off using multisig on chain and a “smart script” on an external server. If you don’t want to use oracles, you are limited to bearer assets using only data that is on chain, resulting in “dumb contracts”.