Parts of this article are a snapshot from 2016 but have recently gained new relevance. Subsequent blogs will bring many things rapidly up to date, and reveal the latest developments in delivering secure data and transaction handling capabilities to clients using Smart Ledgers.
We have been working with mutual distributed ledger (MDL) technologies since 1995 for complex multi-party transactions, but until recently financial services people dismissed MDLs as too complex and insecure, until Bitcoin terrified them. The mania around cryptocurrencies has led to a reappraisal of their potential. Equally, MDLs are getting easier to implement and manage at a time when people are rethinking the future of financial services.
Z/Yen have a lot of work on, a project with SWIFT on The Impact and Potential of Blockchain on the Securities Transaction Lifecycle, ‘proof of concept’ and ‘use case’ demonstrators for clients, courses, and ongoing research. Z/Yen and Long Finance share their research widely, e.g.:
Z/Yen published the work of one significant 2015 research consortium (InterChainZ) online back in September. InterChainZ has been working on multiple MDLs working together. Z/Yen used their suite of MDL technologies built up over two decades, dubbed ChainZy, to build a set of seven ‘use cases’ working together. InterChainZ aimed to answer a core question – “what elements of a trusted third party are displaced by mutual distributed ledger (MDL) technology?” by providing a basic demonstrator of MDLs, including variants of blockchains, and comparing how they might work within selected financial services use cases. InterChainZ provides a generic demonstration suite of software providing an interface to MDLs for tasks such as:
- selection & storage of documents;
- document encryption;
- sharing keys;
- viewing the MDL transactions;
- viewing the MDL contents subject to encryption structures.
The software permitted the testing of a variety of MDL technical configurations. It was then employed to discuss and test various practical applications of MDLs. The outputs were shared with participants as joint intellectual property for their own future use.
InterChainZ has shared some learning online. This includes the below video – titled “Boring is Brilliant” – where participants (DueDil, PwC, and SunCorp) explain what mutual distributed ledgers are, and how they could be employed. A few of the key learning points from InterChainZ were:
Terminology: 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 emphasis on “mutual distributed ledgers” as the term of choice. The technical focus might be on boring ‘ledgers’, but the excitement is in the applications above.
Identity: 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.
Architecture Choices: MDL architecture has to reflect the economic and commercial realities of numerous businesses working together. This dictates that many different architectures are needed for many different situations. One ‘blockchain’ will not suffice for most business-to-business work. Different business uses 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.
Validation: Core to identity and architecture is the method used for validating new transactions. While Bitcoin blockchain’s ‘proof-of-work’ validation approach is fascinating, and suited to having seven billion people confirm retail transactions, it is not appropriate for wholesale markets. 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. However, Z/Yen long ago achieved around 1 billion transactions per day, a benchmark a few are now touting, by sacrificing token systems for other validation methods.
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.
Further Research – IntereXchainZ & MetroGnomo
At a basic level, the project showed that MDLs work and can work together, but current research, IntereXchainZ goes much further, pushing forward four themes:
- 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.