GREP
Generic Resource Exchange Protocol Specifications
The Generic Resources Exchange Protocol (GREP) is a set of decentralized resources exchange protocols built on the Ontology main chain infrastructure. By using the GREP, users can quickly establish on-chain attestation and transfer platforms for data and other resources. Thanks to Ontology's comprehensive trust ecosystem infrastructure, including the decentralized identifier ONT ID, the decentralized multi-source authentication system Trust Anchor, the trusted off-chain data connector Oracle, and the decentralized electronic contract and signature system ONT Sign, the GREP can provide a solid foundation of trust for decentralized resources exchange.
GREP Ilustration
Through the GREP, anyone can quickly and easily establish a diverse on-chain resource attestation and transfer platform. Under the protocol, resources can be digital resources, such as data, CPU computing power, GPU computing power, storage, on-chain Oracle and trusted computing platforms, etc.; they also include some physical resources, such as property, antique calligraphy and paintings. The platform can be a general-purpose platform where multiple resources can be circulated; it can also be a general-purpose exchange platform for the fine-grained circulation of specific resources.
Resource circulation can be in the form of exchanging resource for ONG, OEP-4 tokens, etc., or it can be in the form of resource exchange. Possible forms of resource transfer include, but are not limited to:
- Data resource circulation, such as exchanging medical big data (analysis results) for ONG;
- Circulation of computing power resources, such as exchanging trusted computing power for PAX;
- Circulation of physical resources, such as split auctions of ownership of famous paintings.
The circulation of resources is essentially the tokenisation and transfer of the rights to use the resources. For a resource, it can be its ownership or the right to use that is circulated. Resources with off-chain entities need to be delivered off the chain, and the method of off-chain delivery will be determined by the nature of the resource and other factors.
In the GREP, the Ontology public chain provides an important decentralized foundation of trust. Each user, including the resource provider, resource consumer, resource verifier and off-chain judge, needs to generate a corresponding ONT ID for themselves, and register and/or complete related KYC authentication according to the needs of the marketplace. Resources need to be registered on the chain during the transaction. When registering, the unique code of the resource is usually extracted to create a digital fingerprint, and the corresponding ONT ID is generated for the resource.
The process of data and resource exchange can be viewed as exchange and transfer of tokens. The process is executed using smart contracts.
GREP defines the following roles that implement the token exchange process:
- Resource Provider (RP): An entity that can provide and transfer resources-related rights and make them accessible to the market in exchange for some rewards (for example, ONG or some other resources) through a certain pricing system. The resource provider may or may not be the owner of the resource. For example, it can be a resource aggregator. There are many types of such entities, such as data owners, computing power owners, data collection platforms, and data custodians with certain permissions.
- Resource Consumer (RC): The counter-party of a resource provider and an entity that is in need of a certain type of resource. The resource consumer pays the resource provider a fee (for example, ONG) in exchange for the (partial) ownership or the right to use the resource.
- Resource Authenticator (RA): A third party with certain credentials that has its own resource quality authentication system, according to which it can provide resources or resource providers with a certain way of authentication to enhance the credibility of resources or resource providers. An authentication fee may be charged based on different models. Compared to their non-authenticated counterparts, authenticated resources have more potential buyers and are likely to command a higher fee.
- Off-chain Judge (OJ): An off-chain dispute arbiter recognized by both the resource provider and resource consumer of a transaction. Off-chain disputes (for example, the resource consumer did not receive the resources) will be arbitrated by the OJ.
- Marketplace (MP): It is the link between the resource provider and resource consumer. It stores the meta-information of resources, provides flexible display and fast search for resources while charging a transaction fee. Each marketplace can provide scalable and flexible services according to the characteristics of its own transactions, such as providing meta-information templates, electronic contract templates for resolving off-chain disputes, etc., for both parties to the transaction. An MP generally has a resource transaction pricing system. In addition, the MP generally also has a resource transaction information disclosure system, which can disclose transaction information to the public or regulatory authorities.
Privacy is the top priority in the GREP design process. The GREP is committed to protecting the privacy of personal information and trading information of both parties in the transaction. In addition, another focus of the GREP is that resources (especially digital resources, etc.) themselves and resource metadata will not be uploaded onto the chain.
GREP provides a method to fix the price of a resource. There are different ways to set the price, such as auction pricing, bidding, etc. Two common methods are as follows:
- 1.Fixed Pricing: The RP sets the price when issuing the resource the first time and if interested the consumer must carry out the transaction at this fixed pricing.
{
pricing: fixed // Pricing method
price: 10.23 // Price
currency: ONG // Price unit, e.g. ONT, ONG, etc.
}
2. Negotiatory Pricing: The RP does not define a price when issuing the resource. The price is set by negotiation between the provider and the consumer. The price is then set and updated in the transaction contract.
{
pricing: negotiatory // Pricing method set to negotiatory
}
The user selects the MP where the transaction is to take place according to his own needs. Resources that can be delivered multiple times can be traded in different ways on different MPs. For example, the right to use a piece of data can be traded in multiple MPs. It is assumed that users, including the RP, the RC, and the OJ, have already completed KYC according to the requirements of the MP. The entire resource circulation process involves resource preparation, resource release, resource transaction, profit distribution and post-transaction review.
The complete process is described in the use case section. Resource and data exchange is carried out via GREP by implementing a reputation system that is based on transaction ratings. This is a step towards developing a reliable, trust based ecosystem.
- 1.Registration of the resource on the chain. The RP creates an ONT ID on the chain for the resource to be published and generates a corresponding ONT ID Document as a mapping of the resource on the chain;
- 2.Resource authentication * (optional) *. The RP obtains authentication of the resources that are to be released from the RA;
- 3.Resource pricing. Specific transaction rights and pricing methods are determined based on the pricing system provided by the MP;
- 4.Generation of resource meta-information. Generate the resource meta-information based on the resource meta-information template provided by the MP.
- 1.Resource submission. The RP submits the resource's ONT ID, meta-information, rights to be traded, and pricing method to the MP;
- 2.Resource information processing. The MP obtains the information corresponding to the resource from the chain and its own database;
- 3.Resource display. The MP displays the resources so that the RC can quickly retrieve the required resources based on the resource meta-information.
- 1.Resource retrieval. The RC quickly retrieves the required resources stored by the MP according to the resource meta-information and selects the resources that it wants to trade;
- 2.Signing of the electronic contract for resource transaction * (optional) *. The RP and the RC use the MP's electronic contract template to create an electronic contract between the two parties, appoint the OJ, sign the contract via ONT Sign, and record it in the transaction smart contract.
According to the MP or contract requirements, the RP and the RC may need to stake a certain amount of ONG into the transaction smart contract respectively for dispute settlement and post-transaction profit distribution;
- 1.Tokenization and on-chain transfer of resource rights. The RP generates DToken according to the electronic contract, and authorises a certain right of the resource, such as (partial) ownership or the right to use, to the RC;
- 2.Off-chain transaction and dispute arbitration. When the transaction enters the lock-in period, the RP uses the DToken in exchange for the right to deliver the resources; if a dispute arises during the lock-in period, the two parties need to submit on-chain or off-chain proofs. The off-chain proofs will be judged by the OJ or Ontology Oracle.
Profit distribution of the transaction. After the lock-in period ends, the profit will be distributed according to the transaction results. The OJ's or Ontology Oracle's arbitration on the dispute may trigger profit distribution in advance.
Post-transaction review. In a reputation system, the RP and the RC review each other, and the review can be about the resources or users. The ratings obtained by users or resources will affect their rankings on the marketplace and the success rate of transactions.
When executing a transaction, the RP generates a DToken for the resource (implemented in the form of a smart contract), which includes a reference to the resource's ONT ID, the ONT ID of the DToken holder, and the validity period. DToken can be a homogeneous token, for example, the split of a crowdfunded property. It can also be a non-homogeneous token, such as one-to-one data delivery.
A possible DToken structure is as follows:
type DToken struct {
Name // The name of the DToken
Symbol // The symbol of the DToken
Amount // The amount of the DToken
ResourceID // The ONT ID of the resource corresponding to the resource
RealContractDigest // The record of the e-contract signed by both parties via ONT Sign
Expires // Validity period of resource rights
Exchange // The number of times the DToken can be transferred. The DToken cannot be transferred if the number is set to 0
Status // The status of the DToken, indicating whether it can be used. The counter method can also be used
}
The status of the DToken is initially set to "Unused" (even if the remaining number of transfers is 0). When the holder wants to obtain the right to use off-chain resources from the RP, the DToken status needs to be set to "used" first. The DToken in this status can no longer be transferred. When a resource can be "used" multiple times, the status can be set to a number, and the initial value is the number of times the DToken can be used. When the holder wants to obtain the right to use off-chain resources from the RP, the number of the DToken status decreases by 1. The value cannot be less than zero. DToken under a certain value can only be used once.
After the RP receives a request to use off-chain resources, in order to prevent malicious behaviour, the RP will verify whether the RC is the current holder of the DToken, and check whether the status of the DToken is available, etc., before transferring the right to use the resources. For example, when a DToken represents the right to use certain data, the DToken and RC signature can be used to generate a JWT to access the data corresponding to the DToken.
Off-chain behaviour, such as the attestation of ownership and legitimacy of resources, involve the identification of behaviors and the determination of rights in the real world. This identification method needs to be agreed by both parties, and if necessary, by a decentralized electronic contract and the signature system ONT Sign. Moreover, in the event of breach, how the off-chain liabilities are handled needs to be specified.
Since there may be off-chain disputes, for example, the resource provider has not delivered resources off the chain, the two parties to the transaction usually sign an electronic contract via ONT Sign to clarify how to settle off-chain disputes. The off-chain judge, which is jointly designated by both parties when signing a contract, is a more reliable and efficient way to resolve off-chain disputes. The off-chain judge or its delegate (for example, the marketplace) puts the result of the dispute arbitration onto the chain. The off-chain judge does not handle on-chain disputes, which are resolved directly through on-chain proofs. In addition, some off-chain proofs can be uploaded onto the chain through Ontology Oracle, and a direct ruling can be made on the chain.
GREP is an open public protocol. As the technology becomes more advanced and the ecosystem evolves, GREP's features will also grow simultaneously to keep up with the growing needs.
GREP supports the pricing of resources and provides resource transactions based on pricing. In the actual transaction process, Token payment is supported. Since the current token assets of the blockchain are located on multiple chains, GREP supports cross-chain asset transactions.
Last modified 3yr ago