Making way for smart contracts

Blockchain and smart contracts in financial organizations are shifting from curious experiments to pragmatic pilot projects.

A few software products, including Ethereum, Digital Assets, Hyperledger, Multichain, Chain, and R3CEV, seem to have garnered larger interest in the banking space. While these are generic, there are more business-specific blockchain-smart contract vendors such as Itbit, Bankchain, Wave, and Clearmatics, built to serve such banking functions as clearing/settlement of trades and trade finance.

While new blockchain-smart contracts ideas keep coming up, there are still issues that must be ironed-out over the long journey ahead.

Let’s examine these issues, in software and non-software areas, and then some potential ways to help smart contracts become the norm sooner.

Software-based issues

• Privacy: Even in permissioned blockchain-smart contract use-cases, participating financial entities wouldn’t want data being visible to each other. While different theories and solutions have been proposed, there is still no established or proven one.

A few solutions (e.g. Zerocash, Enigma) propose using algorithms that would enable mining nodes to approve transactions without knowing details of the transaction. Other alternative solutions include having data reside or be visible only to the participants in the transaction, instead of everybody.

• Speed: In any blockchain-smart contract transaction there is replication and signature verification before a new block is added. This overhead will have an impact and will limit speed of transactions.

Tech startups like “Lightning” have proposed a solution where transactions happen off-the-chain. However, it’s a yet to be proven model.

• Data on the ledger: The blockchain data store has focused only on transaction data. Yet a comprehensive structure would have to support storage of static data (ranging from types of instruments to trade and member directories); have the ability to modify non-critical data; and facilitate reporting. Should this data be a part of the blockchain or maintained in a traditional data-store that is linked to the blockchain?

Non-software issues

• Mining responsibility: Mining in a private context doesn’t have to be intensive in a computational sense, but good incentive mechanisms need to be in place for trusted entities to perform this. The business viability of the mining role in a private scenario doesn’t seem very lucrative or sizeable.

• Centralization: There seems to be a “centralization” of responsibilities implied in the business models being discussed. The R3CEV’s Corda is a notable example.* Aren’t we centralizing on a new type of entity— a software technology vendor—instead of a service provider? Isn’t a key tenet of blockchain—that there be no central administrator—under question?

• Smart contract management: Some aspects require review— who writes the contract code; who executes it (A neutral venue? Nodes of participating entities? All of them?); fixing software bugs in contracts after it’s published; having trusted data sources for events; and so on.

Standardization

It’s important not to be over-dependent on a blockchain-smart contract vendor. It’s also essential to have an industrywide approach to common themes. Blockchain and smart contract technology requires standardization similar to how W3C manages HTML-5 and that all internet browsers comply with.

Some areas of potential standardization are:

• Message replication/exchange: If the exchange of messages between nodes and their rules of addition to the blockchain can be standardized, “blockchain node” development can flourish independently.

Blockchain vendors would then be able to interoperate, and there would be less need for all participants to use the same software provider. This concept is not new to the financial services industry.

• Code reflection: Smart contracts as a technology have to be usable to non-technical business/legal users. The ability to convert smart contracts programs to plain English and vice-versa can bridge this gap.

More than a decade ago Microsoft and Sun Microsystems introduced the concept of programs written in different languages (like C#, J#, and Visual Basic), producing the same machine language (intermediate language) and ability to reverse-engineer compiled code. If this can be extended to “code reflection” tools that can interpret smart contracts and make them readable in common English/native language, it will have a big impact.

• Program templates: There’s no point for every financial entity to draft their own smart contracts when most of the deal terms are similar to those the broader industry uses. It’s better if industry groups draft these tested, trustable, and re-usable programs and provide them to a wider community. Additional deal subtleties can be added separately. This will reduce the cost of smart contract preparation.

• Program execution: While there appear to be benefits in node (entity) storing a common copy of data, it doesn’t make sense in the same program, i.e. smart contracts being executed by every node at the same time.

In addition, re-usable/common code-modules could be serviced by cloud Software-As-A-Service [SaaS] providers. In a whitepaper, Microsoft has called this “Cryptlets.”

Where do we go from here?

While the future of blockchain-smart contracts looks promising and disruptive, there is still more to be done. The centralization of key governance tasks in a blockchain-smart contract network setup will continue to exist, though the role and cost of that will be reduced.

If standardization in protocol and features doesn’t happen soon, there is a risk of transferring the existing over-dependence on service providers like Visa to a software product company with little net gain. To make blockchain-smart contracts technology mainstream and enterprise-ready, providing tools is both important and lagging. (Those tools include easy-to-use administrative consoles, reporting modules, and developer toolkits.)

In the midst of this disruptive change, consider a quote by science fiction author Isaac Asimov: “The saddest aspect of life right now is that science gathers knowledge faster than society gathers wisdom.”

* From R3CEV’s blog regarding Corda: “Corda is a distributed ledger platform designed from the ground up to record, manage and synchronise financial agreements between regulated financial institutions. It is heavily inspired by and captures the benefits of blockchain systems, without the design choices that make blockchains inappropriate for many banking scenarios.”

About the author

Senthil Radhakrishnan is senior vice-president and head of the BFS Strategic Solutions Group at VirtusaPolaris. Blockchain is a major concentration for the firm and its work includes establishment of and development through its Blockchain Exploration Center.