In the previous article, we looked at how oracle requests are executed, the consensus process for oracle nodes, and the supported protocols, filters, and responses. For the final article in the series on oracles, we’ll cover how the oracle network aims to decentralize and explore current progress into designing the economic model.

An oracle network serves to ensure the integrity of data by having multiple nodes execute requests, comparing the results together to determine a “correct” value. Although this is an important process, the final result may not be trusted unless the oracle nodes are also trusted.

This is achieved through decentralization, using multiple independent node operators to serve requests and reach consensus on the final result. This is intended to prevent entities from being able to control the outcome of requests, which improves the credibility of any results and provides security against malicious actors.

Policy contract

For the oracle network to operate as expected under decentralized conditions, a policy needs to be in place that defines the agreed upon rules and any values needed for operation (such as a base oracle request fee). The Neo3 oracle solution will use a native contract for this purpose, ensuring consistent behavior across all nodes.

This echoes the approach used to manage key parameters for consensus in the Neo3 blockchain. The core developer team considered extending the native policy contract with the fields needed for oracles. However, a vote on the topic suggests that a separate oracle policy contract will be created.

The oracle policy contract will provide a single reference for important information pertaining to the service, such as a list of oracle nodes, fees, and supported protocols or filters. The policy contract also provides the mechanism by which oracle nodes can be added or removed from the network.

Node election

For the oracle service to operate trustlessly, participating nodes must be selected in a decentralized manner. During conversations on the oracle node election process for Neo3, two main camps have emerged for its implementation.

The first camp promotes binding the oracle node election process to that of the Neo3 consensus node system. As explained by Mengyu Liu, an NGD software developer, this approach is simple to implement, reliable, and would piggyback on the decentralization of Neo itself. In this case, each oracle node would be required to operate (or elect) one or multiple oracle nodes. This approach simplifies the election process but places additional responsibility on consensus nodes.

The second proposal shows a preference for independent oracle nodes, controlled through a qualification and election process. As Stanislav Bogatyrev of NeoSPCC comments, the advantages of this approach are increased credibility and robustness of the network due to a more extensive spread of authorized third party nodes.

Using a separate election for oracle nodes in this manner also carries some downsides, such as increased complexity. Another potential trade-off was highlighted by NGD’s Wang Yong Qiang, who noted that although oracle election would be a group decision, a voter in the minority would likely have no desire to use the elected oracles.

Additionally, increasing the number of elections carries the risk of low user participation. This is especially true for an oracle network, where it is very difficult to prove an oracle node is Byzantine and therefore, should be actively voted out by users.

Discussions on the exact implementation of the oracle node election process are still ongoing. However, a vote between several approaches has shown a majority of core developers in favor of delegation of oracle node election to consensus nodes.

This could take the form of each consensus node being required to operate one or several oracle nodes. However, support was also strong for independent oracle nodes with the election process delegated to consensus nodes. In this case, it may be possible to leverage the advantages of both approaches.

Economic model

The economic model of the oracle system is another important component; if the reward for providing the service is not adequate, then conditions may arise where it is more profitable for nodes to be malicious rather than honest. In order to ensure the sustainability of the oracle network, a robust incentive model must be designed in accordance with game theory, which maximizes the payoffs for oracle nodes when acting honestly.

Mengyu Liu provided a summary of the current thinking on the economic model, chiefly concerned with fee calculation and reward distribution. In the post, Liu proposes a simple distribution model; sharing fees evenly to all oracle nodes. Although this can be efficiently implemented, but may result in free riders and does not specifically incentivize honest behavior.

Consideration has also been given to a penalty system, which would theoretically punish malicious nodes. However, due to the difficulty in proving that an oracle has returned incorrect data, such a mechanism may be quite complicated to implement.

Finally, the economic model must also provide a mechanism for preventing obvious attacks. For example, a system must be in place to avoid free requests, where users may underpay for the number of oracle executions.

This may happen due to the inability for a node to know the number of requests in a script before the script is executed. A fee may be paid for one request, however the script may contain multiple requests. Although the execution would end in a fault in this case, the node would still be forced to do unpaid work.

The proposed solution by Liu is to make use of an OracleFee field, calculated by multiplying the base fee per request by the total number of requests. The request count can be noted by the VM before requests are executed, and then decremented each time a request is completed. Once the request count reaches zero, oracle requests will not be executed and will fault.

In effect, this prevents the free request problem by using the OracleFee to define the maximum number of requests upfront. If an insufficient fee is paid, the oracle request will not be executed at all.

It should be noted that work on the economic model, as with all other aspects of the oracle solution, is still in development and subject to change in the future. The native Neo oracle service is expected to launch alongside the Neo3 MainNet, slated to occur during 2020.

Tags: