Just because a repetitive job could be replaced with self-executing code on a blockchain, doesn’t mean it should be.
A group of Wall Street insiders and blockchain innovators took to the stage yesterday at the New York Law School in Manhattan to sort through when a smart contract is a bad idea, when it’s a good idea and what stands in the way of widespread proliferation of the technology.
“There are some looming grand challenges,” said Ari Juels, professor at Cornell Tech and co-director at the Initiative for CryptoCurrencies & Contracts (IC3).
Speaking on a panel about implementing legally sound, secure smart contracts, at an event hosted by the Wall Street Blockchain Alliance Juels broke down the key obstacles into two main categories.
First, he says there’s a pull within the industry toward confidentiality. While financial institutions and other players in the space hail the benefits of transparency, they hesitate to put their information on a blockchain.
Key directions Juels sees in the resolution of this apparent dichotomy are two technology solutions.
First, he listed software-based solutions run with zero-knowledge proofs like the zk-SNARK technology upon which Zcash was built. The technology allows counterparties to control how much information they share about themselves as well as who can see that information.
But he also listed a hardware solution. Specifically, Juels said Intel’s Software Guard Extensions will help strike the balance between confidentiality and transparency.
Intel’s Hyperledger contribution, Sawtooth Lake, is powered by a consensus algorithm called PoET (Proof of Elapsed Time), which is intended to run in a Trusted Execution Environment (TEE), including Intel SGX.
“Tools like zero-knowledge proof and SGX can let blockchain users have their cake and eat it too,” said Juels.
Ensuring accuracy
The other “looming challenge” facing smart contract development is accuracy.
According to Joshua Ashley Klayman, who serves as special counsel to the finance and projects group at Morrison Foerster, the problem can be articulated as such: “How do you make sure the code matches what you think is in the contract?”
While Juels argued for widespread use of bug bounties to find inaccuracies, and so-called escape hatches to prevent a contract from executing in certain circumstances, Klayman said the key to accuracy is simplicity.
“Typically, we tend to say the simpler the transaction the better,” said Klayman, who is also a founding member of the firm’s blockchain and smart contracts group. “The less discretion the better.”
But there is also an underlying trait of smart contracts that coincides with what Juels described as the need for accuracy. The smart contract must also be upgradable and interpretable. Juels calls this “enshrining ambiguity.”
‘Code is law’ debated
While one of the strengths of a smart contract is its incredible accuracy, that is also one of its weakness, Juels argued.
The extreme example of this is the “code is law” philosophy that there should be no natural language counterpart to a blockchain-based smart contract.
In the case of the first large-scale use of such smart contracts, The DAO was unable to fix its own code once it had launched because changing that code amounted to changing the terms the existing users had agreed to. The result was the slow draining of funds as the cryptocurrency community could do little more than watch until more drastic solutions were conceived.
Preston Byrne, COO and general counsel of Monax Industries and a long-time critic of certain implementations of smart contracts, described the “code is law” philosophy as “snazzy marketing nonsense” spouted by “non-lawyers”.
Havell Rodrigues, co-founder and CEO of Adjoint, explained how the next generation of smart contracts must give at least a modicum of access to the community using them.
Rodrigues said:
“You want to make sure that business users, legal users, can ask questions of the smart contract.”
Bad smart contract
The group of blockchain professionals also addressed what not to do when building smart contracts and what not to build.
As a general rule, smart contracts only bring value in proportion to how frequently they’re used. So, single use contracts and rarely used contracts aren’t likely valuable use cases, they said.
Also, a smart contract is only as valuable as the intermediaries it disrupts. Services that are already largely conducted directly between counterpartires are less likely to bring value to the builder.
But not every example of what not to do was based on design principles.
When asked directly by moderator Richard Johnson, of Greenwich Associates, what kinds of smart contracts are a bad idea, Juels said that “smart contracts actually present a lot of opportunities for crime”.
Specifically, he listed contracts that pay out automatically when an arson is committed and a person is killed as opportunities that shouldn’t be built.
Standard smart contracts
Along the path to widespread smart contract adoption more needs to be accomplished that just overcoming obstacles and avoiding wasted resources.
In a separate address the founder of Enterprise Data Management (EDM) Council Mike Meriton argued that smart contract standards currently being developed would be the final step towards widespread adoption.
Last week, Swift unveiled its own proof-of-concept built with Byrne’s Eris software and the Tendermint consensus engine designed in part to show how the ISO20022 standard might function on a blockchain.
Earlier this year, the Bankers Association of Finance and Trade (BAFT) made key hires to expand its own blockchain standards exploration. The following month the European branch of the International Securities Association for Institutional Trade Communication (ISITC) proposed 10 blockchain benchmarks.
While previous standards efforts appear to be focused on blockchain interoperabilty, Meriton says that, generally speaking, the EDM Council’s Financial Business Industry Ontology (FIBO) project has taken aim squarely at smart contracts.
The non-profit trade association with over 200 members is currently in advanced proof-of-concept phase with its FIBO standard which is registered with the Object Management Group. The FIBO standard is based on the actual language of a traditional contract and is designed to “stand up to heavy-duty processing requirements” of frequently transacted contracts across platforms.
“The objective for scaling blockchain is to leverage standards like ISO and FIBO,” said Meriton. “There’s tremendous potential.”
The EDM founder said he is currently in conversation with Digital Asset Holdings, Consensys and R3 and earlier this year conducted a test with Wells Fargo, State Street and Deutsche Bank. He expects a series of POC’s built on the standard to be released by the end of 2017.
Meriton concluded:
“We’re sort of having a coming out party with these capabilities as we speak.”
Mt Everest image via Shutterstock