Distributed Price Oracle
When consumers request oracle services, the oracle may not respond in time for various reasons, resulting in a single point of failure. Therefore, ChainLink uses a distributed price oracle design to provide services to users. For example, a service that provides BTC USD prices aggregates 31 price oracles to provide services to users.
The contract source code of the aggregator can be viewed on Etherscan: https://etherscan.io/address/0xae74faa92cb67a95ebcab07358bc222e33a34da7#readContract
Among them, by calling the transmitters method in the contract, you can view all the off-chain oracles contained in the aggregator.
Each off-chain oracle can provide price data by calling the transmit method in response to the request of the user in the aggregator. These off-chain oracles are some EOA accounts, which not only provide price data for the BTC/USD aggregator, but also may provide price data for other aggregators, such as ETH/USD.
On-chain contracts:
1. First, read the current contract status and perform a series of checks:
2. After all these are passed, you can do some preparation work:
3. Next, use ecrecover() to verify the signature of each signed data and verify that the hash value is the hash of _report. At the same time, check whether the role of the signer is Signer and check the duplication of the signature.
4. Finally, check whether the observations are in order. Then select the median from the ordered observations and make sure that the median does not exceed the upper and lower thresholds. When everything is OK, record the answer of this oracle in s_transmissions. In addition, the answer must be verified:
Here, after a series of calls (with a Proxy contract in the middle), the validate method of the UniswapAnchoredView contract (the price oracle used by Compound) is finally called:
The key is to compare whether the price deviations given by the oracles on both sides are within a range:
Feed Registry
Although the above usage is simple, if you need the price of different tokens, you have to execute setPriceFeed for each token. The management cost is actually a bit high, and it is not very flexible for some scenarios. At this time, you can consider using the Feed Registry to access it.
Feed Registry can be simply understood as an aggregator of PriceFeeds. It has aggregated multiple priceFeeds. With it, users do not need to set up priceFeeds themselves, and can directly read price data through Feed Registry, as shown below:
Price Feed Mechanism
First, the price of the Price Feed is obtained through multiple levels of data aggregation. There are actually three data aggregation layers: data source aggregation, node operator aggregation, and oracle network aggregation.
The original price data mainly comes from centralized trading platforms such as Binance, Huobi, and Coinbase, as well as decentralized trading platforms such as Uniswap and Sushi. There are some service providers that specialize in data aggregation (such as amberdata and Coingecko), which collect the original price data from these trading platforms and process and integrate these data sources, such as weighted calculations based on trading volume, liquidity, and time difference.
This is the first level of aggregation, the aggregation of data sources. The key to having a reliable price data source is to have comprehensive market coverage to ensure that a price point represents an accurate aggregation of all trading environments, rather than the price of a single exchange or a few exchanges, to prevent data from being manipulated and price deviations from occurring.
The second layer is the aggregation done by Chainlink Node Operators. Each Chainlink Node Operator is mainly responsible for running the Chainlink core software used to obtain and broadcast external market data on the blockchain. Node Operators obtain price data from multiple independent data aggregation services and obtain the median between them, eliminating outliers and API downtime.
The last layer is the aggregation of the entire oracle network. There are many ways to aggregate, but the most common way is to take the median of the data when the number of responding nodes reaches the preset value. For example, there are 31 nodes in total, and the preset value is 21. That is, after receiving the responses of 21 nodes, the median of the price data of these nodes is taken as the final price. However, not every round of price results will be updated on the chain. It will only be updated when one of the two trigger parameters is met: Deviation Threshold and Heartbeat Threshold. Moreover, the values of these two parameters of different PriceFeeds may be different.
In summary, Chainlink price oracles are easy to access and have relatively high security, but because of the deviation threshold of its price update mechanism, price updates are relatively slow, ranging from a few minutes or tens of minutes to 24 hours. Therefore, it is generally only suitable for applications that are not very sensitive to price updates. This is also the limitation of Chainlink price oracles, and it cannot be applied in all scenarios.
This article was written by XiG (X account @SHXiGi ) of ZAN Team (X account @zan_team ).
