Blockchains - Smart Contracts - Part 2
By: Peter Chipkin
Article Contents
- Contracts and Legal Contracts
- A Use Case: Machine-to-Machine Commerce
- Over-Hyped - The Conceptual Flaws in Use cases / Application Ideas
- Contacting External Services Undermines the Purpose
- Enforcing on-Chain Payments Is Counter Productive
- Blockchains Cannot Hide Confidential Data
Because we are using the word 'contract' we must take care of terminology carefully. Contract has a specific legal meaning under law. Jurisdictions have rules of evidence for court cases.
Just because you block chain it doesn't mean a court will recognize the evidence of the security of the blockchain.
defined variously as "autonomous machines" , "contracts between parties stored on a blockchain" or "any computation that takes place on a blockchain" . Many debates about the nature of smart contracts are really just contests between competing terminology.
Smart contract" another definition - the use of code to articulate, verify, and enforce an agreement between parties. A smart legal contract.
These smart legal contracts would most likely be a combination of smart contract code and more traditional legal language. For instance, imagine a supplier of goods enters into a smart legal contract with a retailer. The payment terms could be defined in code and executed automatically when delivery is made . But the retailer would likely insist the contract include an indemnity clause, whereby the supplier agrees to indemnify the retailer against claims flowing from a defective product. There would be no point representing this clause in code, since it is not something that can self-execute – it exists to be interpreted and enforced by a court in the case of litigation.
The growing ecosystem of smart devices – particularly those that are in some fashion autonomous – will eventually need a way to engage in basic commercial interactions with one another. For instance, a washer that buys its own detergent or a car that can pay to recharge itself .
Smart alternative contracts might enable an entirely new type of commerce carried out between our computers, cars, phones, and appliances.
Over-Hyped - The Conceptual Flaws in Use Cases / Application Ideas
Contacting external services undermines the purpose
When a smart contract gets data/information from an external source, this is done repeatedly and separately by each node. But because this source is outside of the blockchain, there is no guarantee that every node will receive the same answer.
Everything that takes place on a blockchain must be completely deterministic, with no possible way for differences to creep in. The moment that two honest nodes disagree about the chain's state, the entire system becomes worthless.
Perhaps the source will change its response in the time between requests from different nodes, or perhaps it will become temporarily unavailable. Either way, consensus is broken and the entire blockchain dies.
There is a workaround. Instead of each instance of the smart contract retrieving the data individually, use a trusted service to embed the data in the chain. After that the contracts will be making reference to data embedded in the chain – thus it can be trusted but more importantly you can be use each contract instance uses the same data.
An oracle pushes the data onto the blockchain rather than a smart contract pulling it in.
The problem exists in the reverse direction as well. If a contract has to manipulate data in the world outside its chain then it will be making use of a apicall. If every node is independently executing the code in the chain, who is responsible for calling this API? One or all of the nodes ? If just one, what happens if there is an error. Does one trust every node with passwords ? The workaround solution is to have a trusted service which monitors the blockchain state and executes under certain conditions. But how do we know it executed correctly – we are back to the untrusted external data source again.
For example, a bank could proactively watch a blockchain and perform money transfers which mirror the on-chain transactions. This presents no risk to the blockchain's consensus because the chain plays an entirely passive role.
Two important considerations emerge
1. Trusted sternal entities are required – kinda defeats the point of the chain.
2. If you are using trusted services why use a blockchain.
Enforcing on-chain payments is counter productive
Here's another proposal that we tend to hear a lot: using a smart contract to automate the payment of coupons for a so-called "smart bond". The idea is for the smart contract code to automatically initiate the payments at the appropriate times, avoiding manual processes and guaranteeing that the issuer cannot default.
Here is the flaw. For the payment to be guaranteed not only must the funds be stored in the chain BUT they cannot be used for any other purpose until the contract is terminated or completed.
In other words, a smart bond is either pointless for the issuer, or pointless for the investor. And if you think about it, this is a completely obvious outcome.
From an investor's perspective, the whole point of a bond is its attractive rate of return, at the cost of some risk of default. And for the issuer, a bond's purpose is to raise funds for a productive but somewhat risky activity, such as building a new factory.
There is no way for the bond issuer to make use of the funds raised, while simultaneously guaranteeing that the investor will be repaid.
"The connection between risk and return is not a problem that blockchains can solve."
Blockchains cannot hide confidential data
Hiding data in a smart contract is about as secure as hiding it in the HTML code of a web page. Sure, regular web users won't see it, because it's not displayed in their browser window. But all it takes is for a web browser to add a 'View Source' function (as they all have), and the information becomes universally visible.
Similarly, for data hidden in smart contracts, all it takes is for someone to modify their blockchain software to display the contract's full state, and all semblance of secrecy is lost.
A half-decent programmer could do that in an hour or so.