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

[Sergey]

TL;DR

• Chainlink 2.0: Next Steps in the Evolution of Decentralized Oracle Networks presents a vision for the future of the Chainlink Network beyond its initial conception in the original Chainlink whitepaper.
• The whitepaper describes Decentralized Oracle Networks (DONs) as the technical foundation of Chainlink 2.0 that enables hybrid smart contracts by providing universal connectivity to external resources and scalable off-chain computation, aligning with the long-term vision of creating a Decentralized Metalayer.
• This expanded vision of the Chainlink Network and smart contract functionality focuses on seven key areas: hybrid smart contracts, abstracting away complexity, scaling, confidentiality, order-fairness, trust-minimization, and incentive-based (cryptoeconomic) security.

Citation

• Breidenbach, Lorenz, Christian Cachin, Benedict Chan, Alex Coventry, Steve Ellis, Ari Juels, Farinaz Koushanfar, Andrew Miller, Brendan Magauran, Daniel Moroz, Sergey Nazarov, Alexandru Topliceanu, Florian Tramèr, and Fan Zhang. “Chainlink 2.0: Next Steps in the Evolution of Decentralized Oracle Networks.” 15 Apr. 2021.

Link

• https://research.chain.link/whitepaper-v2.pdf

Core Research Question

• How can the functionality of oracle networks be broadened to provide a general-purpose, bidirectional, compute-enable interface between and among on-chain smart contracts and off-chain systems?

Background

• The oracle problem is the challenge of connecting smart contracts to off-chain resources due to the inherent security properties of the blockchain. This oracle problem exists for every blockchain network and smart contract platform.
• Decentralized Oracle Networks (DONs) are an approach to the oracle problem using a network of nodes which connect disparate on-chain and off-chain systems and allow for unidirectional or bidirectional communication.
• The original Chainlink whitepaper was published September 4, 2017 and was the first to introduce and describe the construction of a decentralized oracle network.
• The Chainlink mainnet launched May 30, 2019, initially on the Ethereum blockchain, and was the first in-production oracle network composed of independent oracle nodes.
• Off-chain computation describes the usage of an oracle network to perform computations off-chain whose execution on-chain is undesirable due to various factors such as costs, scalability, and privacy, therefore complementing blockchains.
• Committee-based consensus protocols describe a class of Byzantine Fault Tolerant (BFT) algorithms of known nodes achieving group consensus, a technology which predates blockchains.
• Decentralized Metalayer is the long-term vision presented by the Chainlink 2.0 whitepaper that aims to provide developers and users with a unified machine model that is seamlessly mapped onto decentralized resources.
• Hybrid Smart Contracts describe smart contracts which perform computations both on-chain and off-chain, resulting in the creation of decentralized applications that are more advanced than on-chain logic in isolation.
• Meta Contracts describe smart contracts operating entirely within a decentralized metalayer and can be considered a more evolved version of hybrid smart contracts.

Summary

• There is an increasingly expansive role for oracle networks beyond their original design of forwarding data on-chain, one in which oracles complement and expand new and existing blockchains by providing fast, reliable, and private connectivity and computation for smart contracts.
• To describe the future evolution of the Chainlink Network, a fresh definition of “Decentralized Oracle Networks” (DONs) is provided as a middleware layer that offers an interface for smart contracts to connect to off-chain resources and access efficient, decentralized off-chain computation.
• A DON is a network maintained by a committee of Chainlink nodes, which is rooted in a consensus protocol and can support an unlimited range of oracle functions chosen by the nodes. DONs explicitly support smart contracts running on a main chain, which can take the form of any existing or future blockchain.
• The paper covers the security model and goals of DONs, their interface and capabilities, examples of DON-powered decentralized services, Fair Sequencing Services to prevent front-running, the Transaction-Execution Framework for DONs syncing with a main chain, the methods of trust-minimization, deployment considerations, as well as defining the economics of the Chainlink Network and cryptoeconomic security through staking.
• The Chainlink 2.0 Whitepaper focuses on seven key advances including hybrid smart contracts, abstracting away complexity, scaling, confidentiality, order-fairness, trust-minimization, and incentive-based security.

Method

• DONs are first described by defining their security model and underlying components:
  • DONs are distinct distributed systems, initially planned to be implemented using committee-based BFT consensus protocols in order to augment the capabilities of smart contracts on existing blockchain networks.
  • DONs can be built upon either committee-based or permissionless consensus protocols, where deployers can choose to adopt either approach, following Chainlink’s existing heterogeneous network design.
  • DONs use a ledger data structure where, unlike blockchains, the ledger of a DON is not treated as a standalone system but instead is anchored to an existing blockchain network and aims to enhance that chain’s capabilities.
  • DONs provide networking, storage, and computation for smart contracts and achieve these properties through the usage of executables (continuously running deterministic code) and adapters (bi-directional interfaces to external resources).
    • Networking is achieved through adapters, which are a generalization of the adapters used in the Chainlink Network today. They are bidirectional and can send/receive data to and from blockchains, web servers, external storage, and other DONs.
    • Computation is achieved through executables, which is the basic unit of code on a DON consisting of an array of logic entry points and a corresponding array of initiators, which are analogous to the initiators used in the Chainlink Network today.
    • Storage is achieved through both the DON’s ledger and through external decentralized storage networks which are bridged by an adapter. Additionally, DONs can connect to traditional cloud providers for storage.

• The seven key design goals of DONs are described first in an initial overview and further explored throughout the paper. These include:
  • Hybrid Smart Contracts
    • The vision for the future of Chainlink centers on the idea of securely combining on-chain and off-chain components into hybrid smart contracts.
      • On-chain code is where cryptocurrency ownership is represented and provides robust anchors for decentralized services.
      • Purely on-chain contract code is limited and unable to connect to external data resources, confidential computation, or a secure source of randomness.
      • Adding an off-chain component through one or multiple DONs provides access to data feeds, randomness, off-chain computation, and more, creating a hybrid smart contract.
    • The other six goals aim to achieve this overarching vision of creating smart contracts that include on-chain / off-chain contract composition.
  • Abstracting Away Complexity:
    • Chainlink 2.0 aims to abstract away the complexity of creating hybrid smart contracts by leveraging DONs to fulfill the long-term vision of a decentralized metalayer which provides the following features:
      • Developers can construct their contract as a virtual application using a unified machine model.
      • A compiler can be used to automatically generate the on-chain smart contract and off-chain executable DON logic, which together instantiate the DApp.
    • Hybrid smart contracts are the first step toward meta contracts, which are applications coded on a decentralized metalayer that encompass on-chain logic as well as off-chain computation and connectivity.
  • Scaling:
    • Widely used existing permissionless blockchains have their bandwidth saturated, which has resulted in the launch of more performant chains and various layer-2 solutions, which require oracle networks that support low latency and high throughput.
    • DONs derive their performance through the use of fast, committee-based consensus protocols, which are combined with the permissionless blockchain and layer-2 networks they support, creating hybridization.
      • DONs leverage a transaction-execution framework (TEF) that performs the task of regularly syncing data from a DON to the main chain.
    • By concentrating transaction and oracle-report processing off-chain, the transaction throughput is increased, latency is decreased, and fees are reduced.
  • Confidentiality:
    • Blockchains provide a high degree of transparency, but this comes with the trade-off of disincentivizing data providers from publishing sensitive or proprietary data on-chain.
    • DONs provide a solution where the transparency of blockchains is combined with confidentiality protections:
      • Confidentiality-preserving adapters: DECO (zero knowledge proofs of TLS web session data) and Town Crier (trusted execution environments) are two technologies that enable oracle nodes to retrieve external data privately, thereby protecting user confidentiality.
      • Confidential computation: DONs can conceal information from blockchain networks by using secure multi-party computation and/or trusted execution environments to perform privacy-preserving computations on datasets.
      • Support for confidential layer-2 systems: DONs can support a variety of layer-2 solutions including those that leverage zero knowledge proofs to ensure transaction privacy.
  • Order-fairness for transactions:
    • Blockchains are ephemerally centralized in the sense that individual miners and validators can order transactions in any way they choose for their created block. Transaction order can also be manipulated by users changing the amount of fees they pay mining nodes.
      • A common adverse effect from transaction reordering is front-running, where a miner or a bot can observe transactions in the mempool and insert its own exploitive transaction in front to siphon value from the user.
    • Fair Sequencing Services (FSS), which can run on a DON, aims to address this problem by allowing smart contract developers to predefine ordering policies for their applications.
    • FSS introduces order-fairness and helps prevent front-running, back-running, and other related attacks on ordering of any type of transaction including oracle reports.
    • FSS enables this by using a DON to order transactions off-chain and forward them on-chain, which allows transactions to be ordered by time of arrival and lowers the transaction fees users need to pay.
  • Trust minimization:
    • DONs aim to provide a trustworthy layer of support for smart contracts and other oracle-dependent systems through decentralization, cryptographic tools, and cryptoeconomic security.
    • Users may prefer a trust model where the main chain is deemed more trustworthy than the DON itself. This model is supported through various optional trust-minimization mechanisms including:
      • Data source authentication, which uses cryptographic signatures to digitally sign data and prevent tampering.
      • DON minority reports, which allow a minority subset of DON nodes to report majority malfeasance of the network.
      • Guard rails, which use on-chain logic on the main chain to detect anomalous conditions like price deviations in order to pause contract execution.
      • Trust-minimized governance, which allows for community-inspected updates and decentralized emergency interventions.
      • Decentralized entity authentication, which leverages public-key infrastructure such as ENS to identify Chainlink nodes.
  • Incentive-based (cryptoeconomic) security:
    • While the above mechanisms ensure DONs continue to operate with an honest majority, it is equally important to ensure the majority of nodes remain honest.
    • This can be achieved through the use of cryptoeconomic incentives, which, in the context of the Chainlink Network, is derived from implicit incentives and explicit staking.
      • Implicit incentives are derived from future fee opportunity (FFO), where any malicious activity creates an opportunity cost of losing future fee revenue. These incentives exist in the Chainlink Network today.
      • Explicit staking is a mechanism through which nodes lock LINK tokens into a service agreement with predefined parameters, where the node’s stake can be slashed (taken away) for malicious behavior.
    • Explicit staking in the Chainlink Network has been designed with three key innovations:
      • A powerful adversarial model that encompasses attacks other systems do not protect against such as prospective bribery where bribed nodes are selected on a conditional basis, such as offering guaranteed bribes to nodes who are selected for specific roles.
      • Super-linear staking impact where an adversary must have a budget greater, by a quadratic factor in the number of nodes, than the combined deposits, increasing the cost of attack and providing more scalable economic security.
      • The Implicit-Incentive Framework (IIF), which defines the empirically measurable financial incentives beyond staking, such as FFO.
    • The combination of the IFF and super-linear explicit staking creates a virtuous cycle of economic security where as new fee-paying users enter the system, the marginal cost of economic security drops for future users, creating long-term sustainability for the Chainlink Network.

Results

• The Chainlink Network will broaden in functionality over time to achieve the long-term vision of a decentralized metalayer, by supporting the creation of hybrid smart contracts composed of on-chain and off-chain infrastructure.
• With this new scope of functionality, the Chainlink Network can achieve multiple oracle infrastructure upgrades that dramatically enhance the capabilities of existing and future blockchains, layer-2 networks, and web systems.
• The whitepaper lays out an ambitious vision, which begins with the development of increasingly advanced hybrid smart contracts and culminates with the creation of a robust, decentralized metalayer that opens up the long-term possibility of meta contracts.

Discussion and Key Takeaways

• The definition of Decentralized Oracle Networks (DONs) has significantly evolved since its conception in the 2017 Chainlink whitepaper. Initially described as a data transfer mechanism, DONs also encompass off-chain computation and an entire suite of trust-minimized, off-chain services to enhance blockchains.
• DONs enable a vast array of new smart contract use cases that were previously infeasible due to technical limitations around scalability, privacy, and connectivity of smart contracts that exist solely as on-chain code.

Implications and Follow-up

• The off-chain services powered by the Chainlink Network aim to provide significant benefits for the blockchain ecosystem, allowing complex operations to transition off-chain, lowering the computational burden placed on blockchain networks.
• The expansive functionality of DONs outlined in the paper may translate to increased adoption of existing blockchain-based ecosystems, as well as the creation of new categories of decentralized applications that leverage external connectivity, privacy, and scalability in new and unique ways.
• This whitepaper is a vision piece for the evolution of the Chainlink Network over time. More focused and technically-oriented papers may be released as new features and approaches evolve.

Applicability

• The advantages provided by Chainlink DONs are far-reaching for the blockchain ecosystem, as well as for existing Web 2.0 systems. Specific sectors of the smart contract ecosystem that may realize significant positive impact from expanded oracle infrastructure include DeFi, insurance, NFTs, gaming, and decentralized identity.
  • With off-chain computation, developers will be able to build hybrid smart contracts that combine the security and immutability properties of blockchain networks with the expressiveness and flexibility of off-chain web services.
  • With highly scalable DONs servicing blockchains and layer-2 networks, developers will be able to build advanced smart contracts that support the transaction throughput and low fees required for mass adoption of decentralized applications.
  • With extended connectivity, smart contract developers gain access to more decentralized data feeds that update on a more frequent basis, allowing for more advanced DeFi applications which expand beyond on-chain coded logic.
  • With privacy-preserving smart contracts, premium data providers can monetize their proprietary datasets and enterprises can maintain confidentiality of user data and trade agreements, all while leveraging the advantages of blockchain-based automation and security.

[patrickalphac]

DONs (Decentralized Oracle Networks) are going to be a massive step for the smart contract ecosystem. Quite excited about this. We’ve got a lot to do!

[Don_Orwell]

I want to congratulate to Sergey and whole Chainlink team and wish them all the best!!!

[Eric]

Cheers Don! I’m still wrapping my head around everything and am looking to share some more thoughtful feedback myself shortly here, but what are the initial developments that jump out to you, or surprise you?

[Rich]

There are a lot of pretty weighty implications here and I’m still processing some of them. Might be helpful to discuss some of the potential use cases we can think about. Having trouble narrowing them down, or perhaps the space is too wide to pigeon-hole?

In the Applicability section above it says DONs can service blockchains and layer-2 networks. Are there bright lines between the role of an L2 and a DON? It seems like a DON could be considered a bespoke, temporal L2.5… Is that accurate?

[Don_Orwell]

Cheers Eric, lots of information we knew from before (VRF, Fair sequencing), but the whole section 9 is new, things like super-linear staking and alerts, not to mention that somehow Chainlink whitepaper is full of my name :-) (DON). Hopefully Linkpool will fit nicely into the whole staking proposal.

[Granit23]

Congrats on this, seriously. Looking forward to reading more about super linear staking and looking into the code as this is developed.

[zube.paul]

@Sergey

Support for confidential layer-2 systems : DONs can support a variety of layer-2 solutions including those that leverage zero knowledge proofs to ensure transaction privacy.

Does this imply that DONs can act as an abstraction layer between chains? Can this be interpreted as a cross chain bridging solution? If so, how is custody handled in this model?

[jmcgirk]

I’m curious about the guard rails, and how to ensure data integrity. Can anomalies be detected externally or is the committee responsible for slashing outliers? Are there any special hardware requirements for running a DON? Does it require an enclave or TCE?

[zube.paul]

Welcome to SCRF, @Granit23! You mentioned you’re looking forward to looking into the code. Is there anything in particular that you’re looking for or that you’re looking forward to making use of?

[tjd233]

@jmcgirk this is a great question and it actually relates to one @Zach and I discussed a bit in the Off-Chain Reporting post about data integrity. During our conversation, @Zach summed up the idea of how data is ensured to be correct by stating the importance of staking:

I see explicit staking as a key aspect of scaling up network security in the medium to long term, particularly when the underlying smart contracts consuming this data begin to secure increasing amounts of value.

Chainlink 2.0 explicitly discusses how staking will be used as a way to ensure the data being reported by nodes is correct in section 9.4. Specifically, I want to draw attention to section 9.4.1 Further Mechanism Details starting on page 89.

Using the new bribery-resistant system all nodes will need to stake two different deposits; a deposit that can be slashed if disagreements are found and a “watchdog” deposit. This watchdog deposit seems to be a key aspect of ensuring data reported on DONs is accurate and correct. Essentially, this watchdog amount acts as a type of bounty for nodes to find and successfully report data errors being reported by other nodes.

If we look at Figure 16 we can see the general idea of how these staking deposits can be used to ensure data is reported properly, or how nodes can be rewarded if they report faulty data/incorrect nodes.

The figure shows that anyone attempting to maliciously influence other nodes to upload incorrect data must pay more than that of the potential rewards any one node may receive if they were to successfully report the malicious act/incorrect data. This economic incentive makes it so any purposeful data manipulation should be extremely expensive, and economically incentivizes nodes to report such instances.

In the comment chain I reference above regarding the security of OCR data, I purposed the idea that industries may come together to collude and provide false data in OCR reports. This specific bribery-resistant staking mechanism seems to address this issue, and helps ensure the data being uploaded is correct and accurate.

@Zach I’d love to hear your thoughts on the matter as well.

[Zach]

Thank you for the break down @Sergey! The cryptoeconomic security section is especially interesting to me given an adversary needs not just slightly more than the combined deposits like most staking implementations, but a budget quadratically greater amount of funds (as a function of the number of nodes) to successfully subvert a DON.

@tjd233, you are mostly correct here with your analysis in regards to significantly raising the cost of attack preventing data manipulation, but slightly off in regards to the watchdog deposit. The watchdog deposit is only slashed if an invalid alert is a created by a node (e.g. claimed the aggregate report was false when it was actually true). This prevents DoS attacks and false-positives from occurring. The regular stake a node deposits is what is slashed if they deliver false data (this stake is significantly greater than the watchdog stake).

Even more specifically, if the majority of nodes report a false data, then all those malicious nodes have all of their primary stake slashed. If only a minority of nodes report false data (and therefore doesn’t affect the final report), then they are only modestly slashed (e.g. 10x what their fee payment would have been, much less than their entire stake). This is conceptually similar to Ethereum 2.0’s staking mechanism where a large coordinated attack generates a larger penalty than when just a few nodes are wrong (which likely happens because of a configuration issue or honest mistake).

This incentivizes an even greater amount of stake to be deposited as nodes know if they have an isolated failure, then they will recoup the losses within the day, however if they become malicious and try to manipulate the final oracle report, then they will experience a significant economic consequence. It’s pretty brilliant in design and lead to greater decentralization of the network as a whole.

[Zelda]

Thank you very much for this breakdown, and congratulations to all contributors to the whitepaper. One can only be satisfied with this novel approach at staking, which seems to solve the sybil attack problem in an adequate fashion. I was wondering who will pay the fees on the transaction in case of a slashing event, as this might happen during times of high gas prices and as such could influence the profit that the slashing event can generate for a succesful alert.

[thelinkmarine]

Massive congratulations to the Chainlink team on this monumental step towards mass adoption of hybrid smart contract technology and a fairer world for everyone.

We’re all in this together!

[jyezie]

A bit of a general question for those who read/worked on the v1 and the v2:
what changed the most from the initial vision? What did you learn from the live network that affected that vision?

[rncd]

In the current architecture of Chainlink’s price feeds, the participants of the oracle network contributing to each price feed are predetermined and fixed. Questions that come to mind when I consider the impact of shifting Chainlink to what I think can be described as “offchain-computation-as-a-service” on a product such as price feeds:

With a shift to a DON architecture, what does the ETH-USD price feed look like in the future?

Will a DON still report a feed into an on-chain contract, as is the case today? Is it possible that a hybrid smart contract could abstract this function to fully offchain?

Is the DON reporting this data static? If no, how composable is the DON to requester requirements?

If there is a shift away from using a static DON toward a dynamically composed DON - or even a randomly composed DON - for a given job, how do you handle the selection of DON members and distribute the work?

It seems that the ultimate goal of this metalayer approach is to develop a network of nodes that perform a suite of offchain computations in both reactive and proactive service verticals. This approach implies that a component of the metalayer will be a data structure which acts as a foreman of sorts (possibly a structure that would live on the DON of DONs layer, a concept discussed briefly), tracking individual oracle capabilities/suitability to be included into a spontaneously-composed DON.

I am excited to see the ideas outlined in the paper begin to be implemented. I think the metalayer is necessary and elegant. Congrats to all involved.

[Sergey]

Thanks everyone for your congratulations and support around this expanded vision for Chainlink, we’re all really excited about it.

@rncd thanks for your thoughtful points and questions.

I think the long term future of price feeds will likely be driven by the DON’s users and their requirements to both continue using the DON and around whether they are willing to pay additional fees to the DON for greater security. I expect DONs will evolve based on two key factors; the need to provide additional security as the value secured by them continues to grow, and the ability for the DON to provide additional functionality that the users of the DON would find useful. Part of what Chainlink achieves is the creation of an efficient on-chain marketplace for very specific user demands about what a DON should do, and the ability for DONs to cater to those demands in an increasingly flexible, secure and privacy preserving manner, with consuming contracts having a guarantee of performance and node operators having a guarantee of payment for performance.

Selection of DON members is made easier in Chainlink through the on-chain reputation generated by them, which services like market.link and reputation.link already display some information for. Part of Chainlink’s unique value for generating DON’s is its ability to compose them based on the immutable proof about past performance retained around specific node operators.

The chainlink network is a complement/enabling technology for blockchains and L2s that house the smart contract code which needs to interact with key resources off-chain. Chainlink will continue to enable other blockchains and L2s, in order to expand the functionality of the smart contracts that operate in those environments.

I also think that DONs will place data into web 2.0 systems that require hyper reliable oracle reports to trigger events that they consider “mission critical”; events that need to be tamper-proof based on the value of the outcomes they secure. I do believe that polishing a system like Chainlink into something that meets the stringent requirements of Web 3.0 systems, will also make it attractive to Web 2.0 systems that have a similarly intense need for highly reliable off-chain computation and/or validated data delivery.

I also think the metalayer is necessary and will enable a redefinition of what blockchains are known for by enabling developers to easily create hybrid smart contracts.

Please note, beyond clarification of how existing features already work, all of my posts on SCRF are just one person’s opinion, stated here to engage in a dialogue with the larger research community, in an effort to test and improve my personal point of view. Whatever I write here is not a definitive statement about how Chainlink will evolve, which will be based much more on what we discover in working with actual smart contracts. I am excited about having an open creative dialogue, in order to arrive at a clearer and more accurate picture of reality.

[rncd]

I think the implications of the metalayer have been mostly glossed over in discussions so far. The “restructuring” of Chainlink’s existing and under-development services into this new organization, and the expansion of the software framework supporting them, imply a fundamental change in the way that existing layer 1/2 solutions will interact with the network.

The chainlink network is a complement/enabling technology for blockchains and L2s that house the smart contract code which needs to interact with key resources off-chain.

I think this describes the idea of the future metalayer best. Thinking aloud: So what happens when all of these node services, job initiation mechanisms, DON administration/clerical work, are consolidated into a unified new architecture? What does that look like? What does that mean for users of the network? How does it change how they interact with the network? What does scaling the metalayer imply?

Let’s assume that the Chainlink metalayer handles millions of transactions per day of varying types, pushing/pulling data to legacy systems and blockchains through native metacontracts, and opening and closing thousands of what I will call tickets - a future version of an ad-hoc job request. Clearly, the ticket administration aspect of this process will have to be automated. What component of the metalayer is responsible for self-organization? I will call this component the Overseer.

Imagine a hybrid Ethereum contract in which the offchain computation instruction component specifies a series of requirements for a DON job. The Overseer would be responsible for receiving and reading the ticket from the offchain component of the hybrid contract, handles the genesis and assembly of the DON, the distribution of the required instruction, and the dissolution (if necessary).

When I look at the staking diagram for the escalation of watchdog alerts, I see some of these same Overseer ideas reflected - where nodes act as administrators for others. So what would an Overseer consist of? It could be an application running on a set (or maybe superset) of nodes in the metalayer. It seems it would need a ledger or database containing information about itself in order to assign work correctly and respond to tickets.

I am making all of this up, but it is fun to think about autonomous distributed systems like this.

Ultimately, what I see being described in this paper is just that, a semi-autonomous blockchain accessory layer that performs a suite of offchain computation, data processing, and transfer services. If I had to bet on it, I would say that this metalayer evolves into a blockchain-like system.

Another thought: The description of assets at stake by a given node operator, $S≈$D+ $F+ $FS+ $R, may fall short of capturing the complete incentive picture of a metalayer node. There are separate classes of behavior within a node’s operational remit that in theory could affect a node’s incentive-based security. An example is a node providing FSS services in addition to participating in a price feed DON. Is FSS a tool that should be included when considering incentive-based security? Does a node’s participation in a given service such as FSS affect the way that incentive-based security should be considered for other services the node participates in? Fun questions to think about.

[Sean1992076]

I’m so excited coming to layer 2 such as Optimistic Rollups, Polkadot, Binance Smart Chain, Polygon(Matic layer 2 solutions), Avalanche, etc. Bringing Decentralized Oracle Networks(DON) to build up a new era of the Chainlink ecosystem.

I also think that Chiainlink 2.0 committee-based BFT consensus protocols need more discussion about the governance by algorithm especially the detail in the open and fair information transparence.

[B1tcoin]

Congratulations to the Chainlink team, I am very excited about the work being done and the clearer path for the future. =]