Per-asset permissions, capacity upgrading and inline metadata
Today we’re pleased to unveil the second preview release of MultiChain 2.0. This makes substantial progress on the MultiChain 2.0 roadmap, and includes an important extra feature relating to asset permissions.
Per-asset permissions
Let’s start with the surprise. This release adds the ability to separately control the send and receive permissions for each asset issued on the blockchain. This control is important in environments where each asset has different characteristics in terms of regulation, user identification requirements and so on.
At the time a new asset is issued, it can optionally be specified as receive- and/or send-restricted. Receive-restricted assets can only appear in transaction outputs whose address has receive permissions for that asset. Similarly, send-restricted assets can only be spent in transaction inputs by addresses which have per-asset send permissions. (Note that in all cases, addresses need global send and receive permissions to appear in inputs and outputs respectively.)
The send and receive permissions for an asset can be granted or revoked by any address which has admin or activate permissions for that asset. By default, these permissions are only assigned to the asset issuer, but the issuer (or any subsequently added asset administrator) can extend them to other addresses as well.
Blockchain parameter upgrades
One of the major features in development for MultiChain 2.0 is blockchain upgrading, to allow many of a chain’s parameters to be changed over time. This is vital because blockchains are designed to run for the long term, and it’s hard to predict how computer systems will be used many years after their creation.
MultiChain 1.0.x already provides a facility for upgrading a single parameter – the chain’s protocol version. This release of MultiChain 2.0 takes a significant step forwards, allowing changes to seven additional parameters related to blockchain performance and scaling. These include the target block time, maximum block size, maximum transaction size and maximum size of metadata.
As with other crucial operations relating to governance, upgrading a chain’s parameters can only be performed by the chain’s administrator(s), subject to a customizable level of consensus. We’re continuing to work on this feature, so look out for more upgradable parameters in future releases of MultiChain 2.0.
Inline metadata
MultiChain 1.0.x already supports unformatted (binary) transaction metadata, which can be embedded raw or wrapped in a stream item. The first preview release of MultiChain 2.0 extended this to allow metadata to be optionally represented in text or JSON format. In all of these cases the metadata appears in a separate transaction output containing an OP_RETURN, which makes the output unspendable by subsequent transactions.
This release of MultiChain 2.0 introduces a new type of metadata which we call “inline”. Inline metadata is stored within a regular spendable transaction output, and so is associated directly with that output’s address and/or assets. As with other forms of metadata, inline metadata can be in binary, text or JSON formats, and is easily writable and readable via a number of different APIs.
Inline metadata becomes truly powerful when used in conjunction with custom rules regarding transaction validity. One example is to send assets with an expiry date, or with a list of restrictions on where they can go next. In this release, custom validation rules can only be defined by modifying MultiChain’s C++ source code. However, once filters are implemented as part of the MultiChain 2.0 roadmap, these rules will be written in JavaScript and installed on a blockchain using regular API calls.
The road ahead
With this second preview/alpha release, we’ve completed about half of work scheduled for the open source Community edition of MultiChain 2.0. You can download and try out alpha 2 by visiting the MultiChain 2.0 preview releases page. On this page you’ll also find documentation for the new and enhanced APIs.
We’ve already started working on the next major feature for MultiChain 2.0, which we’re calling off-chain stream items. In an off-chain item, only a hash of the item’s payload is embedded inside the chain, alongside the item’s keys and some other metadata. The payload itself is stored locally by the publisher and propagated to the stream’s subscribers using peer-to-peer file sharing techniques, with the on-chain hash providing verification. The result is a huge improvement in the scalability and performance of blockchains used to record large amounts of information, where some of this information is only of interest to certain participants. While not originally planned for MultiChain 2.0, this feature rose up our list of priorities in response to user demand.
As always, we welcome your feedback on the progress of MultiChain 2.0, and look forward to delivering the next preview release in due course.
Please post any comments on LinkedIn.