Quant Network’s Overledger: Part Three — Verification and the Tokenisation of data
Disclaimer: Please note this article was accurate to the best of my knowledge at the time of writing. This information should not be used as a reference source to make any investment decisions (as is the case with all my articles). The Quant team have removed multiple references surrounding tokenomics of the QNT token, including the original tokenomics paper, the Overledger Network for community paper (which you can find an copy on a 3rd party side here ) and archive of removal of medium articles written by Quant surrounding tokenomics can be found here). For clarification around any topics you should seek clarification from other sources rather than rely on any information found in this article.
This is Part Three in the series looking at Quant Network where we look at the verification and tokenisation of data as well as oracles. Part one can be found here and a link to the other parts can be found at the bottom of this article.
Verification of Data
Quant Networks fingerprint verification Technology allows developers to assign digital fingerprints to real world IP, documents, physical goods, etc. in a way that is secure and non-reputable. This technology will revolutionise the use of blockchain across sectors, having the ability to assign a true identity to a physical item such as contracts, pharmaceutical products, designer goods or to data assets that will lead to the wholesale adoption of DLT technologies, setting it on the path to realise its full potential.
The technology can be used to provide interoperability across blockchains, provide Oracle functionality, Tokenisation of Assets, Supply chain to verify the origins of a product and that its authentic, enable completely confidential transactions over Public blockchains, Zero Knowledge Proofs, Prevent Phishing and many more uses. Quant Network have made the tech freely available to developers and can easily integrate it into existing systems via the Overledger SDK.
Trust and Interoperability
The vast majority of blockchains have the ability to add a small amount of metadata to a transaction. Bitcoin allows the use of OP_RETURN field to add metadata, Ethereum has script bytecode field, ripple has memo’s field. Only the digest of the message is stored on the blockchain, the message itself is not. The actual message is sent off chain and the receiver can run the message through a Hash function to verify that the Digests match. It’s also important to point out that the concept of a blockchain “message” doesn’t mean it has to be a basic message, it can require a more complex format and be part of more complicated interactions if desired. Popular mark up languages such as XML and JSON would be well suited for building messages and could be exchanged over standard HTTPS machines, XML and JSON which are all widely used in Internet communication today.
If you haven’t already, I strongly recommend reading the 1st article in this series, which explains Hashing, Digital signatures and overview of how a blockchain works to make the following make more sense if you are unfamiliar with them.
Recall from Part one where Bob was sending a Bitcoin Transaction. The Bitcoin Transaction consisted of Inputs and outputs. This Transaction data was then put through a Hashing function.
If Bob wants to send a message out of chain, Bob can put the message through a hashing function and then add the output (Digest) as metadata to the Blockchain Transaction (using the OP_Return field for Bitcoin, Memo field for Ripple etc)
Also recall how Hashing was used to convert the message “Hello World” with a Hashing function to output a Digest and that Hashing was a one way function used to verify the integrity that the message hadn’t been modified. Whilst it’s not possible to convert a Digest to the original message, once you know a certain message converts to a certain hash, you know that any instance of that hash represents that message. To get around this a cryptographic “Salt” is appended to the message before it is put through a Hashing function. The Salt is a completely random string and is unique to each user. So multiple users now using the same message as “Hello World” would have a different Digest output as the Salt that is appended would be different.
Example of Bob creating a Digest of the message appending his unique “Salt”
Example of a different user creating a Digest of the same message but appending a unique Salt Value
Then Bob creates a Digital Signature by putting the transaction details (including the added Digest of the message as Metadata through a Hashing function and then Encrypting them with Bob’s Private key.
Which was then added to the Transaction and put through a Hashing function again to get the Transaction ID which is then appended to the blockchain.
Bob can then encrypt the actual message and the Salt using the MAPPs public Key and send the message off chain to the MAPP.
The MAPP receives the encrypted message and decrypts the message using its Private Key to see the Message and Salt value
The MAPP then puts the message and Salt through a hashing function to calculate its Digest value
The Transaction details along with the Digest are retrieved from the blockchain and compares it to the value the MAPP has calculated based on the received message. If they match it is seen as Valid and removes the Salt value that was appended to the message.
By adding the Digest as metadata of a blockchain transaction it also benefits from the same features / security that they receive in addition to others such as Privacy:
Identification — Bob is identified by the Public Key of their sending wallet.
Authentication — Authentication is achieved by Bob encrypting the Hash of the transaction details with his private key to create the digital signature.
Non-Repudiation — as only Bob has access to his private key it can be stated that the message was compliant with the will of the entities that have signed it and could not refute signing the message.
Integrity — Hashing verifies that the transaction data hasn’t been modified but also by including the Digest of the Message as metadata it validates that the message that is sent out of chain has not been modified as well.
Privacy — As the message is not stored on the blockchain and just a Hash of the message and salt then users are able to share messages / transfer Data / Digital Assets privately even over permissionless blockchains such as Ethereum and Bitcoin. This also means that it is compliant with Regulation such as the EU’s GDPR (General Data Protection Regulation).
Immutability — By storing the Digest on a blockchain, it makes it extremely difficult for someone to modify the Hash stored on the blockchain.
High Availability — Blockchains provide an extremely resilient infrastructure so that the Digest is always available when needed. The data can be compared against the Digest stored on the blockchain to ensure it hasn’t been modified even after years after initially receiving it.
Interoperability — This can be used to send Data between two Non-Blockchain applications. Send Data across multiple blockchains for multi chain smart contracts (Treaty Contracts). As well as providing Oracle services where Data offchain can be used for smart contracts on a blockchain.
Oracles
An Oracle provides connectivity between Non-Blockchain systems and blockchains with the ability for smart contracts to use data retrieved from external sources.
Many of the challenges in constructing secure oracles arise from the fact that existing data sources don’t digitally sign the data they serve. If they did, then oracles would not need to be trusted to refrain from tampering with data
This is what Overledger provides. It enables data to be signed at source to provide the most secure and trusted method where you don’t have to Trust 3rd party oracles with Data / Requests, validating the data and then for the oracles to sign a transaction confirming its correct. Instead the data is signed at source and the Hash of the data is stored on any blockchain (Public, Private, DAG etc) to provide integrity, non-repudiation and immutability.
Data from multiple sources can be aggregated together in a treaty contract as well as the ability to then use that data across multiple blockchains all from the same treaty contract. The actual data is encrypted and send directly to the MAPP to be used by the treaty contract. Overledger can’t decrypt the data / nor does it have to, it’s simply passing the encrypted data to the MAPP and retrieving the associated blockchain transaction that was signed by the source so that the MAPP can validate it.
Tokenisation and Privacy
As discussed, Quant will allow the tokenisation of Assets to be stored on a blockchain by assigning digital fingerprints to them. Utilising the built in Zero-knowledge proof capability built in will allow Enterprise and developers to safely use public permissionless blockchains, keeping privacy and compliance to regulation like GDPR. It’s a huge deal for a risk-averse enterprise to be able to safely connect their private permissioned blockchains to public and permissionless blockchains.
Another benefit would be the ability to track an asset all the way through the supply chain and verify its origins. This is useful not only for a consumer to verify a product is genuine but also if a manufacturer needs to track where an item has come from. As its very likely that there will be multiple different Supply chain blockchains used through the entire supply chain there is a need to be able to transfer and interoperate between them which is what Overledger will allow.
Sticking with the Supply chain theme, related documentation can also be put on the blockchain allowing for a single source of trust but due to the number of parties involved you would normally want to limit what each party can see to only see parts of the document they are required to see. It provides an optional privacy flag which will add Hash pointers to another part of the message. In this way applications can provide each user with user-specific parts of the messages, i.e., unique content addressed only to specific users. Thus, if a user has no rights to see some part of the multi-part message, she will only see a hash pointer or a random piece of data.
In Part Four I will look at some of the other features that will be made available to developers via Overledger in addition to those mentioned in this article
Part One — Blockchain Fundamentals
Part Two — The Layers Of Overledger
Part Three — Verification and the Tokenisation of data (This article)
Part Four — Features Overledger provides to MAPPs
Part Five — Creating the Standards for Interoperability
Part Six — The Team behind Overledger and Partners
Part Seven — The QNT Token
Part Eight — Enabling Enterprise Mass Adoption
Value Beyond Speculation — Why Quant has the potential to be an incredible long-term investment
Quant Network Enabling Mass Adoption of Blockchain at a Rapid Pace
Large Enterprise Adoption of Blockchain is happening, enabled by Quant Network’s Overledger
