Blockchains come in all shapes and sizes, with different consensus mechanisms, and performance characteristics, but the vast majority focus on financial use-cases, where the integrity of a cryptocurrency is the primary objective.
In contrast, SEEB focusses on the requirement for secure information sharing between independent parties within the Supply Chain, where the primary objective is maintaining availability, integrity and confidentiality of the shared information.
SEEB offers Data Access Control (DAC) within the Blockchain AND off-chain storage of encrypted data, which collectively support long-term availability of encrypted versioned file systems to users across multiple organisations.
The core SEEB protocol supports reliable mutual replication of transactions between a linear array of nodes through a two stage process: in the first stage, each node processes new transactions using standard RAID 6 software, sending each RAID stripe to a different node; then in the second stage, each node replicates the RAID stripes previously received to every node. This process ensures every node is able to reconstruct every transaction reliably, even if there are significant transmission losses.
The extended SEEB protocol supports reliable replication of transactions across multi-dimensional arrays of nodes, by repeating the core replication protocol across each dimension in successive time intervals, in order to support reliable replication across hypercube network topologies.
The core and extended SEEB protocols are implemented within a single packet structure, which ensures that each packet communication from one node to another is atomic and either succeeds or fails. The core protocol is resilient to multiple packet losses, so all nodes will receive the new transactions. However, in the event of too many packets being simultaneously lost, then none of the nodes will be able to reconstruct the new transactions.
This ensures that every node within the network will receive the same transactions within any specified time period, which means that every node can construct the same block of transactions for each time period, which can be chained to form a Blockchain.
In order to support explicit confirmation of consensus, we require a random sample of the nodes to publish the hash of each block, which can then be verified by every node in the next time period, allowing each node to explicitly report consensus issues so that all nodes can determine the documented consensus. This process can optionally be enhanced to improve failure mode performance and reduce the recovery time.
The final aspect of the SEEB protocol is to “seal” the consensus, using chained signatures to provide proof beyond all reasonable doubt that all nodes in the signature chain have explicitly validated the block hash consensus.
The off-chain storage protocol distributes RAID 6 stripes of the encrypted file versions across multiple Gatekeeper nodes, which are responsible for persistent storage of the stripes, in accordance with the retention specification stored within the Blockchain. This process can optionally be extended to ensure the data can be reconstructed through collaboration between any X of Y Gatekeeper nodes, which either store the stripes themselves or offload the storage to a cloud storage service.
Every node maintains an independent copy of the Blockchain, whereas the encrypted files are distributed across nodes with an arbitrary level of redundancy, which needs to be appropriate for resilience & cost expectations of the user community.
In general, we would expect the Gatekeepers to distribute the stripes across multiple cloud service providers, utilising multiple cloud storage regions and multiple cloud storage accounts. In consequence, we would expect the encrypted file storage to be highly resilient to failure events or censorship actions of any individual cloud service provider, and fairly resilient to failure events or censorship actions that are distributed across wider geopolitical regions.
However, the global resilience to such failure events or censorship actions can be significantly enhanced by introducing separate Blockchains for each user community, which can independently select Gateways nodes, based on community-specific selection criteria.
The SEEB Blockchain will be fully documented by the DACOSIA project, with a Technical Reference Manual & Reference Implementation. However, we expect alternate implementations to be developed in future projects, which will allow user communities to dynamically select preferred implementations, based on community-specific selection criteria.