A new solution for off-chain Oracle data aggregation
In the DeFi ecosystem, lending, derivatives, and even trading are inseparable from oracles. Without Oracle, the DeFi ecosystem cannot be maintained. However, the current popularity of DeFi has caused abnormal congestion on the Ethereum network. On the contrary, the cost of using the oracle is very high, makes it not practical to use.
The reason is that the many oracles currently use on-chain data aggregation on the Ethereum, users not only pay for data services but also have to bear a large amount of gas fee.
The above picture shows the gas fee of data aggregation from an oracle. The fee for each transaction is as high as 13–25 US dollars, which seriously affects the availability of the oracle.
From a higher level, the request/response oracle (network) working process is as shown in the above picture:
-Users who need data from off-chain send data requests through a smart contract
-The oracle (network) sends a request to the external data source after receiving the data request
-The oracle (network) aggregates the data results
-The Oracle (network) finally responds to the user’s smart contract with the data
In response to this situation, in order to let oracle to enable the potential of smart contracts, we propose an off-chain data aggregation scheme based on VRF(verifiable random function)and BBFT (BBFT Bytom Byzantine Fault Tolerant).
1, Users send request
When users make a request to the oracle network, they need to deploy a smart contract with a standard template.
The contract will contain the requested data type, specific data, quotation, oracle staking requirements, number of oracles required, data aggregation scheme, request time, and other information.
The hash value of the above request information will be used as the RequestID as the proof of subsequent process.
2, The consensus committee receives the request
The oracle network is composed of 42 nodes in the initial stage, 10 of which form the consensus committee, and they take turns to lead the data consensus; the other 32 are oracle nodes. The oracle nodes and consensus committee nodes in the oracle network are generated decentralized, and the specific mechanism can be designed separately.
The consensus committee of the oracle network will monitor the data requests sent to the singularity network on each blockchain.
3, The consensus committee assigns tasks based on VRF (verifiable random function)
The Leader node in the consensus committee will randomly select a certain number of oracle nodes based on user requests (compared to the number of user requirements, 1.2 times the redundancy can be considered), and distribute data requests to them. In this process, other members of the consensus committee are responsible for verifying the randomness of node selection and the content broadcast by the Leader, and express their opinions in the subsequent consensus process. See the subsequent chapters for the specific plan.
4, Consensus Committee collects responses
After receiving the data request, the oracle node queries the data source for data. It can be suggested that a oracle node should have different data sources for the same data and provides relevant proofs, which will improve the competitiveness comparing other oracle nodes.
After obtaining the data, the oracle node will use a standard data template to report the data and RequestID to all consensus committee members.
5, Consensus committee aggregates data and reaches consensus
The Leader node will aggregate the collected responses according to the aggregation scheme required by the user, and lead the consensus committee to reach a consensus on the aggregation results.
The other members of the consensus committee can calculate by themselves based on the data they collect, verify the aggregation results, and express their opinions on the final aggregation results based on the supervision of the Leader’s behavior in the previous steps.
The consensus committee finally submits the aggregated unique data result to the user’s request contract (multi-signature/threshold signature), and distributes the remuneration for this service.
In the entire workflow, the consensus committee witnesses the whole process from data request to data aggregation. Each committee member can form his own judgment on the final data result. Therefore, as long as no more than 1/3 of the consensus nodes commit evil, they will finally pass BBFT(Bytom Byzantine Fault Tolerance) consensus. The mechanism of reaching a consensus on the results of data aggregation will also be effective.
This solution will greatly reduce the impact of the blockchain’s own network conditions on the oracle service, and improve the efficiency of data aggregation while reducing the cost of data aggregation.