An update from the MultiChain factory floor
As a change from blog posts about blockchains in general, I’d like to provide an update on MultiChain, both in terms of recent enhancements and our roadmap for 2016.
First, I’d like to thank the many thousands of you who have downloaded and built on MultiChain, asked questions and sent us feedback. In the eight months since the first public release, our stats have shown consistent organic growth in traffic and downloads, and I hope this means we’re hitting the spot. Indeed, without naming names, we know that MultiChain has been successfully used for long-running blockchain pilots in some of the largest banks, consulting firms, financial technology and IT companies on the planet.
One question we’re often asked is why MultiChain has been in “alpha” for so long. The simple answer is that we’ve been bombarded with feature requests, most of which made sense to us, so we’ve been focused on adding these enhancements rather than bringing the product to beta. Having said that, you should find MultiChain to be very stable for alpha software, and we’ve tested it thoroughly under extreme loads.
I also want to explain how we’re positioning MultiChain in the broadening space of blockchain platforms. In the last six months, many competing products have been announced, (quasi-)consortia have been formed, companies have raised tens of millions of dollars, and just occasionally we’ve seen some real software releases. Of course, competition is natural and inevitable and we look forward to watching these other platforms develop. No doubt we’ll be borrowing their best ideas, and we assume they’ll return the compliment.
So where does MultiChain fit in with all this noise? In a nutshell, it’s focused on product and practicality:
- Stability. By forking from Bitcoin Core, the reference implementation for the bitcoin network, MultiChain builds on the years of hard-earned stability and security which come from stewarding billions of dollars in cryptocurrency value on the open Internet. To be clear, the Bitcoin Core codebase does have architectural limitations, and we may eventually have to move away from it. Nonetheless, for current user requirements, the cost of doing so would significantly outweigh the benefits.
- Ease of use. Many MultiChain users have told us that it’s far easier to use than competing blockchain platforms. I can’t even recall how many times I’ve told someone they can go from zero to their own private blockchain in minutes, and they just haven’t believed me. But it’s really true – just follow the instructions on the download and getting started pages and see for yourself. No dependencies, no compilation, no messing with Docker. Just three self-contained executables and a README file.
- Features. When MultiChain was first released, it had far fewer features than today. No per-address control of assets, no atomic exchange transactions, no easy transaction metadata. So how do we decide what to add? Simple – we listen to our users. Sometimes they know exactly what they want, like follow-on asset issuance, and we’re happy to oblige. Other times they know what they want to achieve, but don’t know how to express that as a feature, and it’s our job to work it out. Either way, MultiChain’s roadmap is driven relentlessly by user feedback, and so it will continue.
- Bitcoin compatibility. If you’re building a blockchain solution, you’ll find the node is just a small part of the picture. You may need mobile or web wallets, key management solutions and a library in some obscure language for decoding, signing and encoding transactions. MultiChain is designed to make all this as simple and fast as possible, by maintaining maximal compatibility with bitcoin, for which a huge amount of information, tools and code is freely available. To prove the point, MultiChain can even be configured as a node on the bitcoin network.
Basically, we aim to delight our users, and firmly believe this is the surest path to commercial success. On that note, I’d like to describe some of the new features added in the last few months.
Follow-on asset issuance (alpha 17)
This request has been around for a while, and is the most upvoted question on the Developer Q&A. So why did it take so long? You can blame us for being purists. You see, in terms of security, there’s no difference between (a) issuing a gazillion units of an asset the first time round and keeping most of them out of circulation, and (b) allowing follow-on issuances of more units of the same asset.
But it turns out that from our users’ perspective, there is quite a difference between the two cases, because it’s not so easy to differentiate units in active circulation from those sitting on the sidelines. So we’re pleased to announce that, in the version released today, when you issue an asset, you can decide whether that asset is open or closed. If it’s open, the original issuing party can create more units as many times as they like.
On the flip side, MultiChain also now provides a canonical ‘burn address’ for every chain. This address is full of X’s and so was obviously created without a corresponding private key (doing so would take an interminable amount of time). Any asset units sent to this address can therefore never be spent and are destroyed in a transparent fashion. Note that for your safety, the burn address has to be explicitly granted receive permissions before it can be used.
API calls: issue, issuefrom, issuemore, issuemorefrom, listassets, getinfo response’s burnaddress field.
MultiChain Explorer
Together with alpha 17, we’re releasing the first beta of the free and open source MultiChain Explorer. This provides an intuitive web-based view of the global state of a MultiChain blockchain, similar to the blockchain explorers that bitcoin users know and love. It lets you quickly and comfortably view transactions, blocks, assets and addresses, as well as the connections between them, all from the comfort of your favorite web browser.
The MultiChain Explorer was forked from the popular Abe project, written in Python and powered by SQLite. It connects to the API of a local MultiChain node and includes a self-contained web server so there are no additional dependencies. We hope you enjoy this tool and welcome your feedback to help us make it even better.
Interactive command mode (alpha 16)
As a fork of Bitcoin Core, MultiChain inherited the bitcoin-cli tool, which we appropriately renamed to multichain-cli of course. This tool provides a convenient command-line interface for MultiChain’s JSON-RPC API, allowing API calls to be sent from the system command line, with their responses displayed in the terminal. Behind the scenes it reads the API credentials from the appropriate chain’s configuration file, builds the JSON-RPC request and decodes its response.
As users of MultiChain ourselves, one frustration we had was that multichain-cli had to be run separately for every API request. Apart from the system overhead, this prevents the sort of fluid interaction that SQL databases provide. And so we fixed it. As of alpha 16, if you run multichain-cli [chain-name] with no command, you’re dropped into an interactive mode that lets you repeatedly type commands and see their response. Interactive mode supports standard editing features such as history (up and down arrows), jumping to the start (Ctrl A) or end (Ctrl E) of the line, and moving to the next (Ctrl →) and previous (Ctrl ←) word.
Faster signature verification (alpha 15)
When it comes to performance in bitcoin or MultiChain, the most crucial bottleneck is the verification of the ECDSA signatures on which the blockchain’s security model is built. The original Bitcoin Core software relied on an open source library called OpenSSL for signature generation and verification, which did the job, although it had some issues with malleability, meaning that more than one signature was valid for a given private key and payload.
Recent versions of Bitcoin Core introduced a new library for ECDSA signing and verification, called libsecp256k1. This library, written from scratch by world-class blockchain developers, removes the dependency on OpenSSL, resolves issues with malleability, and performs several times faster. One of the benefits of being derived from Bitcoin Core is that MultiChain can take advantage of these sorts of enhancements, which are extensively peer-reviewed and tested before being deployed in the bitcoin network. And so alpha 15 does exactly that with libsecp256k1.
Activate permission (alpha 14)
When developing the first version of MultiChain, we faced a dilemma in terms of permissioning. On the one hand, we’d have no problem concocting and implementing an extremely powerful permissions model, with multiple layers of administrators, per-asset permissions, and weighted voting schemes. On the other hand, we knew that these would add complexity from a user perspective, and wouldn’t necessarily match user needs. So we decided to start with a simple model, containing just six permission types (connect, send, receive, issue, mine, admin) and some straightforward consensus-based voting for the most important privilege changes. We expected this model to get more complex over time, but driven by user requirements rather than our own theories.
It turns out that, in this case, simple is actually pretty good. But one serious partner we’re working with needed something more. You see, a MultiChain address with admin privileges has the power to control all types of permissions on a blockchain, subject in some cases to consensus with other administrators. But this partner wanted to give an address the power to control others’ connect, send and receive permissions only, for the purposes of onboarding, and have no influence on more crucial processes such as mining and asset issuance. So we added a new ‘activate’ permission which does exactly this. This was also the first example of a partner paying to implement a feature they needed in the product, a win–win if ever there was one.
Wallet transaction APIs (alpha 13)
As a fork of Bitcoin Core, MultiChain inherited some of the bad along with the good. One of the weak spots in Bitcoin Core is the API for retrieving information about the transactions in the local node’s wallet. It offers two choices: (a) the getrawtransaction call which decodes the binary content of transactions, but doesn’t explain how they affected the local wallet, and (b) the gettransaction and listtransactions calls which aim to describe transactions from the wallet’s perspective, but do so in a confusing way, with multiple response elements per transaction. Making things worse, the output from these calls couldn’t be easily extended to work with MultiChain’s implementation of blockchain-issued assets.
So this release introduced a bunch of new APIs for querying a node’s transactions. The output from these calls retains all the useful fields from the ones they supersede. But they also add a bunch of new fields describing how each transaction affected the local wallet’s balance, which addresses it involved, how it modified permissions, and any metadata contained. Following the introduction (in alpha 8) of the ability to isolate the activity of each address in a wallet, the calls come in two versions – one pair which describes transactions from the perspective of the wallet as a whole, and another which describes them from the perspective of an individual wallet address.
API calls: listwallettransactions, getwallettransaction, listaddresstransactions, getaddresstransaction.
Looking ahead to 2016
Those are some of the major enhancements introduced in MultiChain during the last few months. Of course, many smaller features have been added as well, and they’re listed in full in the download’s README file. And our first priority will always be to fix bugs as soon as they appear. Thankfully the issues we’ve seen have never been of a serious architectural nature – the happy result of using Bitcoin Core as a starting point.
In terms of MultiChain itself, after a breakneck release schedule, we’re going to slow down a little. This is because we’re working on something big that will take a few months to finish. I’ll describe this feature in detail in a future blog post, but the basic idea is to provide a simple and efficient immutable recording and timestamping mechanism for any type of information, a kind of digital ‘tape’. Although transaction metadata in MultiChain can already be used for this purpose (in up to 8MB chunks), it’s not particularly convenient for storage or retrieval, and there are scalability issues when dealing with large pieces of data.
What’s motivating this feature? Your feedback, of course, which has taught us that general purpose immutable storage is a very common use case for blockchains. And if we ever see significant demand for “smart contracts” (i.e. on-blockchain computation) in MultiChain, this system can serve as the underlying storage layer, with computations performed per node, when required. As I’ve explained previously, there’s little value in requiring every node in a private blockchain to perform on-chain computations in real time.
And after that? Well no doubt there will be more enhancements to the free product, but we’re also going to start working on a premium version of MultiChain. As luck would have it, over the past 8 months we’ve seen a bunch of common feature requests which share the following characteristics:
- They’re important for real world deployments, but not for initial experimentation.
- They can be implemented on a per-node basis, without affecting a chain’s consensus.
- Real companies doing real projects seem more than happy to pay for them.
These features are related to performance, security, logging and analytics, and we’ll describe them in detail in the fullness of time. For now, I want to emphasize two key things about this premium version. First, it will be a drop-in replacement for the free version, so any code or applications you build on MultiChain today will continue to work unmodified. Second, every node in a blockchain will be able to independently decide whether to upgrade or not, because none of the premium features affect the blockchain’s consensus. This isn’t just us being kind-hearted – it’s crucial if we want MultiChain to continue to grow organically. A new entity will be able to connect and interact with an existing MultiChain network full of premium nodes, without spending a dime.
If you’re interested in discussing the premium version of MultiChain, please email premium@multichain.com or use this form. We’ll be happy to learn about your requirements and see how we can meet them.
One thing I’ve learnt in the past couple of years is that nobody takes software seriously until they can actually see and use it. A month before the first release of MultiChain, I was telling people about the product, and I noticed them politely nodding while obviously thinking “Oh save me, here’s another fast talker with a white paper and no working code.” But as soon as you make a product available, the response changes completely. So if you’re reading about this future premium version with a dose of skepticism, I understand and won’t hold it against you. All I can say is that, so far, MultiChain has a very solid record of delivering on its promises, and we look forward to continuing.
I also want to take this opportunity to thank our team for their outstanding work. Although I’m a serious coder by profession, these days I spend all my time writing content, managing product and talking to customers. I’m incredibly fortunate to know I can trust our developers to craft solid and efficient code, day after day, and I don’t take it for granted for a moment.
And finally, thanks to you for reading, and for being an early user of the MultiChain platform.