Now available to view, review, compile and fork
Two years after starting to develop MultiChain, we’re delighted to release its source code under the GNU General Public License (GPLv3). The code, along with compilation instructions for Ubuntu, is now available at Github. You are free to browse and review it, compile it for yourself, or fork MultiChain in accordance with the GPL license.
Why now?
The code was originally scheduled for release with the first beta of MultiChain 1.0, but we decided to bring it forwards, as source code access has become crucial for many of our users and platform partners. Releasing the code allows enterprise users of MultiChain to perform independent security audits, and guarantees freedom of choice in the unlikely event that we stop developing the product.
So why did we wait so long? First, we needed to invest time in tidying up the code for public consumption, and preferred until recently to focus our efforts on pushing the product forwards. With the feature set for version 1.0 nearing completion, we could spare the distraction. Second, we didn’t want to be too helpful to some of our competitors who seemed rather desperate to see MultiChain’s code, judging by the (ahem) peculiar phone calls and email requests we’ve received. Now that the product is reasonably mature and well known, this is less of a concern.
Business models
If MultiChain is open source, how will we generate the revenue necessary to support its long-term development? To start with, we are already offering Service Level Agreements (SLAs) to customers who need guaranteed response and solution times for their questions and problems. Even though MultiChain is still officially in alpha, we already know of cases where it’s being used in production in the finance and government sectors.
In parallel to offering SLAs, we’ve started preparing the groundwork for a premium version of MultiChain, which will include extra features relating to security, scalability, analytics and performance. If you’re already working with the free version of MultiChain, there are two important things to know about the premium product. First, it will be possible to connect free and premium nodes in a single network, so each participant can independently decide which version to use. Second, any applications built on MultiChain today will work unmodified on the premium version – all APIs and parameters will remain backwards compatible.
Roadmap to 1.0 beta
In the meantime, we still have more to do before MultiChain 1.0 reaches beta. A full list can be found in the TODO file inside the source code repository, but here are some of the most important items:
- Add support for automatic “checkpoints” in a node, to permanently lock down changes in a blockchain’s governance model (admin and mining permissions).
- Allow control over the mining of empty blocks. This is useful for minimizing disk usage in blockchains with periods of low activity.
- Add a “mining turnover” parameter, which balances between (a) all permitted nodes mining blocks at random, and (b) round-robin mining which prevents forks but can still recover quickly if a mining node goes down.
- Finish the mechanism for notifying external processes of new transactions relating to a wallet address and/or subscribed stream/asset.
- Increase the maximum size of transaction metadata (whether raw or as part of a stream item) from the current limit of 8 MB to at least 32 MB (and hopefully more).
- Review and reduce the size of logs and other files whose primary purpose is to help with debugging.
- Complete the port of MultiChain to Mac OS.
The first three of these have already been implemented (see the development branch on Github). We’re hoping to complete the rest, along with smaller tweaks and changes, by the end of Q1 2017.
The beta phase
We define a “beta” version as “without known shortcomings”, i.e. when we’re not aware of a single bug or important unaddressed issue in the product. So the purpose of the beta phase, which will probably last 6 months or so, is to enable any hidden problems to be discovered through our user base and internal test suite, both of which continue to grow. No doubt we’ll also receive feature requests during this period, but we’ll only implement those which are very low risk in terms of product stability. Major new features will have to wait until MultiChain 1.1, 1.5 or 2.0, as appropriate.
However, one aspect of development will continue during the beta phase – performance optimization. MultiChain’s transaction throughput, which can reach 800 tx/sec under ideal conditions, is already more than enough for most blockchain applications. Nonetheless, some use cases require more, and there is no reason why MultiChain cannot reach thousands of tx/sec with the appropriate optimizations. Naturally, we won’t be making any significant architectural changes during the beta phase. Instead, we will focus on local optimizations, such as caching intermediate results.
Beyond 1.0 and Premium
Apart from the well-defined path to MultiChain 1.0 and its premium version, what’s the longer term roadmap for the MultiChain platform? How do we see the product developing over the next five to ten years?
I should start by clarifying that, as a technology, we don’t see blockchains as specific to banks or the finance sector. While platforms such as MultiChain can indeed be used to implement shared ledgers of financial assets, their applications go far wider. We view blockchains as a fundamentally new type of database, which can be directly shared between separate companies or organizations, without requiring a central intermediary. This ability to span trust boundaries sets blockchains apart from today’s common database platforms, whether they are of the SQL, NoSQL or NewSQL variety. Indeed, in the long term, we should probably call these “peer-to-peer databases” rather than “blockchains”, because a product’s purpose is more important than a description of its underlying technology.
Version 1.0 of MultiChain provides three high-level abstractions for peer-to-peer database application development: permissions (to control access and activity), assets (ownership tokens that are transferred or exchanged), and streams (general purpose data storage and retrieval). Over the coming years, we’ll be studying the strongest use cases for this new type of database, to see what else should be added to this list.
We already know of some obvious possibilities, such as virtual machines and zero-knowledge asset transactions. But the more interesting abstractions will probably be those that we can’t yet imagine. What is the blockchain equivalent of foreign keys in relational databases, map-reduce in big data stores, or the HyperLogLog of in-memory databases? As we continue developing MultiChain in conversation with our users and partners, we intend to find out.
Please post any comments on LinkedIn.