How are banks actually going to use blockchains and smart contracts?

Banks are now officially collaborating on connected distributed ledgers, something of a milestone in the blockchain narrative. But how are they actually going to use computational blockchains that can operate that well-known term of art - "smart contracts"?

Dr Gideon Greenspan, founder of Coin Sciences and MultiChain, has a specific thesis about how an enterprise blockchain will look. It's a model based on a shared database design that can squeeze in as many desirable features without sacrificing performance and scalability. Greenspan is plotting a course, therefore, between a transaction constraint model (Bitcoin) which enables much greater concurrency and parallelism, and a smart contract or enforced stored procedure model (Ethereum), which can execute general purpose programs on a blockchain.

Regarding the recent R3 CEV announcement involving 11 of its member banks, Greenspan told IBTimes: "The R3 announcement is about a temporary experimental blockchain that was set up between some banks. From what I can see, it wasn't technically interesting but more of an organisational proof of concept, to show that they could get that many banks to work together on a single shared ledger.

"As the announcement says, the use of Ethereum was fairly incidental, and I think in the long run R3 will conclude (as we have) that for applications focused on asset transfer and exchange, a bitcoin-style architecture (in which assets sit inside transaction outputs that are directly spent) will perform better than an Ethereum-style architecture (in which assets are only moved by general-purpose code)."

Greenspan has proposed a "double-decker" blockchain approach made up of two tiers; a lower tier which would perform simple movements of assets including safe atomic exchanges (when two entities swap in a single operation some asset for some other asset so there is no way that one entity can end up out of pocket), without resorting to smart contracts. An upper tier would allow participants to choose what degree of programming complexity they want, by storing smart contract code within the metadata of lower tier transactions. This would not interfere with the performance of the lower layer and enable every node to run only the code it needs to.

Ockham's razor

Perhaps a principle of parsimony should be adhered to. Greenspan said that while many enterprise customers are experimenting with Ethereum, often in closed environments with firewalls around them, he has not encountered a lot of demand for smart contracts from MultiChain users. "From what I've seen so far, it seems that the strongest use cases for blockchains are the simple ones," he said. "First, transferring and exchanging digital representations of assets, whether financial or otherwise (a digital asset can also be used to track provenance). And second, using the blockchain to store raw unprocessed data, turning it into an immutable append-only file system."

"We haven't seen a lot of people wanting to execute complex computations at the lowest ledger level. I think the reason is that, in a private blockchain context where there's no cryptocurrency, there's not a lot of point to it. Even if you want a blockchain for trustless computation, all you need is for the data which defines that computation to be recorded immutably in the chain. The blockchain itself adds no value by understanding or performing the computations represented."

In a public blockchain like Ethereum with a native cryptocurrency which lives entirely on the chain, there is a point to having complex rules and computations regarding how that currency moves around; because there is a notion of pure on-blockchain ownership, said Greenspan.

"On a private chain with no cryptocurrencies, there is nothing that lives entirely on the chain. There is no asset whose existence is defined only by what's written on the chain. What you are actually transacting on the chain is a promise, for some recognised entity to give you something in exchange for that on-chain token.

"You don't need complex computation to move the asset around because you are not directly moving the asset anyway. All you are doing is changing what's written in the database. So as a result you don't need your database to support those complex operations, they can just be agreed on outside of the database. With a non-crypto asset, there is always a contract which defines the connection between what's written in the chain, and who has the legal right to own that asset. Since there's always that extra step, the contract can just as easily say 'ownership is defined by executing the code on the chain using such-and-such a language on such-and-such a system'. Anyone who wants to can dry run the contract to check its outcome, but there is no value in doing this on every node in the chain."

Smart bonds

Greenspan said he had an interesting online exchange with Ethereum's Vitalik Buterin about the point of blockchains executing complex computation, including in relation to smart bonds. "He [Buterin] suggested that computation in smart bonds is mainly for permissioning; to define detailed rules about who is allowed and not allowed to hold this bond. That's one feasible use of smart contracts, but any regular SQL database proves you can do sophisticated permissioning without a full computational layer. I think if the main use case of smart contracts is permissioning, it's like using a sledgehammer to crack a nut."

Greenspan pointed out that the intuitive idea of a smart bond is one which automatically pays out at given intervals. But what if the issuer of the bond does not have sufficient on-blockchain funds to pay the bond coupon on time? "It's not workable in practice,' he said. "There's absolutely nothing that a smart contract can do about a default. A smart contract can't seize real world assets and it can't take the bond issuer to court. All it can do is put up a red flag in the database which says that the payment is overdue.

"The only way that you could ensure that there are sufficient funds to pay the coupon would be for those funds to be locked under the control of the smart contract representing the bond. But if the funds are locked, then the issuer can't use them for anything else, so there's no point issuing the bond in the first place. Today when a company issues a bond it doesn't take the money that it receives and stick it in the bank - it pays a higher rate of interest precisely because it has something productive but somewhat risky to do with the money."

Ethereum

"I certainly wouldn't rule out computational blockchains in general in the finance sector," stated Greenspan. "I just think that if it's possible to implement a certain application on a more simple blockchain which has better performance characteristics, then people will probably do that."

Greenspan said banks are building many pilot projects and proofs of concept using blockchains, but in many cases these ideas fall down on a small detail. "I think the same thing will happen with smart contracts and Ethereum. Once people actually start building stuff they will often find that because of some small detail, as I mentioned in the smart bonds case, an idea is not practical.

"But I think smart contracts will definitely find some applications – where you want the extra bonus that Ethereum gives you, which is that every node is calculating all of this stuff in real time. If it's something for which performance isn't very important, then that is likely to make sense."

Sharding

For over a year Ethereum has been working on a solution for sharding a blockchain, enabling only subsets of transaction validators to process subsets of transactions in each time frame. Ethereum is presently capable of 25 transactions per second (TPS). Andrew Keys, director of enterprise business development at ConsenSys, the Ethereum development hub in New York, predicts the protocol will be able to handle many more TPS with Ethereum version 2.0 – levels comparable with the Visa and American Express networks.

Sharding means creating multiple isolated sub-environments within a single blockchain, so instead of having a single global state of the entire blockchain, where any message can trigger any contract which can update any database anywhere, you have got separate worlds. Within each of these separate worlds you can have lots of complex interactions, but one world cannot speak to another.

Greenspan said: "That would solve some of the problems. If the global 'state root' is removed from block headers, each node would only have to keep up with the state of those shards which are of interest to it. But it still wouldn't solve the overall problem which is that general purpose computation, even within one of these shards, does not lend itself well to some of the performance characteristics that we want from databases. And ultimately, despite all the hype and noise, a private blockchain is nothing more than a new type of shared database.

"If within one shard you are getting a lot of transactions which are moving things around, you still have this problem that you can't look at a transaction before it's been confirmed and have a high level of confidence about what it means. This is because its actual ordering in the blockchain, even within that shard, could make a very big difference.

"That's kind of a key issue because these are distributed asynchronous databases, which means that transactions are going to and fro and arriving at different nodes in different orders. The necessity of knowing the final order of the transactions before being able to predict their outcome is a downside of the entire Ethereum model, when compared to simpler bitcoin-style chains."

Netting

The integration of netting of securities settlements into blockchains is reputed to be one of the more complex problems facing a technology upgrade of this sort. It is unclear if transactions in digital securities would be recorded on blockchains on a gross or net basis, according to a recent Bloomberg report focusing on Overstock's T0 and the SEC.

Talking about using this technology to optimise post-trade settlement, Blythe Masters of Digital Asset Holdings said blockchains can provide virtuous sophistication because not all trades need to be settled instantaneously in real time; "optimised settlement speed" can allow a delay in some trades so these can be netted, reducing risk and liquidity requirements.

Greenspan states that, in many cases, blockchains could remove the need for netting altogether. He said the idea of having multiple outstanding liabilities between different parties, and then counting off some of these against each other in order to reduce the number of assets you have to move around, is not needed with the instant settlement that blockchains can provide.

"One of the reasons for netting is that multi-party financial liabilities are partially opaque, so netting helps everybody to understand their overall position with regard to everyone else. But opacity tends to be the opposite of what a blockchain does; a blockchain would let everyone see exactly what their position is, in real-time. So I think that overall, blockchains are more likely to reduce the need for netting rather than be a new solution for it."

Privacy

The transparency of the blockchain paradigm could be a double-edged sword. Some very smart people are working hard on the problem of privacy on blockchains, such as Blockstream with its Confidential Transactions feature, or the Enigma project at MIT and other zero-knowledge proof developers.

Greenspan said: "Even when that technical problem is solved, there is still a kind of emotional and psychological problem. The CIO of a big bank today knows that their confidential information is protected from their competitors by physical and organisational barriers. They know there are firewalls in place and the communication pipes don't go that way; they know the people that work for them have signed contracts which prevent them from leaking that info outside.

"That is how the world works today. Now you are talking about moving to a world where your confidential information is sitting on your competitors' hard disks but subject to very clever encryption. Even if it's all mathematically proven and all technically solid, I think CIOs might still have a gut resistance to moving to that world, to trusting cryptography rather than walls and contracts."

It might just turn out to be the case that regulators decide it's time to accept a new world where businesses can see what their competitors are doing, and everyone just has to deal with it.

Greenspan recounted an interesting story about the early days of CREST, the central securities depository for the UK which was at that time a huge IT project. Apparently a lot of the early participants of CREST were concerned about having a single place in which all of this transaction information would be collected. They thought it would be visible to certain service providers, whoever was providing the infrastructure or the communications lines, and this would undermine their confidentiality.

"It was a very big issue early on, and then people got used to it, and realised it wasn't really a problem," noted Greenspan. "Maybe something similar will happen with blockchains. All the participants in a chain will lose some of their sense of confidentiality. But because they are all in the same boat, overall it might notmake that much difference. As is often the case, people may realise that their confidential data isn't worth as much as they thought."