Overall Scheme
DDXF facilitates data resource exchange while ensuring data privacy protection and traceability. Its characteristics are as follows:
Data interoperability
Across off chain systems
On-chain features and techniques
The process that takes place on the marketplace through which resources are exchanged between the provider and the consumer as follows:
Resource digitization (secure storage)
Data resource attribute extraction
Resource verification
Resource exchange metadata assignment
Transaction contract confirmation
Contract safety bond payment
Requirements confirmation, resource processing workflow
Resource integration, transaction generation
User delegation and data characteristic mapping
Contract order generation
Transaction execution
Smart contract driven data processing and resource exchange
Instant dispute settlement and arbitration
The provider generates an ONT ID and a DDO on the blockchain for the resource that is to be published. This serves as an on-chain mapping entity for the resource.
The RP can invite a RA with certain credentials to authenticate the resources before release, so as to improve the credibility of the resources on the market. Generally speaking, highly trusted resources will have more potential buyers and may command higher fees, and will be more easily retrieved in the marketplace. Resource authentication can be done by the RA by issuing verifiable credentials to related resources, or by uploading the physical certificate of the resources onto the chain via ONT Sourcing.
The MP will provide some corresponding meta-information templates for specific resources, so that the RP can easily extract meta-information when publishing data. For example, a medical data marketplace will provide medical data metadata templates. When the RP prepares to conduct data transactions in an MP, it generates the corresponding meta-information for the resources to be released according to the MP's meta-information template for the retrieval and selection of the RC. When making the format of the meta-information template, the MP should meet certain specifications and provide necessary information accordingly.
The MP determines the pricing system based on the characteristics of the resources. The RP determines and submits its pricing method in a way approved by the MP. Common pricing methods include fixed pricing, dynamic pricing, and auctions. Once again, it should be emphasized that resource transactions are essentially the transfer of resource-related rights.
After the RP provides the resources, the resource authentication API provided by the marketplace or the platform-defined data is stored in the RA. The RA can use trust anchor to perform resource authentication for the relevant data, or directly store the entity certificate through ONT Sourcing certification. After the resource authentication is successful, the RP can proceed with data tokenization.
Please refer to the link below for details on resource auditing.
After the RP applies for the value confirmation or verification of the resource, the marketplace can be used to tokenize the resource (the tokenization). The data transfer carried out by the marketplace denotes the circulation of the tokens.
Please refer to the Resource Publication section below for more details on how the tokens are generated.
Based on the DToken contract, when tokenizing data, you need to pass the RPs account, the dataid of the resource, the ONTID of the controller, etc., to bind people, property, events, and things. The incoming controller has control of the data privileges, the essence of resource transactions is the conversion of Token permissions. After RC purchases a Token, you can use it to view the specific details of the data.
After the resource passes the RA certification, the resource is tokenized. After ensuring that the resource meets the standards of the third-party certification authority, the frequency of the data circulation can be judged to further evaluate its value. You can refer to the openbase credibility system to formulate a series of value systems for tokens by offering incentives for upholding contracts.
The RP publishes resources to an MP and waits for the RC to purchase. The published content includes the resource's ONT ID, associated ONT ID Document information, meta-information, rights to be transferred, pricing strategy, and authentication information (if the resource has any) of the resource from one or more third-party authentication centers. The MP stores the resource metadata and other information into a local database and optimizes information retrieval. The MP will also display related historical transaction information, authentication information, and other information from the chain.
The reviews of users and resources in previous transactions will be converted into equivalent scores under a certain distributed reputation system. The scores will affect the rankings of users or resources on the marketplace and the success rate of transactions.
There could be several different MPs, such as the medical data marketplace and antique auction marketplace. Each marketplace accepts and exhibits different types of resources based on its own market characteristics, and the same resource can also be published on different marketplaces.
The initial holder of the DToken is the RP, and the DToken can then be transferred (via transactions) to others. The RP can set a limit on the number of transfers allowed for the DToken. The number of transfers decreases with each transfer. If the number of transfers is 0, it means that the DToken can no longer be transferred.
Certain basic data fields and information needs to be provided in order to carry out token generation before publishing a resource, such as the token volume, resource ownership period time limit, marketplace SDK methods available to invoke the DToken contract and the marketplace purchasing contract.
When uploading resources, the RP needs to upload the token generation parameters together, and then when the RC performs the purchase operation, the DToken contract and MP purchase contract are invoked through the SDK methods provided by the marketplace.
The marketplace provides an SDK for querying the on-chain data chain. The platform needs to be integrated into its own project so as to allow users to view the description of the data. The platform can customize the exchange method, such as online or offline transaction tokens.
After the RC executes the purchase operation, it can have all the rights of the token. When the RC applies for arbitration, the MP arbitration contract will pledge the token. When the OJ determines that the RP has not provided the resources and sends this result to the transaction smart contract, it handles the resolution process accordingly.
After the resource retrieval phase, that is, after the RC quickly retrieves the required resources based on the resource meta-information at the MP, the RC will conduct transactions with the RP, the owner of the required resources. The resource transaction process roughly includes the following steps:
Place an order: The RC quickly retrieves the required resources according to the resource meta-information at the MP. The two transacting parties sign an electronic contract for resource transaction via ONT Sign, set the subject matter of the transaction (such as the right to use the resources), transaction details, and staking information of both parties (optional), transaction lock-in period (optional), dispute resolution logic, profit distribution logic, etc., and then create the smart contract. In order to prevent malicious behaviours, the RP and the RC each need to stake a certain amount (it may be 0) of tokens according to the electronic contract;
On-chain transactions: The RP generates the DToken on the blockchain for the transaction of resource rights, and transfer the DToken to the RC. The RP can also authorise the MP to generate the DToken. The RC can trade the DToken per the contract:
When the transaction of DToken does not involve the delivery of off-chain resources, it can be in the form of atomic transactions without setting a transaction lock-in period;
When the transaction is in the form of resource exchange, the RC will also generate DToken for the resource that is to be traded. Of course, the DToken can also be generated by an authorised MP. DTokens can also be traded in the form of atomic transactions, and can set a transaction lock-in period based on whether off-chain delivery is required;
When the transaction is in the form of exchanging resources for tokens (such as ONG), the token holder stakes a required amount of tokens into the transaction contract and sets a transaction lock-in period based on whether off-chain delivery is required;
Off-chain resource delivery: After the on-chain transaction is completed, the transaction lock-in period is triggered. During the lock-in period, the RC uses the DToken to receive the resources from the RP, that is, the rights to use the resources change hand. When a dispute arises, proofs need to be submitted to resolve the dispute. There are on-chain and off-chain proofs. The proofs can come from the Ontology blockchain, Ontology Oracle, and the OJ specified in the contract.
After going through the resource discovery stage, the RC quickly retrieves the required resources based on the resource metadata at the MP, and both parties can sign the relevant resource transaction electronic contract via ONT Sign. If the resource transaction process does not involve OJ, i.e. OJ is not required for off-chain judgment, it is not necessary to sign an electronic contract.
According to the characteristics of its tradable resources, MP can set up electronic contract templates to guide its users to quickly sign electronic contracts. Generally speaking, electronic contracts mainly include the following:
Transaction subject matter. The subject matter of the transaction is a certain right of a certain resource.
Trading party. Mainly specifies the RP and RC of the transaction.
Trading rules. Mainly stipulates the delivery period, delivery stage, delivery method, etc.
Transaction lockout period and dispute handling logic. When it comes to delivery and disposal of off-chain resources, it is recommended to set a transaction locking period and set dispute handling logic. During the transaction lock period, both parties to the transaction can deliver off-chain resource rights. When a dispute occurs in an off-chain transaction, the dispute is resolved in accordance with the dispute handling logic, and the result of the dispute is recorded on the chain. Generally, the chain of dispute resolution results is carried out by OJ. In addition, Ontology Oracle system can also be used for off-chain dispute resolution.
Both parties pledge information. It is agreed whether the two parties of the transaction need to pledge a certain amount of tokens. In general, RC will be required to pledge tokens that are at least equivalent to the price required to obtain the subject of the transaction to make the transaction smooth. Sometimes, RP may also be required to put in a certain amount of tokens as security deposit to prevent them from doing malice.
Profit distribution: It mainly stipulates how to divide the profit after the transaction is completed. The suspension or cancellation of the transaction is also considered a way of completion. Split run is mainly carried out between the parties to the transaction, MP and OJ.
During the transaction lock-in period, the RC uses the DToken to receive the resources from the RP, that is, the rights to use the resources change hand. During the lock-in period, disputes may arise due to problems occurred during the transfer of resources-related rights.
Under normal circumstances, since the automatic profit distribution logic usually transfers the transaction fees of the RC to the RP after the transaction lock-in period ends, the settlement of transaction disputes is generally initiated by the RC. The initiator of the transaction dispute arbitration needs to stake a transaction dispute application fee, which can be paid in the form of a deposit when the transaction is established. The losing side of the dispute arbitration will pay the costs incurred and possible fines. When the transaction dispute arbitration rules that the initiator loses, the transaction dispute application fee will be used to pay the arbitration fees; if the other party loses, then its stake is usually used to pay the arbitration fees.
For one transaction, due to the existence of the contract and the OJ jointly designated by the two parties, the result of the first dispute arbitration shall prevail.
When a dispute arises, proofs need to be submitted to resolve the dispute. The tamper-proof, open and transparent blockchain, as well as the automatically executed contracts, help improve the transparency of the data transaction process, can record the process of disagreement, and facilitate the transacting parties (the RP and the RC) to submit the necessary proofs. In order to increase the transaction processing speed and the degree of automation, the conditions for the success or failure of the transaction need to be defined. For example:
Whether the RP's resources are accessible during the transaction lock-in period. If the RP cannot provide this proof, the transaction will fail;
If the RP submitted the RC's record of resource delivery, the transaction will be successful.
Each condition corresponds to a validation logic. When a dispute arises, proofs need to be submitted to resolve the dispute. There are on-chain proof and off-chain proof.
The verification of on-chain proofs is done directly by the blockchain nodes. Common on-chain proofs include digital signatures, preimages on Hash functions, zero-knowledge proof, Merkle Proof, and so on. The off-chain information imported into the chain through Ontology Oracle can also be considered as on-chain proof and is processed by relevant processing logic;
When there is a dispute that cannot be settled on the chain, then an OJ is required to complete the verification of the off-chain proof. The OJ completes the confirmation and arbitration of the off-chain transaction according to the electronic contract signed by the two parties via ONT Sign and sends the arbitration result to the smart contract of the transaction. The arbitration result is part of the dispute settlement.
The proof of dispute liability determination, whether it is on-chain or off-chain proof, will affect the outcome of dispute liability determination, which in turn will affect the profit distribution of transactions. The determination of the liability for the dispute may trigger profit distribution in advance.
After the transaction lock-in period, that is, after the off-chain resource transfer period ends, the transaction will enter the profit distribution phase. Profit distribution is mainly between the two transacting parties, the MP, and the OJ. Profit distribution is a relatively broad concept, including returning the staked token to both parties and distributing transaction fees to the MP. Either party of the data transaction can trigger profit distribution, which will automatically distribute the profit based on the preset logic.
If there is no dispute, profit distribution will be triggered automatically when the lock-in period ends.
If an arbitration occurs, then the profit distribution operation will be triggered automatically according to the arbitration result when the lock-in period ends.
Transaction success, termination, or penalty for malicious behaviour are all a form of profit distribution.
The conditions for the success or failure of a transaction formally define the possible status of the transaction and the corresponding judgments to execute the appropriate profit distribution strategy accordingly. For example, the profit distribution strategy defines that when the RP cheats, the staked token of the RP will be confiscated when a dispute occurs. Then if the OJ rules that the RP did not provide resources and puts the result into the transaction smart contract, the contract will be executed accordingly.
In case of no disputes, the incentive is shared as per policy.
The marketplace platform uses the contract to set transaction fee rate, deposit rate, and the arbitration fee rate.
RP receives the resource deposit amount
RC receives the resource tokens
The marketplace platform receives the transaction fee
In case of a dispute, the incentive is distributed based on the dispute resolution result.
The marketplace platform can use the contract to set transaction fee rate, deposit rate, and the arbitration fee rate. Before publishing a resource, the RP needs to pay a resource deposit, and the RC needs to pay transaction fees to the marketplace platform.
If a party initiates arbitration, the arbitration fee shall be paid by the concerned party, and the fee shall be pledged into the MP arbitration contract through the API.
If the initiator is judged to be unsuccessful by OJ, the final arbitration fee will be owned by OJ. The commodity fees paid by RC in advance will be distributed to both parties by OJ through the MP arbitration contract interface. The MP platform will finally get the transaction fee when RC carries out the purchase.
The various fees with respect to the marketplace are calculated as follows:
Resource Deposit = Resource Price * Deposit Rate
Platform Transaction Fees = Resource Price * Platform transaction fee rate
Arbitration Fees = Resource Price * Arbitration fee rate
The OJ needs to be hired and provided by the RC. Generally speaking, an arbitration is triggered by the RC in most cases.
After the transaction is completed, the RP and the RC review each other. The review can be about the resources or users. The MP can provide a review system and the post-transaction reviews are stored in the MP's local database. When the on-chain review system is well-established, the MP can use a combination of the on-chain review system and local review system to present a more accurate rating.
Please proceed to the next section for more details regarding the currently available solutions.
