Gideon Greenspan

It’s exactly two years since we published “Avoiding the pointless blockchain project“, a checklist of questions to ask when assessing permissioned blockchain use cases. The post obviously struck a nerve and continues to attract thousands of monthly readers on our site and others. People are still hungry for content that goes beyond the blockchain hype to assess this technology objectively.

Here at Coin Sciences, we’re best known for MultiChain, a popular platform for creating and deploying permissioned blockchains. But we began life in March 2014 in the cryptocurrency space, with the goal of developing a “bitcoin 2.0″ protocol called CoinSpark. CoinSpark leverages transaction metadata to add external assets (now called tokens) and notarized messaging to bitcoin. Our underlying thinking was this: If a blockchain is a secure decentralized record, surely that record has applications beyond managing its native cryptocurrency.

If you ask someone well-informed about the characteristics of blockchains, the word “immutable” will invariably appear in the response. In plain English, this word is used to denote something which can never be modified or changed.

We’re delighted to announce the first beta release of MultiChain 1.0 for Linux and Windows, after more than two years of intensive development. As we’ve said before, our definition is very specific: "beta" means that there are no known bugs or major shortcomings. So the purpose of the beta period is to ensure than any unknown issues are discovered through our own testing, as well as that of our growing user base.

About 18 months have passed since the finance sector woke up, en masse, to the possibilities of permissioned blockchains, or to use the more general term, “distributed ledgers”. The period since has seen a tsunami of activity, including research reports, strategic investments, pilot projects, and the formation of many consortia. No one can accuse the banking world of not taking the potential of this technology seriously.

Last Friday saw the launch of Zcash, a new public blockchain and associated cryptocurrency that attracted a lot of attention. By now, there are hundreds of cryptocurrencies, so any budding young entrant needs a serious differentiator to rise above the fray. In the case of Zcash, this is easy – Zcash users can send money to each other in absolute privacy.

Almost a year after first releasing MultiChain, we’ve learnt a huge amount about how blockchains, in a private and non-cryptocurrency sense, can and cannot be applied to real-world problems. Allow me to share what we know so far. To begin with, the first idea that we (and many others) started with, appears to be wrong. This idea, inspired by bitcoin directly, was that private blockchains (or “shared ledgers”) could be used to directly settle the majority of payment and exchange transactions in the finance sector, using on-chain tokens to represent cash, stocks, bonds and more.

Ethereum-like smart contracts are on the MultiChain roadmap. The answer I always give is: no, or at least not yet. But in the hype-filled world of blockchains, smart contracts are all the rage, so why ever not? Well, the problem is, while we now know of three strong use cases for permissioned Bitcoin-style blockchains (provenance, inter-company records and lightweight finance), we’re yet to find the equivalent for Ethereum-style smart contracts.

If you’ve been reading my previous posts, you will know by now that blockchains are simply a [new type of database](http://www.multichain.com/blog/2015/10/private-blockchains-shared-databases/). That is, a database which can be directly shared, in a write sense, by a group of non-trusting parties, without requiring a central administrator. This contrasts with traditional (SQL or NoSQL) databases that are controlled by a single entity, even if some kind of distributed architecture is used within its walls.

When it comes to using blockchains for inter-enterprise coordination, there’s an elephant-sized problem in the room. In my view, nobody’s talking about this issue enough, whether due to denial or the need to keep the hype going. The problem, in a nutshell, is **confidentiality**.