The protocol ensures the exchange of reliable data for cryptocurrency and guarantees that none of the parties will be able to take advantage of each other. This protocol is used in the DISCIPLINA work in order to only provide recruiters with verified data on academic achievements.
The protocol has two parties - the Buyer (B) and the Seller (S). The system also has an intermediary that can hold money and validate the data. However, unlike conventional data exchange algorithms, this intermediary in DISCIPLINA is a blockchain — a decentralized ledger with a consensus mechanism that can ensure the validity of all the transactions.
Each party will have the opportunity to determine the validity of the data. If any disputes occur, the parties will use blockchain as a final judge: the chunk of data that the Buyer claims to be invalid is observed by the nodes of the network, and then the Buyer decides whether the data is valid or not. It should be noted that the blockchain nodes will not have access to the data as long as the parties agree on the fairness of the deal.
Before making a deal, the Buyer will have to notify the nodes about the function that will be used for the validation. Each chunk of the traded data will have to be valid in terms of this validation function. The Seller then encrypts the data with a session key, computes a Merkle root of the encrypted data, and puts this Merkle root in the publicly available chain of blocks.
The Buyer creates a session keypair and makes a transaction, making the session public key available for everyone. They also send coins that are locked on the smart-contract with this transaction.
The Seller sends a fixed security deposit to the contract and waits for a pre-agreed confirmation period in order to be sure there is no chain rollback. They send the encrypted data chunks to the Buyer off-chain, which allows to avoid storing a big amount of information in the blockchain and disclosing the entire dataset in case of dispute.
After the Buyer confirms that they have received the encrypted chunks, the Seller publishes a session key encrypted with the public session key of the Buyer.
Now the Buyer can decrypt the data. This stage has two possible scenarios:
If the Buyer finds out that some data chunk is invalid, they can just identify that invalid chunk and reveal their private session key. Any user can then decrypt the chunk and apply the validation function. In order to prove that this chunk was indeed among the data that the Seller sent to the Buyer off-chain, the Buyer also provides a Merkle path of this chunk. In the event that the Buyer can prove the data is invalid, they receive their money back, along with the security deposit initially provided by the Seller.
If all the data is valid, the Buyer acknowledges it through the on-chain transaction. If they fail to do so, the contract automatically sends the money to the Seller after a certain time period.