Aggregation of results and synthesis
Nodes and Oracle contracts
There are N Chainlink nodes instead of one. It is important to note that Chainlink nodes do not communicate/coordinate with each other off-chain, they are totally independent.
There are N Oracle contracts that each belong to their corresponding off-chain nodes. These are also independent from each other.
I talk about choosing an optimal N later.
The EWT/EUR Job
Each Node runs the following job:
}
],
"tasks":[
},
},
},
},
}
],
"startAt":null,
"endAt":null
}For this Job, no parametrization is done from the client contract to reduce on-chain message size. It is hardcoded to fetch the price from https://api.liquid.com/products/560, multiply it with 10000 and return the value in a transaction.
All of them are included in this shared GitHub gist, just import it to Remix as before at Part 1.: 21db5a581949c4ab7882add2bb0d5867.
The Aggregator contract is the heart of this whole operation. Chainlink provides a reference implementaion (Aggregator.sol) that can be modified and extended. The Aggregator contract also derives from ChainlinkClient.sol. How they work in general:
- The Aggregator usually maintains a list of Oracles and JobIDs. New ones can be added or removed similarly to any other permissioning contract.
- Whenever a request is made to the Aggregator, it forwards that request to all the Oracles, separately.
- The Aggregator pays for the Oracles. The Aggregator contract must own enough Chainlink tokens to work.
- The Oracles run the invoked jobs independently and return the answer in the Aggregator’s fallback function
- The Aggregator waits until a certain number of results are collected for a query, and then calculates a statistical value, e.g. mean or median, which is the final answer.
The Aggregator provided by Chainlink is just an example. It is expected that you modify it to your needs (result data types and co).
For this poc I use ExecutorPublicPriceAggregator.sol, which I developed only for this price oracle use case:
- It handles uint256 numbers instead of int256s.
- It can execute an arbitrary transaction as soon as enough results are collected. Enough results mean 3-out-of-5 Oracles replies here.
- Instead of the Aggregator paying, the requester has to approve the Aggregator to spend a certain amount of tokens in its name. If the requester doesn’t do it, the requests fail.
- It is meant to be a public price oracle infrastructure poc.
Let’s try it out!
Fetch the necessary contracts
In Remix just compile and add contracts on the following addresses. Copyable version here: https://gist.github.com/ngyam/6d1ffdc727eea2cfdc8636c53a12a677:
This was a little bit tricky. I wanted my PriceAggregator contract to be a public infrastructure, so how payments are made to the Oracle contracts? Who pays? The Aggregator is the ChainLink client contract, submitting requests with the “transferAndCall” function of the LinkToken. How can I make sure, that the user pays and e.g. I don’t have to continuously fill up the balance of the Aggregator in some tricky way? Or use some registry of users and their tabs? In the end I decided to simply use the “approve” feature of ERC-20 token contracts.
First, you have to check your Volta-Link token balance which you can do with the LinkToken contract’s “balanceOf” function. If you still need some more you can go back to Part 1 section 3 to see how to get some.
There is a convenience function “calculateRequestFee” in the Price Aggregator that returns how much you have to pay for 1 request, which is now basically the price of 5 individual Oracle requests.
Then go back to the LinkToken contract. With the “approve” function, approve some tokens for the Aggregator contract address, at least 1 request worth. Each time you make a request, the Aggregator tries to pay for the Oracle nodes in your name. If you didn’t approve enough to pay for a request, the call will fail.
Published at Thu, 28 Nov 2019 10:28:57 +0000
{flickr|100|campaign}
