Technical Design & Implementation

ZK-Oracle 's main function is to bridge the gap between decentralized applications and real-world data, and to use economic incentives model to ensure that data is accurate and reliable. ZK-Oracle will be initially designed and developed based on SERO chain to support Turing Complete Smart Contract platform on SERO and after the complete functions of the Polkadot mainnet goes live, while maintaining the original anonymous security solution, it will be migrated to the cross-chain Substrate underlying architecture to continuously improve the functions of ZK-oracle. The overall design of ZK-Oracle will focus on three aspects: Data Interaction Process, System Architecture and Interface Integration.

1. Data Interaction Process

When Dapps use the ZK-Oracle in the data layer to help smart contracts interact with off-chain data, the flows are as follows:

1. The smart contract sends data query requests through the proxy contract on the ZK-Oracle chain;

2. The proxy contract sends out trigger events with query parameters;

3. The underlying part of ZK-Oracle chain continuously monitors the defined events on the blockchain;

4. ZK-Oracle selects a set of off-chain nodes for query through rules, requests web API or web page, performs calculations or executes configured scripts;

5. The off-chain nodes reach an "in-group" consensus through the threshold signature algorithm, and feedback the consensus results to the ZK-Oracle on-chain system. The ID of group members and the performance of service quality evaluation parameters (responsiveness / accuracy, etc.) will be recorded on chain for monitoring and data analysis;

6. The ZK-Oracle proxy contract notifies the smart contract by calling the callback function provided by the user contract, and the result is ready.

2. System Architecture

It can be seen that the entire interaction process is divided into on-chain contracts and off-chain nodes to complete cooperation, so ZK-Oracle is divided into two parts, on - chain and off-chain, and contains the following core components:

A. On-Chain Part

The core components of the on-chain part are mainly the deployment of ZK-Oracle related smart contracts on the SERO chain. The main functions include processing requests and responses, calculate result verification, node registration and token mortgage, statistical monitoring, payment processing and other functions. The smart contract on chain also provides a unified interface for the upper level smart contract of ZK-Oracle.

1) On-Chain Proxy Contract

ZK-Oracle 's on-chain proxy contract provides a standard on-chain interface for smart contracts. Once the response is ready, it will asynchronously send back to the contract that called up the oracle.

2) Monitoring System

The monitoring system is used to save the off-chain records of ZK-Oracle node indicators and network statistics off the chain, including:

• The total number of nodes, the number of times the node group is selected, the uptime, etc.

• Reward details, weight percentage, delay statistics of callback and unprocessed query requests.

• The service quality score of the node, including the correct rate and the response rate of the report result. The monitoring system can display the real-time status of the ZK-Oracle network.

3) Registration System

To join the network, ZK-Oracle nodes need to mortgage and lock a certain amount of tokens as margin, and register their margin address and payment address in the registration contract. The deposit can make the system resist attacks and improve the security of the system. Nodes need to obtain " mining " rewards and earn service fees by quickly and correctly obtaining centralized results. Once the response times is out, they will be fined.

4) Payment System

Rewards for data requests will be sent to the current group selected to handle the request and distributed to honest members. These funds will first be stored in the payment contract, and node operators can check and withdraw their income.

B. Off-Chain Part

The off-chain part of ZK-Oracle is run by independent third-party operators which implement a L2 distributed peer-to-peer network composed of clients of the core protocol. ZK-Oracle 's off-chain nodes use a Byzantine protocol to reach agreement on the same API calls. In each round of the agreement, a random leader election is achieved through a resource (VRF random seed) that no one can easily monopolize. As long as most participants are honest and credible, the ZK-Oracle system will achieve final and unalterable consensus.

Important components in the protocol client include: event monitoring and chain adapters, node consensus components under the chain, request/computing task processing modules, etc.

1) Node Registration and Verification Group Selection

The newly registered nodes first enter the pending state. Once the pending pool contains enough pending nodes and waits for enough time, they will be randomly selected and form the threshold group of the current request. This part uses the VRF algorithm as the basis for random verification node selection. VRF is a function for random generation, and this function is verifiable, i.e. when the same private key signs the same information, only one legal signature can be verified, which is different from ordinary asymmetric encryption algorithms.

The specific operation process of VRF is:

1. The prover generates a pair of keys, PUB__KEY and $PriKEY$ . PRI__KEY is the private key, and PUB__KEY is the paired public key；
2. The prover outputs a random result result=VRF__Hash(PRI_KEY, info) ；

3. The prover outputs a random proof proof=VRF__Hash(PRI_KEY, info) ；

4. The prover submits the random result and random proof to the verifier. The verifier needs to verify whether the $result$ and $proof$ matches, if they match, go to the next step；
5. The prover submits the PUB__KEY and $info$ to the verifier, and the verifier calculates whether the result is $TRUE$ . If it is $TRUE$ , the verification is passed；
6. After the verification is passed, it can be deduced whether $info$ and $result$ match, which proves that the material given by the verifier is correct. In the whole process, the verifier did not get the prover's private key PRI__KEY .

Random Seed (Seed) Generation: The random algorithm will use the seed (Seed). For example, in the encrypted lottery of ZK-Oracle, the seed must be randomly selected and disclosed. This seed must be known to participating nodes and cannot be controlled by opponents. The seed generated in the round r of ZK-Oracle is determined by the seed of the previous round r-1 through VRF. This seed and the corresponding VRF proof are included in each proposed block. Once the nodes agree on the block of round r-1, when round r starts, everyone knows the pseudo-random seed r of the current round. The initial seed 0 value is calculated by the initial participants using multiple nodes together to obtain an absolutely unpredictable random seed. In this way, the seed will not be predicted by the "destroyer" and cannot be manipulated.

2) Form a consensus within the group

Verifiers (including sub-verifiers) know that they have been selected in secret, but they only have credentials to prove their qualifications as a verifier. For each selected node, use its own private key to sign the seed and enter the hash function to get its own credentials. The nature of the hash function indicates that the credential is a random string of 256 byte length, the credential of different nodes will not be the same, and the distribution of credential strings is uniform. In the same way, a batch of candidate leader nodes are selected, and the credentials of the candidate leader nodes are arranged in lexicographic order. The smallest candidate leader node in the ranking is selected as the leader node, i.e., the leader node is randomly elected from a set of candidate leader nodes.

The verification node and the leader node participate in the calculation of the Byzantine agreement $BA*$ together. In each stage and step of $BA*$ , the node independently determines whether it is selected in the committee of the current step in a private and non-interactive way. $BA*$ is a two-stage voting mechanism. In the first stage, the verification node performs a hierarchical consensus on the received candidate results, and selects the candidate with the most verification consensus. In the second stage, binary Byzantine judgment is performed on the candidate results selected in the first stage. $BA*$ consensus must ensure that the honest nodes participating in the consensus are greater than 2/3. If the randomly selected set cannot meet this condition, then multiple random elections are required. As long as the honest nodes participating in the consensus are greater than 2/3, a consensus can be reached. The verification nodes of each step of the $BA*$ consensus are designated in parallel or selected by lottery to speed up the result confirmation.

3) Distribution of Rewards and Penalties

Because of the introduction of the VRF algorithm, nodes are selected in a decentralized manner. Therefore, within a period of time, the probability of each honest node being selected and accepted as a submitter is similar. The fee paid to the group who processes and verifies oracle data request will be locked into the on-chain reward distribution contract, and the node operators can withdraw the reward fee allocated to them at any time. A malicious node may refuse to return a result to the on-chain contract, or return the wrong result, but because of the introduction Byzantine Agreement, malicious nodes will not pass the on-chain verification, and will be marked as an unqualified node according to a certain threshold, and will be fined a certain margin, this part of the margin will be burned. In this case, the node is excluded from the verification node candidates, unless the fined deposit is made up to continue normal operation. In addition, in order to prevent the problem of laziness for nodes, and to motivate participating nodes to provide better, low-latency network resources. If a certain time is exceeded, the current working group has no results returned, then the credibility of the nodes in the entire group will be affected. For a single node, if it exceeds a certain threshold, it will also be marked as unqualified nodes and will be punished economically as above.

4) Parallel Processing

For multiple requests that exist concurrently at the same time, the node group selection and processing verification are performed concurrently, so that the processing speed can be parallelized to facilitate the expansion of TPS. In this way, as the number of nodes increases, its TPS will be improved, and the higher the actual use of TPS, the greater the value of the entire system, and a positive feedback is formed.

3. Query Interface Integration

Users who query external data can use the query system provided by ZK-Oracle to query data. The system interface aggregates the data in the current valid data providers. And only when more than 2/3 of the effective data providers screened by the system provide such data, data value are valid. This ensures that the system can tolerate up to 1/3 of malicious data providers.