MultiChain 1.0 released: Gideon Greenspan muses on blockchain privacy and smart contract languages

Blockchain platform MultiChain 1.0 has been released, and with it details of a wide-ranging partner programme.

MultiChain's partner programme, which includes the likes of Accenture, Cognizant and Medici Ventures, is split into platform partners who develop applications for third parties on the MultiChain platform, and product partners who are using MultiChain in their own proprietary solutions.

MultiChain is currently being used for three main classes of blockchain use case: lightweight financial systems, internal data security, and interorganisational record keeping or aggregation.

This categorisation is informed by founder Dr Gideon Greenspan's close analysis of the blockchain space, as well as continual feedback from MultiChain users (the release of MultiChain 1.0 was actually delayed to accommodate a long list of feature requests from users).

A governing factor in deciding how blockchains might best be deployed concerns the privacy of data transacted on them. Asked what he considers to be the best approach to privacy, Dr Greenspan said: "I think the strongest technology currently out there for privacy in blockchain asset transactions is zero knowledge proofs, as implemented in zk-SNARKs.

"These are designed to hide everything about a transaction: the entities, assets and quantities involved. That kind of combination isn't present in any of the other technologies which solve only part of the privacy problem."

Zero knowledge proofs, where the proofs themselves are visible to everybody but what's being proved is invisible, have a downside in terms of their computational burden, said Greenspan, but in the long run they look like the strongest candidate for a privacy technology to be integrated into MultiChain.

Adding layers of privacy is one approach; another is the modified version of a distributed ledger presented by R3 Corda, where data is only shared between parties that need to see it.

"The Corda architecture is interesting," said Greenspan. "Essentially it doesn't have a blockchain; there is no global picture that everybody sees in terms of data or transactions. Instead everyone sees just those pieces of information that their transactions depend upon.

"I think this approach goes some way to solving the privacy problem, although not completely. People are still seeing transactions that don't involve them, because their own transactions depend on others' past ones. But Corda is also working on leveraging Intel's secure computing environment to achieve something quite similar to zero knowledge proofs, using CPU hardware rather than cutting edge cryptography."

"What you lose with these techniques is this ability for all the participants to see the whole picture, and often you want them to have that picture - not just what they've got, but what other people have, and what else is going on in the blockchain.

"But overall I think Corda is a well designed architecture which suits a certain set of heavyweight financial use cases very well."

Asked if he saw any future collaboration between R3 and MultiChain, Greenspan said there could be a possible integration point with the Corda architecture's notion of notary services. This is a kind of pluggable interface where you can choose how the spending of unspent transaction outputs are notarised and who notarises them, in order to prevent a double spending. "You can have all sorts of systems to provide that notification and it would certainly be possible to provide a notary services solution based on MultiChain."

Taking a step back, Greenspan said that table-thumping conversations around blockchain architectures reflect the immaturity of the space. "If you look at other complicated software tools, for example in the database space, there are tons of trade-offs between different platforms; each design decision gives you certain things, and takes away others.

"One classic trade-off is between relational and non-relational databases. You get advanced indexing and querying for free in relational databases, but you lose scalability for dealing with really large data sets.

"So it's just the same with different types of blockchain for different sets of use cases. I think the decision for which blockchain to use for a particular use case should be made on technical rather than tribal considerations, on how well that particular blockchain architecture suits what you want to achieve."

Crypto news is the gift that just keeps giving: a typical week might include the SEC stepping on ICOs, Bitcoin forking or Ethereum being hacked. Greenspan said the recent Parity bug plays a little to the strengths of MultiChain, which is not a smart contracting platform, focusing instead on more straightforward types of transactions.

"The Parity bug underlines the danger of taking some code written by a human being, however talented, and trying to make that code unchangeable and immutable," he said. "People make mistakes when programming, and many of those mistakes are only discovered once a program is in use – sadly that's just a fact of computing life."

In the long term methodologies and stronger tools will be developed to solve this for Ethereum, while in the meantime new types of blockchain such as Tezos are in the offing, defined around formally verifiable code rather than general purpose code.

"One of the ideas behind the Tezos architecture is that it's going to provide a much more restrictive programming model for writing smart contracts. So the behaviour will be more predictable and more easily formally analysed."

Ethereum smart contracts are often beset by a variety of uncertainties such as re-entrancy bugs, where a piece of code runs fine unless it calls some other piece of code, which then unexpectedly calls back into it.

"Reentrancy is a common thing to worry about when you are writing software; you need to decide whether a piece of code is reentrant or not. Reentrancy can create all sorts of unpredictable behaviour if you don't think about it deeply and formally."

Providing a more restrictive programming language and more restrictive paradigms can prevent these types of problems, for example by forcing the programmer to declare whether or not a function can be re-entered or not.

"Building a great smart contracting platform is about designing a language where security is the number one consideration," noted Greenspan. "For now with Ethereum, the languages that people use are pretty close to JavaScript or Python, which are very easy for programmers to work with, but don't lead naturally to thinking about all these security issues and preventing them from happening."