Not-So-Smart Contracts

So-called “Smart Contracts” are a nightmare waiting to happen. Based on Bitcoin, Smart Contracts are essentially software-based legal contracts that programmatically execute financial transactions when certain conditions are met. For example, a smart contract could be written for a loan such that if borrower misses a payment, the lender could deduct the loan payment, as well as a hefty late fee, from the borrower’s account, automatically, with no recourse available. Interest rates could fluctuate literally with the weather (simply by tying the conditions of the Smart Contract to a weather API), or even be based on a random number. Connecting Smart Contracts to the even more dystopian “Internet of Things” means that if a person is thirty seconds late to work, they can be docked pay automatically, as soon as they walk in.

Smart Contracts have two major flaws. The first is that they couple personal finances, transactions, arbitration, and enforcement in one terrifying monolith. This means that instead of parties in dispute going to small claims court (arbitration), say, and seeking a judgment (enforcement) against the other, so that they can receive a payment (finances) from them, the Smart Contract combines all of these steps into one algorithm. The theory justifying this dangerous approach is that people are inherently untrustworthy, and presumably, that software is not. Ethereum, the most prominent organization developing Smart Contracts technology, brags that it “allows people to safely interact trustlessly”, and the original Bitcoin whitepaper talks about “the inherent weaknesses of the trust based model”, and calls for “cryptographic proof instead of trust”.

From this perspective, the second flaw is even worse. Ethereum uses an object-oriented language called Solidity to write Smart Contracts. From their documentation, “Solidity supports multiple inheritance by copying code including polymorphism.”.  Object-oriented programming has all sorts of complexity problems, but one of the worst is multiple inheritance.

Multiple inheritance is its own disaster waiting to happen: it introduces the possibility of something that Bob Martin calls the “deadly diamond of death” that creates ambiguities that are problematic in interface software, and potentially disastrous in financial applications.

Meanwhile, this is a “simple Smart Contract” from the Ethereum documentation (the word “simple” appears many times in this document):

pragma solidity ^0.4.0;

contract Coin {
    // The keyword "public" makes those variables
    // readable from outside.
    address public minter;
    mapping (address => uint) public balances;

    // Events allow light clients to react on
    // changes efficiently.
    event Sent(address from, address to, uint amount);

    // This is the constructor whose code is
    // run only when the contract is created.
    function Coin() {
        minter = msg.sender;
    }

    function mint(address receiver, uint amount) {
        if (msg.sender != minter) return;
        balances[receiver] += amount;
    }

    function send(address receiver, uint amount) {
        if (balances[msg.sender] < amount) return;
        balances[msg.sender] -= amount;
        balances[receiver] += amount;
        Sent(msg.sender, receiver, amount);
    }
}

Got it? Will your technolawyer get it? This is “the simplest form of a cryptocurrency” (their words). Here is another contract that I wrote, using inheritance:

contract my_mortgage is a_great_mortgage {}
contract a_great_mortgage is a_subprime_variable_interest_rate_mortgage_that_is_enforced_automatically_and_will_ruin_your_life {}

(Hint: read it out loud)

Imagine the worst legalese you’ve ever seen, and now imagine it as computer code, obfuscated by multiple inheritance, connected directly to your bank account, with no possibility of appeal in court, based on protections afforded by law, as that would presume a “trusted third party” for arbitration. Software inevitably has bugs, and I am not encouraged that the primary language for Smart Contracts will reduce their number. In fact, it is painfully easy to see much bad software being written with Solidity.  Ethereum argues that “one of the many advantages of having a robot run your organization is that it is immune to any outside influence as it’s guaranteed to execute only what it was programmed to.”  We are supposed to trust these “neutral” systems over each other.

The companies and institutions promoting Smart Contracts are nothing if not ambitious.  CoinPrism encourages you to “store your house on the Bitcoin blockchain” (I do not). What will this mean if you agree (voluntarily or otherwise) to a buggy and/or malicious contract that happens to have access to ownership of your house?  I don’t doubt the intentions of the authors of Solidity et al, but the road to hell is paved with good intentions. Perhaps the “trust-based model” needs to be reconsidered.

Advertisements


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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s