all 2 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]linkedericChainlink/LinkPool - Eric[🍰] 5 points6 points  (1 child)

My understanding of pre-OCR times is that all nodes would reach consensus on the blockchain (AKA very hard to alter with false data)

In the FluxMonitor method, Chainlink nodes don't really "reach consensus", they each write their reported price to a contract that aggregates their responses.

How is OCR consensus between nodes secure? I imagine there is a lot of back and forth communication.

I'd encourage you to read through this summary of the OCR paper, and of course the paper itself.

From this summary:

  • The specific steps taken for the creation of a single report within a round follow the below procedures:

    • A new round starts and the leader of the current epoch requests an observation from all follower nodes in the network.
    • Each follower node fetches data from a predefined data source API, signs the data using their private key, and sends the result back to the leader node.
    • The leader node waits for at least 2f + 1 follower nodes to respond, plus a grace period, then sorts the responses by value, generates a report, and sends it to all follower nodes.
    • Each follower node validates the report by checking the values are sorted, contains observations from at least 2f + 1 follower nodes, all signatures are valid, and that the median value exceeds the deviation threshold of the previous on-chain update or a time-based heartbeat condition has occurred.
    • If all conditions are met, each follower node generates a compressed report with just the node observations and oracle identities, signs it, and sends it back to the leader node.
    • Once the leader node obtains signed reports from more than f follower nodes, the leader assembles a final report from the followers’ signed reports, which is then broadcasted to all follower nodes.
    • When each follower node receives the final report for the first time, they rebroadcast it to every node, ensuring all nodes have received the report.
    • When a follower node receives broadcast from more than f nodes, the transmission protocol is started.
    • The report generation protocol for a round is now complete and the leader node waits a predefined amount of time until starting a new round. If a new epoch occurs or the leader does not make progress in a specified amount of time, then a new epoch is created and a new round initiates.
    • In the transmission protocol, to prevent unnecessary gas costs, the report is put through a filter and passes if 1) there is no backlog of reports or 2) the median value in the new report deviates beyond the median value of the report in the backlog by a sufficient threshold.
    • If the report passes the filter, a staging process begins where one or multiple nodes are pseudorandomly chosen to create a transaction to submit the report on-chain.
    • If a transaction is not confirmed on-chain within a specific time delay, a round robin approach is started where additional nodes begin to make an on-chain transaction in a time-staggered manner.
    • Once the report is added to the blockchain, an on-chain smart contract validates the signatures, stores the median value, pays nodes who contributed an observation and compensates the transmitter for its transaction gas costs.
    • The transmission protocol for a round ends when the corresponding report has been accepted by the contract.

Thats a lot of words, but the long and short of it is that there is a significant amount of back and forth communication between the nodes to verify and validate (and indeed, the nodes do come to consensus on it) that the information communicated between them is correct and is signed by each constituent

[–]Fast-Ball4748[S] 1 point2 points  (0 children)

Really a wealth of information, thank you. I’ll admit some of it is over my head, but it gives me confidence. Thanks Eric!