Capsule is an open-source transaction governing technology for the use in global industrial context, specialized in transferring trade and logistics data. It uses a combination of DLT (Distributed Ledger Technology, a.k.a. Blockchain) and DHT (Distributed Hash Table) to enable proof-of-existence of transactions with a tamper-proof timestamp.
The contents of a transaction is not stored in the network, providing a much more scalable platform for enterprise-size applications. The name is derived from the function of the system: the content of a message is discarded, leaving only the meta-data and wrappers (capsule) visible.
(Note to the reader: the text underneath is an unfinished extract from a greater body of work, it might contain out-of-order references)
Figure 1 – Conceptual overview
The signed transaction is related to only one object and contains all necessary data to proof ownership of the object. This signed transaction should now be broadcast to and confirmed by the network. To do this, the node will construct also a – different – transaction to broadcast to the network. This blockchain transaction contains a transaction type identifier, the hash of the object it is referring to and a hash of the original signed transaction.
Then, is the network to accept this transaction blindly? There is no way for a blockchain node to confirm the validity of the original signed transaction by only knowing the blockchain transaction it received. Before including the blockchain transaction in a new block, a node should first obtain the original signed transaction and verify its validity.
The initial node might broadcast the transaction to the peers it is connected to, and then let the network gossip the transaction. A node receiving both of the transactions (the blockchain one and the signed original), can now verify the original and include the blockchain transaction in a new block. One question arises though: how will a node that was disconnected while the network was gossiping the original signed transaction, verify the validity of the new transactions it sees in the blockchain? The other nodes have processed the transaction already, and there is no need for them to maintain record of the original transaction.
To solve this last problem, I propose a highly scalable distributed database, such as a NoSQL DHT database. The original node pushes its transaction onto a distributed database that has a certain degree of redundancy. Tampering of the signed transaction by untrusted DHT nodes (a) must be coordinated, as the tampering must happen exactly the same on all places where the transaction is stored redundantly; and (b) will only result in the transaction not being approved, not in false data being confirmed by the blockchain.
Since this distributed database serves the single purpose of providing storage to not-yet confirmed transactions, a complete failure or the loss of data is not breaking the system. In fact, data points can be deleted on purpose. For instance, when the conformation is nested deeply enough into the blockchain, the original transaction can be deleted in the distributed database. This way, a new node is not able to verify the old transaction, but is forced to accept the wide consensus in the network about the validity of this transaction. This way, the database puts only slight additional workload on the systems.
We have constructed a more scalable system now, consisting of two networks. One is the blockchain, which is – in our system – a chain of confirmations. The other network is the distributed database, serving only a faciliatory role in confirming transactions. As long as a node owns the original full transaction (which is likely not stored in the distributed database anymore), it can let the network confirm that it occurred at a specific point in time.
To verify the ownership of a certain object, one needs the data of the original signed message. It is up to the actors involved to locally store and back-up the messages they would like to retain a record of. When asked to check whether a transaction is the most recent transaction relating to an object, it suffices to query the blockchain database for the latest transaction referring to the document hash. This way, an actor who was once owner of a object can proof the timespan of his ownership, yet it is apparent – without knowing who the object was transferred to – that he is not anymore the owner now.
For more information, feel free to contact me.
Michiel Valee [email protected]