I’m
looking for kindred spirits in the word of blockchain-esque database
solutions. I am saying esque, because in common with some other "blockchain" projects in this space, this isnt blockchain, it just uses parts of it (I.e merkle proof
against deletion and public key encryption and authentication).
I
did some work last year building a trusted record or Contract sharing
system. The use of the term contract in this instance is I believe a traditional one. It's a document where we all have an identical signed copy. This is not about cause and effect. It’s essentially record level replication where each record has it’s
own set of participants to share with, backed up with signed verification from all
parties that any action was successfully committed by all parties. The Contract consists
of a tree of fields or Elements, each of which can have one or more
values or Proposals. The record structure, this Elements tree, has ownership and
can only be edited by the owning party of any specific Element. A
party can create sub Elements and pass them onto another party to be further
expanded. Proposals also belong to a party, so we have no contention issues. All we ever do is write to parts of the data space we own.
The
schema was further extended with Rule and Parameter entities to support a
simple, but what turns out to be a very powerful set of rules
primitives. These are mainly for constraints on values and edit/submission access , but a trigger rule exists to support a state
transition workflow. Rules can become active or inactive dependent on
the current state. There is also a derived variable assignment mechanism, as variables are completed complex constraints can be evaluated.
I
implemented it using Sequelize, which is my excuse for posting. All CUD operations on Contract,
Element, Proposal, Rule and Parameter have hooks to cause hidden tables Request and
Dialogue to be affected and Transmitter and Receiver daemons are
notified to do work.
So what ?
The
core of this is a rather boring, seemingly esoteric issue about IT and
corporations. Any large corporation has it’s own systems. They are
averse to "hub" solutions, where essentially we just all use the same data system. There are lots of reasons for this, but hubs just dont work.
We need a distributed record, a ledger where each record has its own
network, and each system on that network holds an incontrovertible copy of a record and its entire history, with cryptographic certainty that all parties have identical
versions. If they used something like this then at least multiple data
entry and cross checking overheads can be wiped out. But it's much more than this.
An important goal was to enable the end user to, with the agreement of all parties, extend and adapt a contract. This empowerment not only short circuits a tedious knowledge transfer, in sharing the analysis between parties we can have the network driving data standardisation. You can use an existing Contract‘s Element tree as a template or starting point for a new one with another company. I have a series of business cases to illustrate this re-use once we have a bilateral system deployed. You can also re-use components, and hence modularise your data. And you can edit and extend it’s structure as required. Of course lower end users just get an application, they dont get to start reconfiguring stuff.