MultiChain

This compatibility makes MultiChain a promising candidate for our project, because most Bitcoin-compatible approaches will apply to MultiChain too. Additionally, “flexible creation and transaction of custom assets/tokens” is of particular interest for us and natively supported by MultiChain. It is also noteworthy that the project is developed in a very transparent way: questions posted to the official Q&A-section are answered quickly and competently.

Since MultiChain expects users to create their own blockchains for their specific use cases, there is no “official” public blockchain network which could have proven its stability and security. However, being a fork of the bitcoin code base, its fundamentals should be sound and it is very simple to setup a local chain for testing.

Setup

A typical MultiChain installation is made up of three executables:

• multichain-util is used exactly once to initialize a new blockchain
• multichaind runs a node to host the chain
• multichain-cli is the client to perform actions on the chain

Installation and usage are straightforward and well documented.

The chain is customized by editing a simple text file generated by multichain-util; this must be done before running multichaind for the first time because settings cannot be changed once the chain has been fully created.

The interactive Getting-Started guide is well-written and a good introduction for the setup, usage and network connection of the chain. Both basic (e.g. creating a wallet, sending funds) and advanced commands (e.g. creating an asset, managing permissions) are covered.

We have set up a small test network with an explorer and a wallet frontend.

Possible usage scenarios for the Content Blockchain Project

Federated management of content identifiers and metadata

Streams on MultiChain are publicly readable, append-only key-value databases on the blockchain whose items can reach “many megabytes in size”. Being append-only, an application can still extract older, “good” data from the stream if some user attempted to overwrite it maliciously. Despite being public, there are ways to store confidential data in a stream but they are a bit cumbersome to implement. A total stream size of multiple gigabytes is possible and the announced transaction rate of 500 tx/sec for insertion-transactions seems promising. By design, these numbers will only hold true in closed setups that do not depend on proof of work and use a permissions based round-robin consensus instead.

The registration of an ISCC on the chain could be implemented by creating a stream and passing the identifier string as custom field or name of the stream (max. 32 bytes), the latter handling the stream’s uniqueness natively. Unfortunately streams and assets seem to share a common namespace, which implies that names for streams must also be unique across asset names. Arbitrary data for that ISCC, e.g. on-chain plain-text or URLs to external resources, could then be published to the stream. One problem of this approach is that streams can be created as closed, which requires the stream’s creator to explicitly grant write-access for the stream to other users. This would enable malicious users to lock an ISCC. As of now (24.02.2017) it does not seem to be possible to allow only open streams on the chain. However, this issue might be addressable by requesting this as a feature or forking the project.

Alternatively, ISCCs could be stored as individual items of a stream (e.g. by using the ISCC as key). To avoid duplication and scattering of ISCCs, we could exclusively use the chain’s root stream for this, which would result in a single, huge stream. If single stream size poses a problem, multiple streams could be used to group ISCCs, for example by a common prefix. To ensure that these streams are open to everyone, stream-creation itself can be restricted to special wallet addresses by utilizing MultiChain’s consensus permission system. However, the specific protocol for this has to be well thought out, as it irrevocably introduces administrative members to the chain beyond its creation.

Flexible creation and transaction of custom assets/tokens

MultiChain allows the dynamic creation of native assets by anyone with appropriate permissions. These assets can be traded directly on the chain so that all nodes validate such transactions in the same way they would validate the chain’s native currency. Additionally, MultiChain allows atomic exchanges of arbitrary assets (including the default currency), so that different assets, whether they represent licenses, ratings or actual monetary value, can be safely and efficiently traded on the chain.

Support for custom blockchain application development (smart contracts)

MultiChain does currently not support the on-chain execution of Turing complete smart contracts like for example Ethereum does. However, smart contracts are a much discussed topic ^1, 2 and the MultiChain developers have not ruled out smart contracts completely, but they want to see “strong use cases” ³ which cannot be solvedusing a combination of multisignature transactions, client side logic and trusted third parties.

Remarks

During testing one thing became clear quite soon: Decentralized consensus based permissions management (if used at all) becomes a liability and a management challenge very fast. The fact that the percentage of administrators needed to approve changes is set in stone at the launch time of the chain would make it hard to accommodate for a growing community. While it is convenient that MultiChain is completely agnostic to what data is posted or stored in streams or metadata it also opens the door to spam streams with data that is invalid in the context of their intended use. A mechanism to bind validation of transaction data against a given schema to the consensus system would be helpful.

Result

The possibility to use MultiChain as a public, large and distributed data storage makes it a promising candidate for the ISCC database. In combination with tradable custom assets, conventional license trading, that is handing over a signed legal paper to a purchaser, could be moved onto this digital platform. The biggest remaining issue seems to be a sensible mining configuration to ensure the chain’s resistance against spam, censorship and centralization.