X NEWThe Chainlink Fall 2021 Hackathon kicks off October 22. Sign up today.
X The Chainlink Fall 2021 Hackathon is happening now. Check it out.
INTRODUCTION The Basics Random Numbers API Calls Other Tutorials Basic Request Model Decentralized Data Model Off-Chain Reporting
USING DATA FEEDS Introduction to Data Feeds Get the Latest Price (EVM) Get the Latest Price (Solana) Historical Price Data Feed Registry API Reference ENS Ethereum Data Feeds Binance Smart Chain Data Feeds Polygon (Matic) Data Feeds xDai Data Feeds Huobi Eco Chain Data Feeds Avalanche Data Feeds Fantom Data Feeds Arbitrum Data Feeds Harmony Data Feeds Solana Data Feeds Optimism Data Feeds
USING RANDOMNESS Introduction to Chainlink VRF Get a Random Number API Reference Security Considerations Contract Addresses Best Practices
USING CHAINLINK KEEPERS Introduction Making Compatible Contracts Register Upkeep for a Contract Patterns and Best Practices Network Overview FAQs
USING ANY API Introduction to Using Any API Make a GET Request Make an Existing Job Request Multi-Variable Responses Large Responses Find Existing Jobs API Reference Contract Addresses
DEVELOPER REFERENCE Install Instructions LINK Token Contracts Developer Communications Getting Help Data Provider Nodes Hackathon Resources Contributing to Chainlink Install, configure & fund MetaMask Acquire testnet LINK Deploy your first contract Fund your contract Use your first contract!

Off-Chain Reporting

Suggest Edits

Off-Chain Reporting (OCR) is the next Oracle network upgrade replacing the FluxAggregator model. It represents a significant step towards increasing the decentralization and scalability of Chainlink networks.

See the OCR protocol paper for a technical deep dive.

Change Summary

In the FluxAggregator model, every node must submit their price value individually, and once all responses are received on-chain, the contract aggregates them to confirm the price.

This solution has been highly effective and reliable since its release. However, there are some drawbacks. Since every single node must submit a transaction per round, each pays gas to do so, with aggregation occurring on-chain once all nodes have submitted.

With our Off-Chain Reporting aggregators, all nodes communicate using a peer to peer network. During the communication process, a lightweight consensus algorithm is run, in which every single node reports its price observation and signs it. A single, aggregate transaction is then transmitted, saving a significant amount of gas.

The report contained in the aggregate transaction is signed by a quorum of oracles and contains all oracles' observations. By validating the report on-chain and checking the quorum's signatures on-chain, we preserve the trustlessness properties that many have come to expect from Chainlink oracle networks.

What is Off-Chain Reporting (OCR)?

A simple analogy

Imagine ordering 10 items from an online store. Each item is packaged separately and posted separately, meaning postage and packaging costs must be applied to each one, and the carrier has to transport 10 different boxes. This is how FluxAggregator works.

OCR, on the other hand, packages all of these items into a single box and posts that. This saves postage and packaging fees and all effort the carrier associates with transporting 9 fewer boxes.

The OCR protocol allows nodes to aggregate their observations into a single report off-chain using a secure P2P network. A single node then submits a transaction with the aggregated report to the chain. Each report consists of many nodes' observations and has to be signed by a quorum of nodes. These signatures are verified on-chain.

Since only one transaction is submitted per round, the following benefits are achieved:

  • Overall network congestion from Chainlink oracle networks is reduced dramatically
  • Individual node operators spend far less on gas costs
  • Node networks are more scalable because data feeds can accommodate more nodes
  • Data feeds can be updated in a more timely manner since each round needn't wait for multiple transactions to be confirmed before a price is confirmed on-chain.

This update is the third generation of Chainlink client that nodes support: the first being RunLog, the second being Flux Monitor, and the third being OCR. This increased redundancy means that Nodes have multiple battle-hardened failover protocols.

How does it work?

Protocol execution mostly happens off-chain over a peer to peer network between Chainlink nodes. The nodes regularly elect a new leader node who drives the rest of the protocol.

The leader regularly requests followers to provide freshly signed observations and aggregates them into a report. It then sends this report back to the followers and asks them to verify the report's validity. If a quorum of followers approves the report by sending a signed copy back to the leader, the leader assembles a final report with the quorum's signatures and broadcasts it to all followers.

The nodes then attempt to transmit the final report to the smart contract according to a randomized schedule. Finally, the smart contract verifies that a quorum of nodes signed the report and exposes the median value to consumers.

All nodes watch the blockchain for the final report to remove any single point of failure during transmission. If the designated node fails to get their transmission confirmed within a determined period, a round-robin protocol kicks in, such that other nodes also transmit the final report until one of them is confirmed.

How does this affect Data Feeds?

Subgraph users

Those using subgraph, make sure to either update the aggregator you're listening to once they go live, or preferably, move to ENS to make sure you're always using the correct address.

For smart contracts that currently consume data feeds, there will be no interruptions. Service will not be affected, and the functions described in the Data Feeds API Reference will continue to work.

The upgrade will happen automatically so long as your contracts are requesting data from the proxy addresses from August 2020 and listed both on our Contract Addresses page and ENS.