Direct request

Price Feeds: Direct Request / Runlog (DR)

The first iteration, and quite possibly the most adaptive Chainlink contract was the Direct Request, also referred to as Runlog, model.

This deployment methodology was not specifically designed for price feeds, rather it was designed to enable a wide range of data to be provided on-chain.
As such, it was easy to deploy and maintain, but it was not able to scale efficiently.
Once DeFi protocols started seeing significant levels of adoption, the number of Price Feeds as well as the rate at which they updated started to increase rapidly.

This following section will cover the history of the Direct Request Price Feeds, using the first ever contract ( ETH / USD) as the example.

---

The First Ever Price Feed: ETH / USD

The original ETH / USD Price Feed was deployed at address - 0x79fEbF6B9F76853EDBcBc913e6aAE8232cFB9De9

With transaction address - 0x9f2791fdc6b1654d593d3ce99a025c0da375541334e26d4ea9215c9cac8a933b

The first three node operators were

• Fiews
• Linkpool
• Chainlink

Fiews and Link Pool were community members that had made contributions to the Chainlink network before the mainnet launch.

Runlog contracts, also referred to as Direct Request contracts, require that an on-chain request be sent to each Chainlink Node Operator (how this operates is covered in more detail in the RunLog section of the wiki).

As a result of this requirement, the Chainlink Deviator / Utility Node was built. This Chainlink Node had just one purpose; to monitor the price of ETH / USD.  When the price of ETH / USD deviated above a specified threshold, a request was sent to each Node Operator's Oracle.sol contract. This triggered a job run on each of the Nodes, which resulted in an updated price on-chain.

---

Direct Request Operation

The timeline for these events is as follows:

• Deviator / Utility Node detects deviation greater than deviation threshold
  • Deviator / Utility Node Address: 0xd8Aa8F3be2fB0C790D3579dcF68a04701C1e33DB


• Deviator / Utility Node sends a request to each Chainlink Node's Oracle.sol contract
  • Fiews Oracle.sol Contract Address:0x049Bd8C3adC3fE7d3Fc2a44541d955A537c2A484
  • LinkPool Oracle.sol Contract Address: 0x240BaE5A27233Fd3aC5440B5a598467725F7D1cd
  • Chainlink Oracle.sol Contract Address: 0x89f70fA9F439dbd0A1BC22a09BEFc56adA04d9b4
  
  
• Each Node Operator's Chainlink Node detects the request event on-chain and the specified jobID is run
  • Fiews Job ID:        20c5fc81df974b6d812b3d0a829c8d7f, or in bytes32 0x20c5fc81df974b6d812b3d0a829c8d7f00000000000000000000000000000000
  • LinkPool Job ID:   c142042149f64911bb4698fb08572040, or in bytes32 0xc142042149f64911bb4698fb0857204000000000000000000000000000000000
  • Chainlink Job ID:  lost to the sands of time


• Each of the Chainlink Nodes then run the requested Job, which will get the price of ETH / USD from their respective data providers.  Once each node has an updated price, they will provide that value on-chain.
  • Once each Node Opertor responded on-chain the aggregated answer was recalculated.

---

If you are a more visual person, the below diagram may make more sense.

An important note, is that the diagram shows just one Chainlink Node, the ETH / USD price feed used three upon launch, then moved to support nine node operators.

---

Once all of the above took place, the price feed for ETH / USD was updated.

 

Price Feeds: Limitations of Direct Request / Runlog

While the Direct Request model was proven to be reliable and supports many more use cases beyond Price Feeds , it was not able to scale very well, and had a single point of failure – the Deviator / Utility Node.

 

Issues with Scaling

Each Chainlink Price Feed, with just three Node Operators, required at least 6 on-chain transactions.

This started exposing potential issues once Chainlink moved each Price Feed from three Node Operators up to nine, we saw that number of on-chain transactions increase to 18 for each update, for each price pair.

In times of high market volatility, such as [Black Thursday], we saw many people competing with Chainlink Node Operators to get transactions included in blocks.  This resulted in exorbitant transaction fees and very high levels of network congestion.

 

We can see that the Ethereum community was not enjoying the fact that they were competing with the Deviator / Utility node for blockspace.

<figure class="image"><img src="https://wiki.dextrac.com/eth-usd/screenshot_at_2022-02-21_10-55-52.png"></figure>

 

In addition to the number of transactions per-update, we also see that the Deviator / Utility Node is required to send a single request to each Node Operator's Oracle.sol contract.

This was another major cost for operating the Price Feeds, while also being a single point of failure.

 

Issues with Redundancy

With the initial deployment of the Price Feeds, Chainlink was required to manage and maintain the Deviator / Utility Node.

In this model, it was the only way to push requests to the Node Operators to update the ETH / USD price.  If the Deviator / Utility Node went offline, ran out of funds, or was rendered inoperable in any way, the Price Feeds would be unable to update.

This was known to be a point of failure, and addressing it was the highest priority for the team at Chainlink.

The solution?
FluxMonitor.

Chainlink ecosystem resources

XXTEXTXX

---

Timeline

Date	Media	Author	Title
N/A	Official Docs	Chainlink	Direct Request Jobs: Official Chainlink Documentation
XXXX	XXXX	XXXX	[]

Educational

Date	Media	Author	Title
XXXX	XXXX	XXXX	[]
XXXX	XXXX	XXXX	[]
XXXX	XXXX	XXXX	[]
XXXX	XXXX	XXXX	[]