ZK-Oracle's Solution
Last updated
Last updated
Before the Polkadot mainnet goes live and meets the technical and functional requirements of this project, ZK-Oracle’s preliminary plan is to create a scalable Layer 2 component layer based on the privacy blockchain SERO for data management (such as data availability and reliability） and privacy protection, and . After the Polkadot mainnet is live and ready, ZK-Oracle will directly migrate to the cross-chain Substrate-based architecture to achieve cross-chain functions while inheriting the original anonymous security. As a trustless and reliable oracle protocol, ZK-Oracle will obtain trusted data sources by optimizing the power of community and adding economic incentives and punishment mechanisms to provide a self-operable and self-organizing data source component for Polkadot, SERO and other blockchain’s future cross-chain business ecosystem. The data source can be read through multiple channels, and can also be aggregated usin g the average value, median value and multiple values added to the weight to provide reliable data values for trading markets such as cryptocurrency versus cryptocurrency and cryptocurrency versus fiat currency.
ZK-Oracle does not define how data should be processed, but lets the community collectively decide how the data will be processed or optimized, and provides a reliable source of data by integrating the power from motivated community participants.
The participants in the ZK-Oracle ecosystem are defined as follows:
Application Data Requester: The contract or account that initiates data request by staking native token ZKT is called a Network Data Requester, referred to as ADR;
Application Data Provider: Participants who provide data to the ZK-Oracle contract, referred to as ADP. The ADP of the whole network can be divided into Specialized Data Provider (SADP) and General Data Provider (GADP) according to whether it is designated by ADR.
The workflow of ZK-Oracle is as follows:
Each Application Data Requester(ADR) initiates data request through the deposited native token ZKT, and can define the data supply structure, time period and frequency of supply;
The data supply mechanism is similar to call auction mechanism, and only the data provided within a specified period will be considered valid;
Application Data Provider(ADP) are divided into General Data Provider (GADP) and Specialized Data Provider (SADP), the former is generated through the whole network bidding, and the bidding requires a certain amount of ZKT tokens. ZK-Oracle will regularly initiate an irregular ADP bidding plan for SADP based on the actual situation of the network;
The ZKT participating in the auction will be partially burned, the other part will be staked for the bidding;
The Specialized Data Provider is designated by the corresponding data requester. The Specialized Data Provider (ADP) in the early mining stage does not need to deposit and pay native tokens. The revenue of the oracle node is subsidized by the mining part of the system, after the mining part is fully mined, for each Specialized Data Provider (ADP), ADR needs to pay the agreed amount of ZKT, and the system will burn it in proportion and return it to the ADP oracle node as a service fee;
ZK-Oracle selects a General Data Provider based on the data supply of the entire network within a certain period. GADP will receive the mining revenue based on its percentage in the entire network (GADP only) until the number of ZKT tokens is 6.18 times the number of participating auctions at that time, the ADP status will be lost and a new auction will be required to obtain the ADP status;
In addition, GADP can also obtain the reward part reserved from the contract by the data requester in order to incentivize the data supplier to provide reliable data;
The data requester can provide a verification mechanism that complies with a certain rule, and encrypt it through zero-knowledge proof. When the data provided by the data supplier cannot meet the verification, it will be deemed invalid, and the amount will be deducted from its future income limit;
Reputation System. Factors affecting the reputation of a node include the frequency of data provided by the node, completion rate, response time and data quality, etc. The more the node mortgages the token, the higher the reputation, leading to the higher chance of obtaining the assignment from the data requester and the increase in revenue.
