aelf Oracle Episode 1: What is an oracle? How does it work?
Tags: Oracle, Blockchain, Aelf

aelf Oracle Episode 1: What is an oracle? How does it work? ælf Follow Sep 13 · 5 min read

Oracle may not be a common concept to the general, however, it is something of great importance to those who are deeply engaged with DeFi — oracle helps retrieve live token prices for the protocols.

So how this happens? There will be an oracle organization with around 10–20 nodes. The organization retrieves the token price on a certain exchange to its serving chain via a transaction. The transaction will be executed every an hour or two; or in some cases where the service fee is cheaper on certain chains, it can even be shortened to ten or twenty minutes. In this way, the DeFi contract can receive the price of certain trading pairs in exchanges.

Oracle can do more than this. In addition to currency price pairs, oracles play a key role in reserving proofs, generating random numbers, on-chain gaming, insurance, and many more. Intrinsically, it is a mechanism that transfers data in a reliable way. The reliability lies in the oracle organization.

All members in the oracle organization are obligated to have correct data. The mechanism is set in certain ways. Some nodes may have staked a large amount of token when joining the organization; some will lose money if making mistakes; some are managed under certain decentralized structure so that no one can falsify data; or to considerate it from a sustainable perspective, nodes will not give up their reputation for an immediate benefit.

The aelf mainnet officially deployed a series of contracts related to the oracle mechanism two weeks before the mainnet token swap. Two of the contracts are at the core, one static, and one moving. The Regiment contract is responsible for maintaining the oracle organization. The Oracle contract can trigger the entire process of the oracle mechanism itself.

Regiment Contract

Management of oracle organization is like the management of a Telegram group, this can also be seen in the interfaces.

Anyone can start a new organization through CreateRegiment. Once receiving new applications through JoinRegiment, an administrator adds new members to the organization and assigns more administrators through AddRegimentMember.

Oracle Contract

Initiate a Query

Inaugural processing of order marks all the members in oracle organization have begun to monitor the order events thrown on the chain, with the official data processing client provided by aelf.

The orders are called QueryCreated. They all come from the oracle query process created by the user using the Query method of the Oracle contract.

To create a query, the user needs to enter at least the three following data:

1. Designated_node_list: Specify which oracle organization (or which oracle nodes) will handle this query;

2. Payment: how many tokens the user is willing to pay for this query;

3. Query_info: The description of the off-chain data to be queried this time.

The other parameters are optional, for example,

1. callback_info can set the automatic callback scheme at the end of this query process;

2. Aggregator_contract_address and aggregate_option indicate how the data sets should be aggregated;

3. aggregate_threshold is used to manually count the number of data sets provided by the oracle organization in this query before the aggregation starts.

Submit the Enquiry Result — Commit

When the QueryCreated event could normally be pushed from rabbitmq, the oracle client will read the query_info field in the QueryCreated event. At this time, correspondent data will be generated accordingly.

Here is the structure of query_info:

Use ELF price as an example. In the query_info provided, the title is https://api.coincap.io/v2/assets/aelf, and the only data in options is data/priceUsd. The oracle client can choose the scheme according to the content of the title: construct an HttpClient to query the HTTPS link, and then select the value of data/priceUsd in the returned json data, and use this value to construct the Commit transaction.

Theoretically, the parameters of the Commit transaction constructed by the client itself contain two values:

1. query_id indicates which query event this Commit transaction is in response to；

2. data/priceUsd offers your own results for the query instructions in query_info.

We changed the second parameter to a hash value to prevent nodes from plagiarizing.

In the default implementation of the oracle client provided by the aelf team, the oracle node needs to submit the following things in the Commit transaction:

1. query_id;

2. data/priceUsd and a random number generated locally (“salt”), namely hash(data/priceUsd, salt). The salt needs to be saved by the oracle node itself, and it will be used later.

Confirm & Check the Aggregation Result — Reveal

The client could receive a preliminary request when the Commit transactions of all the oracle nodes are packaged, though the result is not yet known. At this point, the Oracle contract will automatically throw a new event: SufficientCommitmentsCollected. Once received, nodes will immediately respond and start the last step to complete the query: constructing a Reveal transaction.

The point of constructing the Reveal transaction is to explain where the second parameter of the Commit transaction sent by the oracle node comes from. From the original result, that is, the data/priceUsd in the above example, and the locally randomly generated and cached salt.

In sum, the parameters of the Reveal transaction consist of three fields: query_id, data, and salt. When most oracle nodes (at least equal to the aggregate_threshold set when the customer creates the query) use Reveal transactions to try to end the query, the query ends. Before it really ends, the Oracle contract will do two things: