Chainlink Oracle Series (Part 1)

In the blockchain field, Oracles are systems that can provide external information for on-chain smart contracts. As middleware connecting smart contracts and the world outside the blockchain, oracles play an extremely critical infrastructure role, with their primary function being to provide data for smart contracts on the blockchain.

For example, if we create a smart contract on the Ethereum network that needs to access crude oil trading volume data for a specific day. However, the smart contract itself cannot obtain such off-chain real-world data, so it needs to be achieved through oracles. In this case, the smart contract will write the required date's crude oil trading volume into an event log, and then an off-chain process will be started to monitor and subscribe to this event log. When the request in the transaction is detected, the process will upload the specified date's crude oil trading volume information to the smart contract by submitting an on-chain transaction and calling the contract's relevant method.

Data sourced from https://defillama.com/oracles

Chainlink

In blockchain, Chainlink oracles have the largest market share. Chainlink is a decentralized oracle project that provides data generated in the real world to blockchains in the most secure manner. On top of the basic oracle principle implementation, Chainlink has established a virtuous ecosystem through economic incentives around the LINK token. Chainlink oracles need to be triggered through LINK token transfers. LINK is an ERC 677 contract on the Ethereum network. The oracle functionality completed based on the LINK ERC 677 token belongs to the request/response mode.

The function implemented is to obtain the ETH/USD trading price from the specified API (cryptocompare). The parameters passed to the function are the specified oracle address and jobId. After organizing the request parameters, it calls the "sendChainlinkRequestTo" method to send the request. "sendChainlinkRequestTo" is an interface method defined in the Chainlink-provided library, defined as follows:

After receiving the transfer, the Oracle contract triggers the "onTokenTransfer" method, which checks the transfer's validity and records more detailed data information by emitting the "OracleRequest" event.

This log can be found in the oracle contract's logs. Off-chain nodes will subscribe to the log topic, parse the specific request information after obtaining the recorded log information, and retrieve the request results through API calls. Afterward, by submitting a transaction, it calls the "fulfillOracleRequest" method in the Oracle contract to submit the data on-chain.

After a series of verifications, this method will return the result to the consumer contract through the previously recorded callback address and callback function.

As a developer, can I just use existing trading pair prices without specifying these URLs?

The answer is yes. The first usage method, as shown in the official example code, is as follows:

First, each trading pair has a separate Price Feed, also called an Aggregator, which is essentially an AggregatorProxy, like this:

You can refer to the AAVE/ETH pair for the specific interface implementation: https://etherscan.io/address/0x6Df09E975c830ECae5bd4eD9d90f3A95a4f88012#code

There are a total of 5 query methods:

• decimals(): Returns the number of decimal places for the price data, generally 8 or 18

• description(): Usually the trading pair name, such as ETH / USD

• version(): Mainly used to identify the type of Aggregator pointed to by the Proxy

• getRoundData(_roundId): Obtain the price data at a specific round ID

• latestRoundData(): Obtain the latest price data

In most application scenarios, the contract may only need to read the latest price, i.e., calling the last method, where the "answer" in the returned parameters is the latest price.

Additionally, most applications read token prices uniformly in USD, and you'll find that pairs with USD as the pricing unit have a unified precision of 8 decimal places, so generally, there's no need to handle different precisions for different tokens.

This article was written by XiG (X account @SHXiGi) from the ZAN Team (X account @zan_team).