# Decentralized Data Model
Source: https://docs.chain.link/architecture-overview/architecture-decentralized-model
This page describes how data aggregation is applied to produce Chainlink Data Feeds and provides more insight as to how Data Feeds are updated.
## Data aggregation
Each data feed is updated by multiple, independent Chainlink oracle operators. The [AccessControlledOffchainAggregator](https://github.com/smartcontractkit/libocr/blob/master/contract/AccessControlledOffchainAggregator.sol) aggregates the data onchain.
Offchain Reporting (OCR) further enhances the aggregation process. To learn more about OCR and how it works, see the [Offchain Reporting](/architecture-overview/off-chain-reporting) page.
## Shared data resource
Each data feed is built and funded by the community of users who rely on accurate, up-to-date data in their smart contracts. As more users rely on and contribute to a data feed, the quality of the data feed improves. For this reason, each data feed has its own properties depending on the needs of its community of users.
## Decentralized Oracle Network
Each data feed is updated by a decentralized oracle network. Each oracle operator is rewarded for publishing data. The number of oracles contributing to each feed varies. In order for an update to take place, the data feed aggregator contract must receive responses from a minimum number of oracles or the latest answer will not be updated. You can see the minimum number of oracles for the corresponding feed at [data.chain.link](https://data.chain.link).
Each oracle in the set publishes data during an aggregation round. That data is validated and aggregated by a smart contract, which forms the feed's latest and trusted answer.
## Components of a Decentralized Oracle Network
Data Feeds are an example of a decentralized oracle network, and include the following components:
- [A consumer contract](#consumer)
- [A proxy contract](#proxy)
- [An aggregator contract](#aggregator)
To learn how to create a consumer contract that uses an existing data feed, read the [Using Data Feeds](/data-feeds/price-feeds) documentation.
### Consumer
A Consumer contract is any contract that uses Chainlink Data Feeds to consume aggregated data. Consumer contracts must reference the correct [`AggregatorV3Interface`](https://github.com/smartcontractkit/chainlink/blob/contracts-v1.3.0/contracts/src/v0.8/shared/interfaces/AggregatorV3Interface.sol) contract and call one of the exposed functions.
```solidity
...
AggregatorV3Interface feed = AggregatorV3Interface(address);
return feed.latestRoundData();
```
Offchain applications can also consume data feeds. See the Javascript and Python example code on the [Using Data Feeds](/data-feeds/price-feeds) page to learn more.
### Proxy
Proxy contracts are onchain proxies that point to the aggregator for a particular data feed. Using proxies enables the underlying aggregator to be upgraded without any service interruption to consuming contracts.
Proxy contracts can vary from one data feed to another, but the [`EACAggregatorProxy.sol` contract](https://github.com/smartcontractkit/chainlink/blob/contracts-v1.0.0/contracts/src/v0.6/EACAggregatorProxy.sol) on Github is a common example.
### Aggregator
An aggregator is the contract that receives periodic data updates from the oracle network. Aggregators store aggregated data onchain so that consumers can retrieve it and act upon it within the same transaction.
You can access this data using the Data Feed address and the [`AggregatorV3Interface` contract](https://github.com/smartcontractkit/chainlink/blob/contracts-v1.3.0/contracts/src/v0.8/shared/interfaces/AggregatorV3Interface.sol).
Aggregators receive updates from the oracle network only when the **Deviation Threshold** or **Heartbeat Threshold** triggers an update during an aggregation round. The first condition that is met triggers an update to the data.
- Deviation Threshold: A new aggregation round starts when a node identifies that the off-chain values deviate by more than the defined deviation threshold from the onchain value. Individual nodes monitor one or more data providers for each feed.
- Heartbeat Threshold: A new aggregation round starts after a specified amount of time from the last update.
---
# Data Feeds Architecture
Source: https://docs.chain.link/architecture-overview/architecture-overview
## Basic request model
Chainlink connects smart contracts with external data using its decentralized oracle network. Chainlink API requests are handled 1:1 by an oracle.
The [Basic Request Model](/architecture-overview/architecture-request-model) describes the onchain architecture of requesting data from a single oracle source.
To learn how to make a GET request using a single oracle, see [Make a GET Request](/any-api/get-request/introduction).
## Decentralized data model
For a more robust and trustworthy answer, you can aggregate data from many oracles. With onchain aggregation, data is aggregated from a decentralized network of independent oracle nodes. This architecture is applied to Chainlink Data Feeds, which can aggregate data such as asset price data.
The [Decentralized Data Model](/architecture-overview/architecture-decentralized-model) describes how data is aggregated, and how consumer contracts can retrieve this data.
## Offchain reporting
Offchain Reporting (OCR) is an improvement on the decentralization and scalability of Chainlink networks. With our Offchain Reporting aggregators, all nodes communicate using a peer to peer network. During the communication process, a lightweight consensus algorithm runs where each node reports its price observation and signs it. A single aggregate transaction is then transmitted, which saves a significant amount of gas.
To learn more about OCR and how it works, see the [Offchain Reporting](/architecture-overview/off-chain-reporting) page.
---
# Basic Request Model
Source: https://docs.chain.link/architecture-overview/architecture-request-model
## Contracts overview
All source code is open source and available in the [Chainlink Github repository](https://github.com/smartcontractkit/chainlink).
### ChainlinkClient
[`ChainlinkClient`](https://github.com/smartcontractkit/chainlink/blob/contracts-v1.3.0/contracts/src/v0.8/ChainlinkClient.sol) is a parent contract that enables smart contracts to consume data from oracles. It's available in the Chainlink smart contract library which can be [installed using the latest package managers](/resources/create-a-chainlinked-project).
The client constructs and makes a request to a known Chainlink oracle through the `transferAndCall` function, implemented by the LINK token. This request contains encoded information that is required for the cycle to succeed. In the `ChainlinkClient` contract, this call is initiated with a call to `sendChainlinkRequestTo`.
To build your own client contract using `ChainlinkClient`, see [Introduction to Using Any API](/any-api/introduction), or view the [ChainlinkClient API Reference](/any-api/api-reference) for the `ChainlinkClient` contract.
### LINK Token
LINK is an [ERC-677](https://github.com/ethereum/EIPs/issues/677) compliant token which implements `transferAndCall`, a function that allows tokens to be transferred whilst also triggering logic in the receiving contract within a single transaction.
Learn more about [ERC-677 and the LINK token](/resources/link-token-contracts).
### Operator Contract
[`Operator` contracts](https://github.com/smartcontractkit/chainlink/blob/contracts-v1.3.0/contracts/src/v0.8/operatorforwarder/Operator.sol) are owned by oracle node operators, which run alongside offchain oracle nodes.
#### Request
The client contract that initiates this cycle must create a request with the following items:
- The oracle address.
- The job ID, so the oracle knows which tasks to perform.
- The callback function, which the oracle sends the response to.
To learn about how to find oracles to suit your needs, see [Find Existing Jobs](/any-api/find-oracle).
Operator contracts are responsible for handling onchain requests made through the LINK token, by implementing `onTokenTransfer` as a `LinkTokenReceiver`. Upon execution of this function, the operator contract **emits an `OracleRequest` event** containing information about the request. This event is crucial, as it is monitored by the offchain oracle node which acts upon it.
#### Fulfillment
For fulfillment, the operator contract has a `fulfillOracleRequest` function which is used by the node to fulfill a request once it has the result of the job. This function returns the result to the `ChainlinkClient` using the callback function defined in the original request.
### Offchain oracle node
The offchain oracle node is responsible for listening for events emitted by its corresponding onchain smart contract. Once it detects an `OracleRequest` event, it uses the data emitted to perform a job.
The most common job type for a Node is to make a GET request to an API, retrieve some data from it, parse the response, convert the result into blockchain compatible data, then submit it in a transaction back to the operator contract, using the `fulfillOracleRequest` function.
For more information on how to become a node operator, learn how to [run a Chainlink node](/chainlink-nodes/v1/running-a-chainlink-node).
## Consumer UML
Below is a UML diagram describing the contract structure of `ATestnetConsumer`, a deployed example contract implementing `ChainlinkClient`.
---
# Offchain Reporting
Source: https://docs.chain.link/architecture-overview/off-chain-reporting
Offchain Reporting (OCR) is a significant step towards increasing the decentralization and scalability of Chainlink networks. See the [OCR Protocol Paper](https://research.chain.link/ocr3.pdf) for a technical deep dive.
For Offchain Reporting aggregators, all nodes communicate using a peer to peer network. During the communication process, a lightweight consensus algorithm runs where each node reports its data observation and signs it. A single aggregate transaction is then transmitted, which saves 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 onchain and checking the quorum's signatures onchain, we preserve the trustlessness properties of Chainlink oracle networks.
## What is OCR?
The OCR protocol allows nodes to aggregate their observations into a single report offchain 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 onchain.
Submitting only one transaction per round achieves the following benefits:
- 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 onchain.
## How does OCR work?
Protocol execution happens mostly offchain over a peer to peer network between Chainlink nodes. The nodes regularly elect a new leader node that 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 attempt to transmit the final report to the aggregator contract according to a randomized schedule. The aggregator verifies that a quorum of nodes signed the report and exposes the median value to consumers as an answer with a block timestamp and a round ID.
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 so other nodes can also transmit the final report until one of them is confirmed.