InterchainZ Project Learning


Early in the InterChainZ project it became apparent that the further discussion moved away from Bitcoins and blockchains, the easier conversations became. Bitcoins and blockchains were burdened with too much baggage. Terminology is evolving rapidly, hence the team’s focus on “mutual distributed ledgers” as the term of choice. Further, the team emphasised the ‘boring’ nature of MDLs, and that “boring is brilliant”. The technical focus might be on boring ‘ledgers’, but the excitement is in the applications above.


It also became clear that ‘identity’ issues are universal. One of the great advantages of doing consortium research was that the identity chains were both ‘use cases’ and essential infrastructure that would have had to be built for anything else of substance. Distinguishing ‘identity’ from ‘transactions’ and ‘content’ made processing and distribution sense, at the expense of a bit more complexity in comprehension. While InterChainZ showed that MDLs can work together, and the project explored many different architecture possibilities, what was explored is certainly only a small portion of what is possible. One business area that could use more exploration is whether an MDL system is best as one MDL per entity (person, corporate) interacting with many transaction or content MDLs, or a set of big MDLs (identity, transaction, content) for a process such as anti-money-laundering, leading to identity information replication on different processes.

Validation Choices

Different business uses probably require different node structures. For example, the Master node architecture would be appropriate where a regulator is confirming all transactions in a market as being from valid market participants. The Supervisor node architecture might suit a small group of large organisations interacting with multiple smaller ones. While Bitcoin blockchain’s ‘proof-of-work’ validation approach is fascinating, one of the basic premises for InterChainZ was to focus on exploring “non-blockchain consensus or identity” MDLs, i.e. what benefits could be achieved when not using currencies or tokens. This decision provoked some external criticism, principally questioning whether there were benefits to MDLs without proof-of-work validation mechanisms.

Richard Gendal Brown has produced a categorisation that starts to make sense of “truthful records” versus “how things are agreed”. His diagram shows that there are a number of useful areas where different structures might apply:

Richard Gendal Brown Model

Richard Gendal Brown; “A Simple Model To Make Sense Of The Proliferation Of Distributed Ledger, Smart Contract And Cryptocurrency Projects” (19 December 2014)

The research partners, including the Alderney regulatory observer, contend that regulators are present in most financial markets. Thus, where regulators are prepared to co-stamp transactions, or support co-stampers who provided some trusted third party elements, tokens are unnecessary. There is evidence of regulatory interest. From 9 July 2015 to 8 August 2015, the States of Jersey held a consultation on “Regulation of Virtual Currency”. That consultation considered “whether there is a case for adopting a standard for distributed ledger technology and the possibility of potential future pan-Channel Island work in this area”. In more detail, “whether regulation of the underlying ‘distributed ledger’ technology would be advantageous in providing confidence to the marketplace that the Channel Islands are suitable jurisdictions in which to conduct ‘distributed ledger’ technology based business. A standard might involve registration, inspection, certification and periodical checking of the underlying ‘distributed ledger’ technology system sitting behind any particular business that would use, develop or provide ‘distributed ledger’ technology”. (“States of Jersey, Consultation – Regulation of Virtual Currency”; Part 7: “Distributed Ledger Technology Standard”, July 2015)

Nick Williamson and others have introduced a terminology distinguishing ‘permissionless’ ledgers that rely on tokens or incredulous amounts of trust, against ‘permissioned’ ledgers where there are strong structures for multiple parties, e.g. regulators, or the ledger is within a single organisation:

Nick Williamson Model

Nick Williamson; “What Is A Blockchain?” (04 January 2016)

Further, token or coins are expensive. The process of solving the equations needed to maintain a token-based system consumes energy and slows transactions.  The approximately 10 minute transaction window of Bitcoin and the 7 to 15 second window of Ethereum contrast strongly with the 3,000 to 5,000 transactions per second achieved using InterChainZ’s ‘permissioned’ ledgers, i.e. 106 times faster than Bitcoin.

Content Chains

The project developed a number of MDLs that directly stored documents, as well as MDLs that only recorded the ‘hash’ of documents.  This led to the development three conceptual MDLs, “identity chains”, “transaction chains”, and “content chains”. Corporate and individual identity chains authorise access to a transaction chain. A transaction chain holds the core ledger records of all transactions, but only a hash of original documents.  The content chain is an MDL holding all of the original documents. The content chain might be managed by a third party for storage and retrieval because of its size. This conceptual structure is quite flexible. The only technical difference between the chains is that the identity and content chains have a fixed length hash field while the content chain has a variable length field. 

InterChainZ in pictures for web report

In testing, the content chains held a variety of documents, pictures, videos, or spreadsheets, from a few thousand bytes up to 100 megabytes. In practice, the numbers are likely to grow rapidly.  Just for the personal identity chain a basic 100 nodes handling 1,000 clients would have a chain (excluding updates and changes) of approximately 75 gigabytes. Moving to a more realistic 500 nodes and 10,000 people gets to 3.75 terabytes, or 500 nodes and 10,000,000 people to 3.75 petabytes. Thus, the ability to segregate the large storage requirement, yet retaining the same MDL architecture, provides an ability to control this increasing size more smoothly. Further, most MDL benefits remain for a content chain under a managed service. Users can still copy it if they wish to. The function of adding new transactions to the content chain can still be transferred easily, preventing permanent centralised control of the content chain by a supplier.

Chain Options table for web report

Further Research

At a basic level, the project showed that MDLs work and can work together, but a number of avenues are yet to be explored, and a lot of essential infrastructure is lacking.  Further research could include:

  • Market functions – Order matching, margining, account functions, clearing, settlement, as well as possible uses of a token currency within exchange;
  • Usability and ergonomics to enhance the end-user experience – Exploring the end-user experience by connecting to off-the-shelf wallets for cryptographic key management;
  • Integrity proofing – Dynamic anomaly and pattern response additions, monitoring and testing facilities;
  • Content hash – Addressable Storage Market (C#ASM) - extending the ‘identity’, ‘transaction’, and ‘content’ chain thinking that emerged from InterChainZ into an indexable archiving system both as a ledger itself, but also supporting other ledgers;
  • Data taxonomies, encryption levels and tracking – How feasible is it to have differently labelled categories and ‘data boxes’ (e.g. health, car insurance, home insurance, driving record, etc. on a person’s MDL) that can only be opened as a group, to encrypt levels with levels (first order health data perhaps before detailed data), to provide access records (who opened, when), and might homomorphic encryption have a role;
  • Facilities for automated creation of new mutual distributed ledgers – A parameter driven system providing options for permission management, proof of stake and identity settings, supervisor-master and other node settings, ‘voting’ permutations, and peer-to-peer structure settings;
  • Exchange functions – Processes to make the basic interacting ledgers into a demonstrator of a full exchange, with numerous ‘use cases’ therein, e.g. sharing identity functions with transactional functions and storing relevant documents securely and permanently;
  • Management and control features – Management information, performance statistics, visualisation;
  • Documentation of standards for mutual distributed ledgers and legal entity identifiers.

To find out more about our research, please visit the IntereXchainZ web page. 

Media Coverage


svg.lf_footer_svg{ height: 30px; width: 30px; }