Research Summary: Chainlink 2.0: Next Steps in the Evolution of Decentralized Oracle Networks

Hi @rncd, I think you bring up some good questions around the long-term vision of creating a decentralized metalayer. Such a layer of abstraction appears to consist of the collective sum of all the independent DONs, where each can be constructed to serve a particular use case. A hybrid contract can use the services provided by existing DONs, as well as launch their own DON, to meet their specific requirements. So in my opinion, it seems scaling the metalayer would entail launching additional DONs to provide more services for a larger collection of users.

By extending this definition of oracles, a metalayer really goes beyond data delivery to include any other capabilities that blockchains do not. A DON itself could operate in an entirely autonomous manner, such as reading the mempool for transactions and automatically fulfilling jobs as needed. Each DON could therefore have its own Overseer to change network parameters or automatically process requests using the original deployed design.

On the point about the incentive-based security and FSS, nodes who participate in DONs may provide a wide range of oracle services. I believe these diverse services can be taken into account with Future Fee Opportunity (FFO) within the Implicit Incentive Framework (IIF) where additional cryptoeconomic security is derived from the fees generated from providing oracle services. So the more services a DON node provides, the greater the amount of fees it can generate, leading to greater cryptoeconomic security as a whole. It would be interesting to see this quantified for each specific oracle service a DON could provide.

4 Likes

Incredible stuff everybody, really grateful to read all your thoughts.

For some additional reading on the capabilities of Chainlink, oracles in general, and their roles in blockchains and other systems:

Works like @tina1998612 summary of Liu, Bowen, and Pawel Szalachowski’s “A First Look into DeFi Oracles” provide us a snapshot of what the oracle landscape looked like in late 2019, and as somebody who works on the team of one of the oracle node operators mentioned in this work, I’m personally humbled to see how far we’ve come since then. @abdeljalil.beniiche’s summary of his paper, “A Study of Blockchain Oracles” and @andy’s summary of “Blockchain Oracles: A Framework for Blockchain-Based Applications” (Mammadzada, et al.) provide us useful frameworks for assessing the implementations of a given oracle, and the scope of their utility.

@Zach penned a lovely summary of the original Chainlink Whitepaper, which was written nearly 4 years ago. It’s exciting to look back and see what from that original vision has been executed, and how the scope of the capabilities of blockchain oracles has expanded.

  • The Mixicles Research Summary identifies how oracles can be used to enhance privacy and confidentiality in smart contracts while preserving auditability
  • The DECO Research Summary describes how oracles can be used to securely access sensitive data and execute smart contracts based on that data, without exposing it to the oracle or to other observers using existing TLS infra
  • As more offchain assets are used as collateral for onchain loans or other activities (See Maker’s collaboration with Centrifuge, allowing users to draw down DAI loans from real estate collateralized tokens) services like Proof of Reserves provide a valuable primitive for reliably reporting the supply of a given asset to its onchain, tokenized counterpart.
  • Chainlink’s Off-Chain Reporting Protocol (OCR) provides a nearly 90% reduction in gas costs for a network of oracle nodes to push a data point onchain, and provides the ability to scale the number of nodes in a network at a much lower cost than previous iterations.
  • Zach’s recent post, The Economic Scalability of Oracle Networks directly explores the positive effects of multiple users utilizing a given network of oracles.

Robust oracles are directly tackling big problems today, notably of course oracle exploits/flash loan attacks. MEV, Front-Running, etc are potentially problems oracles can tackle as well, and that’s discussed a bit further here. For more background on MEV, see SCRF Lead Researcher @Vishesh’s Research Summary of Flash Boys 2.0 (Daian, et al.)

5 Likes

5 posts were split to a new topic: Governance, Oracles and AI

I have read this white paper and thought it was a very excited idea, but I have a question about DECO.

Question about the 2 party computation (2PC) for computing kP^mac and kV^mac in the DECO paper (Fan Zhang et al., ACMCCS 2020, we checked the arXiv version (https://arxiv.org/abs/1909.00938[)](https://arxiv.org/abs/1909.00938))).

My question is how to implement F_2PC^hs in the actual DECO protocol. In Figure 6, the prover P and the verifier V respectively send zP and zV to F_2PC^hs that computes kP^mac and kV^mac. But F_2PC^hs is described as a trusted third party (TTP) because it receives secret values zP and zV, computes z=zP+zV, derives k^mac via PRF with z as the key, and divides k^mac into kP^mac and kV^mac such that k^mac=kP^mac + kV^mac. It seems assuming TTP is not a reasonable solution. I guess that a secure 2PC protocol is employed but no explanation is given as for as I checked the paper.

DECO is the core of Chainlink v2.0, so it is an area of great concern.

4 Likes

I just found out about this forum yesterday via the the Smart Contract Summit. I did a one page visual summary of the Chainlink 2.0 paper for myself, and I thought it might be useful to others. And, now that I know about this forum, I look forward to contributing and interacting in other threads as well.

6 Likes

Hello friends. Trust is the real capital of business. Many companies are trying to communicate and complete the smart contract chain so that they can be serious about auditing and transferring it. To control the time, its speed should not have security obstacles to deal with. I hope the y understand this for more cooperation and transparency :dove::handshake::dove: