Actions

Flux monitor: Difference between revisions

From Chainlink Community Wiki

No edit summary
No edit summary
 
(2 intermediate revisions by one other user not shown)
Line 3: Line 3:
<p>The deployment and migration from Runlog to FluxMonitor was a major milestone.</p>
<p>The deployment and migration from Runlog to FluxMonitor was a major milestone.</p>
<p>The migration removed the high risks from the Price Feeds' dependence on the Deviator / Utility Node, while also significantly reducing operation costs.</p>
<p>The migration removed the high risks from the Price Feeds' dependence on the Deviator / Utility Node, while also significantly reducing operation costs.</p>
<p>This page will provide information regarding the history, architecture, and operation of FluxMonitor feeds.</p>
<h2>Migration to FluxMonitor: ETH / USD</h2>
<h2>Migration to FluxMonitor: ETH / USD</h2>
<p> '''06 Aug 20''': &nbsp;The ETH / USD [https://github.com/smartcontractkit/chainlink/blob/develop/contracts/src/v0.6/FluxAggregator.sol FluxAggregator.sol] contract was deployed at address  
<p> '''06 Aug 20''': &nbsp;The ETH / USD [https://github.com/smartcontractkit/chainlink/blob/develop/contracts/src/v0.6/FluxAggregator.sol FluxAggregator.sol] contract was deployed at address  
Line 17: Line 18:
<p>&nbsp;</p>
<p>&nbsp;</p>
<h2>FluxMonitor Operation</h2>
<h2>FluxMonitor Operation</h2>
<p>The operation of FluxMonitor feeds and all related contracts is rather complex, and outside the scope (Price Feed History) of this page. &nbsp;Please refer to Chainlink Contract Details for more information.</p>
<p>The more noticeable changes from migrating from RunLog to FluxMonitor contracts, were:</p>
<p>The important changes from migrating to FM contracts, were:</p>
<ul>
<ul>
   <li>The Deviator / Utility Node was no longer necessary.<ul>
   <li>The Deviator / Utility Node was no longer necessary.<ul>
Line 33: Line 33:
   </li>
   </li>
</ul>
</ul>
<p>&nbsp;</p>
<p></p>
 
== General Overview of Flux Monitor(FM) (v3) contract operation ==
(In the explanation below, we will be assuming a standard FM feed with 9 node operators)
 
Each node operator is assigned three data sources.  At a specified <code>pollingInterval</code>, each node will query their assigned data sources.  It will then take the median value that is returned from the multiple data sources and provide that value on-chain.
 
The below diagram illustrates a single Node Operator querying three data sources (CoinGecko, CoinMarketCap, and Nomics) for the price of ETH / USD.  The node then calculates the median of the values.
[[File:SingleNopDiagram.png|center|frameless|800x800px]]
Once a node has detected a price change that is greater than the <code>deviationThreshold</code> (deviation threshold is the minimum percentage change that a node operator must see in order to fire off a new round), it will respond on-chain to provide the new value to the FM contract.
 
This update will result in a new round request, a new submission, and a call to update the aggregator contract's available funds.  As illustrated in the image below, Nop00 has seen a price deviation greater than the deviation threshold, so it is writing to the FluxMonitor contract
[[File:FluxMonitorFirstNodeResponse.png|center|frameless|750x750px]]
In the image below, you can see the first response to a round, as it appears in Etherscan
[[File:EtherscanFMFirstNodeContractCalls.png|center|frameless|1000x1000px]]
Once the new round has been initiated, the other eight node operators will receive the request for an updated price.
 
Once the minimum number of nodes necessary to reach consensus have responded, each of them will update the aggregate value (<code>AnswerUpdated</code> event).
 
Every node that responds after consensus has been reached, will also call the <code>updateRoundAnswer</code> function to include their value in the aggregate.
 
As you can see in the image below, the response on the top not only submitted a response and update the available funds, but it also performed <code>AnswerUpdate</code>.
 
See [https://github.com/smartcontractkit/chainlink/blob/develop/contracts/src/v0.6/FluxAggregator.sol FluxAggregator contract] for how [https://github.com/smartcontractkit/chainlink/blob/91a62b2f93cff660ecfc26ac747965abfeced707/contracts/src/v0.6/FluxAggregator.sol#L733 NewRound], [https://github.com/smartcontractkit/chainlink/blob/91a62b2f93cff660ecfc26ac747965abfeced707/contracts/src/v0.6/FluxAggregator.sol#L850 AnswerUpdated], [https://github.com/smartcontractkit/chainlink/blob/91a62b2f93cff660ecfc26ac747965abfeced707/contracts/src/v0.6/FluxAggregator.sol#L899 SubmissionReceived], [https://github.com/smartcontractkit/chainlink/blob/91a62b2f93cff660ecfc26ac747965abfeced707/contracts/src/v0.6/FluxAggregator.sol#L887 AvailableFundsUpdated] events are emitted as a result of calls.
[[File:FMMultinodeResponses.png|center|frameless|950x950px]]
 
=== '''Summary of Contract Calls for Each FM Node:''' ===
'''Nop00:'''
 
<code>NewRound</code>
 
<code>SubmissionReceived</code>
 
<code>AvailableFundsUpdated</code>
 
'''Nop01:'''
 
<code>SubmissionReceived</code>
 
<code>AvailableFundsUpdated</code>
 
'''Nop02:'''
 
<code>SubmissionReceived</code>
 
<code>AvailableFundsUpdated</code>
 
'''Nop03:'''
 
<code>SubmissionReceived</code>
 
<code>AvailableFundsUpdated</code>
 
'''Nop04:'''
 
<code>SubmissionReceived</code>
 
<code>AvailableFundsUpdated</code>
 
<code>AnswerUpdated</code>
 
'''Nop05:'''
 
<code>SubmissionReceived</code>
 
<code>AvailableFundsUpdated</code>
 
<code>AnswerUpdated</code>
 
'''Nop06:'''
 
<code>SubmissionReceived</code>
 
<code>AvailableFundsUpdated</code>
 
<code>AnswerUpdated</code>
 
'''Nop07:'''
 
<code>SubmissionReceived</code>
 
<code>AvailableFundsUpdated</code>
 
<code>AnswerUpdated</code>
 
'''Nop08:'''
 
<code>SubmissionReceived</code>
 
<code>AvailableFundsUpdated</code>
 
<code>AnswerUpdated</code>
 
<h2>Price Feeds: Limitations of FluxMonitor</h2>
<h2>Price Feeds: Limitations of FluxMonitor</h2>
<h3>Issues with Scaling</h3>
<h3>Issues with Scaling</h3>
<p>While FluxMonitor was a n<i>major</i> increase in efficiency over the previous generation Runlog contracts, it was not efficient enough to accommodate for the incrasing number of transactions on the Ethereum network.</p>
<p>While FluxMonitor provided a <i>major</i> increase in efficiency over the previous generation Runlog contracts, it was not efficient enough to accommodate for the increasing number of transactions on the Ethereum network.</p>
<p>With the rapid adoption of DeFi in the summer of 2021, the blocks were filling up rapidly and the efficiency of FluxMonitor was not enough to keep up.</p>
<p>With the rapid adoption of DeFi in the summer of 2021, the blocks were filling up rapidly and the efficiency of FluxMonitor was not enough to keep up.</p>
<p>Each new round for each Price Feed still required on-chain transactions from each Node Operator. &nbsp;This meant that at times of high market volatility, each Price Feed was adding 9+ transactions to the mempool for each Price Feed.</p>
<p>Each new round, for each Price Feed still required on-chain transactions from each Node Operator. &nbsp;This meant that at times of high market volatility, each Price Feed was adding 9+ transactions to the mempool for each Price Feed.</p>
<p>As new DeFi protocols were launching with desire to support new tokens, more price feeds were necessary. &nbsp;FluxMonitor was not enough to meet the demand that Chainlink was experiencing.</p>
<p>As new DeFi protocols launched with a desire to support new tokens, more price feeds were needed. &nbsp;FluxMonitor was not enough to meet the demand that Chainlink was experiencing.</p>
<p>If only there were a way to reach consensus off-chain, without risk to the security of the Price Feeds…</p>
<p>If only there were a way to reach consensus off-chain, without risk to the security of the Price Feeds.  '''[[Offchain reporting]]'''.</p>
 
 
{{:flux_monitor_resources}}
{{:flux_monitor_resources}}
‎<references />
‎<references />

Latest revision as of 15:19, 29 April 2022

Price Feeds: FluxMonitor (FM)

The deployment and migration from Runlog to FluxMonitor was a major milestone.

The migration removed the high risks from the Price Feeds' dependence on the Deviator / Utility Node, while also significantly reducing operation costs.

This page will provide information regarding the history, architecture, and operation of FluxMonitor feeds.

Migration to FluxMonitor: ETH / USD

06 Aug 20:  The ETH / USD FluxAggregator.sol contract was deployed at address

and at transaction hash 0x1697d1bd5ab87a246571186262cf5111cb469b60b9798d70a1fe307d3252c76c

06 Apr 21:  The ETH / USD price feed was formally migrated from Runlog to FluxMonitor contracts.


As Chainlink is extremely risk-averse, they did not want to migrate all of their Price Feed contracts to the new FluxMonitor contracts without a backup plan.

If anything were to happen, the proxy contracts were each pointed at their respective FluxMonitor aggregator contracts.  If anything were to happen, the Chainlink team could fall back to the Runlog contracts in a matter of moments.

 

FluxMonitor Operation

The more noticeable changes from migrating from RunLog to FluxMonitor contracts, were:

  • The Deviator / Utility Node was no longer necessary.
    • Monitoring data sources for deviation was pushed out to each Node Operator.
      • If a single Node Operator detected deviation beyond the set threshold, a new round would be fired.
      • The Deviator / Utility Node was no longer a single point of failure.
    • The Deviator / Utility Node no longer sent transactions to each Node Opertor for every price update
      • This resulted in significantly reducing the cost of operating multiple Price Feeds

General Overview of Flux Monitor(FM) (v3) contract operation

(In the explanation below, we will be assuming a standard FM feed with 9 node operators)

Each node operator is assigned three data sources. At a specified pollingInterval, each node will query their assigned data sources. It will then take the median value that is returned from the multiple data sources and provide that value on-chain.

The below diagram illustrates a single Node Operator querying three data sources (CoinGecko, CoinMarketCap, and Nomics) for the price of ETH / USD. The node then calculates the median of the values.

SingleNopDiagram.png

Once a node has detected a price change that is greater than the deviationThreshold (deviation threshold is the minimum percentage change that a node operator must see in order to fire off a new round), it will respond on-chain to provide the new value to the FM contract.

This update will result in a new round request, a new submission, and a call to update the aggregator contract's available funds. As illustrated in the image below, Nop00 has seen a price deviation greater than the deviation threshold, so it is writing to the FluxMonitor contract

FluxMonitorFirstNodeResponse.png

In the image below, you can see the first response to a round, as it appears in Etherscan

EtherscanFMFirstNodeContractCalls.png

Once the new round has been initiated, the other eight node operators will receive the request for an updated price.

Once the minimum number of nodes necessary to reach consensus have responded, each of them will update the aggregate value (AnswerUpdated event).

Every node that responds after consensus has been reached, will also call the updateRoundAnswer function to include their value in the aggregate.

As you can see in the image below, the response on the top not only submitted a response and update the available funds, but it also performed AnswerUpdate.

See FluxAggregator contract for how NewRound, AnswerUpdated, SubmissionReceived, AvailableFundsUpdated events are emitted as a result of calls.

FMMultinodeResponses.png

Summary of Contract Calls for Each FM Node:

Nop00:

NewRound

SubmissionReceived

AvailableFundsUpdated

Nop01:

SubmissionReceived

AvailableFundsUpdated

Nop02:

SubmissionReceived

AvailableFundsUpdated

Nop03:

SubmissionReceived

AvailableFundsUpdated

Nop04:

SubmissionReceived

AvailableFundsUpdated

AnswerUpdated

Nop05:

SubmissionReceived

AvailableFundsUpdated

AnswerUpdated

Nop06:

SubmissionReceived

AvailableFundsUpdated

AnswerUpdated

Nop07:

SubmissionReceived

AvailableFundsUpdated

AnswerUpdated

Nop08:

SubmissionReceived

AvailableFundsUpdated

AnswerUpdated

Price Feeds: Limitations of FluxMonitor

Issues with Scaling

While FluxMonitor provided a major increase in efficiency over the previous generation Runlog contracts, it was not efficient enough to accommodate for the increasing number of transactions on the Ethereum network.

With the rapid adoption of DeFi in the summer of 2021, the blocks were filling up rapidly and the efficiency of FluxMonitor was not enough to keep up.

Each new round, for each Price Feed still required on-chain transactions from each Node Operator.  This meant that at times of high market volatility, each Price Feed was adding 9+ transactions to the mempool for each Price Feed.

As new DeFi protocols launched with a desire to support new tokens, more price feeds were needed.  FluxMonitor was not enough to meet the demand that Chainlink was experiencing.

If only there were a way to reach consensus off-chain, without risk to the security of the Price Feeds. Offchain reporting.

Flux Monitor resources

XXTEXTXX

Timeline

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

Educational

Date Media Author Title
N/A Official Docs Chainlink Flux Monitor Jobs - Official Chainlink Documentation
XXXX XXXX XXXX []
XXXX XXXX XXXX []
XXXX XXXX XXXX []

‎

Retrieved from "https://wiki.dextrac.com:3443/index.php?title=Flux_monitor&oldid=2364"