Chainlink: uma rede Oracle descentralizada

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

Von Steve Ellis, Ari Juels and Sergey Nazarov · 2017

🇺🇸 English (Original)

🇧🇷 Português (Übersetzung)

Abstract

In this whitepaper, we articulate a vision for the evolution of Chainlink beyond its initial conception in the original Chainlink whitepaper. We foresee an increasingly expansive role for oracle networks, one in which they complement and enhance existing and new blockchains by providing fast, reliable, and conﬁdentiality-preserving universal connectivity and oﬀ-chain computation for smart contracts. The foundation of our plan is what we call Decentralized Oracle Networks, or DONs for short. A DON is a network maintained by a committee of Chainlink nodes. It supports any of an unlimited range of oracle functions chosen for deployment by the committee. A DON thus acts as a powerful abstraction layer, oﬀering interfaces for smart contracts to extensive oﬀ-chain resources and highly eﬃcient yet decentralized oﬀ-chain computing resources within the DON itself. With DONs as a springboard, Chainlink plans to focus on advances in seven key areas: • Hybrid smart contracts: Oﬀering a powerful, general framework for augmenting existing smart contract capabilities by securely composing on-chain and oﬀ-chain computing resources into what we call hybrid smart contracts. • Abstracting away complexity: Presenting developers and users with simple functionality eliminates the need for familiarity with complex underlying protocols and system boundaries. • Scaling: Ensuring that oracle services achieve the latencies and throughputs demanded by high-performance decentralized systems. • Conﬁdentiality: Enabling next-generation systems that combine blockchains’ innate transparency with strong new conﬁdentiality protections for sensitive data. • Order-fairness for transactions: Supporting transaction sequencing in ways that are fair for end users and prevent front-running and other attacks by bots and exploitative miners. • Trust-minimization: Creating a highly trustworthy layer of support for smart contracts and other oracle-dependent systems by means of decentralization, strong anchoring in high-security blockchains, cryptographic techniques, and cryptoeconomic guarantees. • Incentive-based (cryptoeconomic) security: Rigorously designing and robustly deploying mechanisms that ensure nodes in DONs have strong economic incentives to behave reliably and correctly, even in the face of wellresourced adversaries. We present preliminary and ongoing innovations by the Chainlink community in each of these areas, providing a picture of the broadening and increasingly powerful capabilities planned for the Chainlink network.

Resumo

Neste whitepaper, articulamos uma visão para a evolução do Chainlink além de sua concepção inicial no whitepaper Chainlink original. Nós prevemos um papel cada vez mais expansivo para redes oracle, no qual elas complementam e aprimoram blockchains existentes e novos, fornecendo serviços rápidos, confiáveis e conectividade universal que preserva a confidencialidade e computação fora da cadeia para smart contracts. A base do nosso plano é o que chamamos de Redes Oracle Descentralizadas, ou DONs para abreviar. Um DON é uma rede mantida por um comitê de Chainlink nós. Ele suporta qualquer uma de uma gama ilimitada de funções oracle escolhidas para implantação pelo comitê. Um DON atua, portanto, como uma poderosa camada de abstração, oferecendo interfaces para smart contracts para extensos recursos off-chain e altamente recursos de computação off-chain eficientes, porém descentralizados, dentro do próprio DON. Tendo DONs como trampolim, Chainlink planeja focar em avanços em sete áreas principais: • smart contracts híbridos: oferecendo uma estrutura geral e poderosa para aumentar os recursos smart contract existentes, compondo com segurança na cadeia e recursos de computação fora da cadeia no que chamamos de smart contracts híbridos. • Abstraindo a complexidade: apresentando aos desenvolvedores e usuários soluções simples funcionalidade elimina a necessidade de familiaridade com processos subjacentes complexos protocolos e limites do sistema. • Dimensionamento: garantir que os serviços oracle atinjam as latências e taxas de transferência exigido por sistemas descentralizados de alto desempenho. • Confidencialidade: Habilitando sistemas de próxima geração que combinam blockchains’ transparência inata com novas e fortes proteções de confidencialidade para informações confidenciais dados. • Justiça de pedidos para transações: apoiando o sequenciamento de transações de várias maneiras que sejam justos para os usuários finais e evitem ataques front-running e outros ataques por bots e mineradores exploradores. • Minimização da confiança: criação de uma camada de suporte altamente confiável para smart contracts e outros sistemas dependentes de oracle por meio de descentralização, forte ancoragem em blockchains de alta segurança, criptografia técnicas e garantias criptoeconômicas. • Segurança (criptoeconômica) baseada em incentivos: projetar rigorosamente e implantar mecanismos robustos que garantam que os nós em DONs tenham fortes incentivos econômicos para se comportarem de maneira confiável e correta, mesmo diante de adversários com bons recursos. Apresentamos inovações preliminares e contínuas da comunidade Chainlink em cada uma dessas áreas, fornecendo uma imagem da expansão e cada vez mais recursos poderosos planejados para a rede Chainlink.

Introduction

Blockchain oracles are often viewed today as decentralized services with one objective: to forward data from oﬀ-chain resources onto blockchains. It’s a short step, though, from forwarding data to computing on it, storing it, or transmitting it bidirectionally. This observation justiﬁes a much broader notion of oracles’ functionality. So too do the growing service requirements of smart contracts and increasingly multifaceted technologies that rely on oracle networks. In short, an oracle can and will need to be a general-purpose, bidirectional, compute-enabled interface between and among onchain and oﬀ-chain systems. Oracles’ role in the blockchain ecosystem is to enhance the performance, functionality, and interoperability of smart contracts so that they can bring new trust models and transparency to a multiplicity of industries. This transformation will come about through broadening use of hybrid smart contracts, which fuse blockchains’ special properties with the unique capabilities of oﬀ-chain systems such as oracle networks and thereby achieve far greater reach and power than on-chain systems in isolation. In this whitepaper, we articulate a vision for what we call Chainlink 2.0, an evolution of Chainlink beyond its initial conception in the original Chainlink whitepaper [98]. We foresee an increasingly expansive role for oracle networks, one in which they complement and enhance existing and new blockchains by providing fast, reliable, and conﬁdentiality-preserving universal connectivity and computation for hybrid smart contracts. We believe that oracle networks will even evolve to become utilities for exporting high-integrity blockchain-grade data to systems beyond the blockchain ecosystem. Today, Chainlink nodes run by a diverse set of entities come together in oracle networks to relay data to smart contracts in what are known as reports. We can view such oracle nodes as a committee similar to that in a classical-consensus blockchain [72], but with the goal of supporting existing blockchains, rather than providing freestanding functionality. With veriﬁable random functions (VRF) and Oﬀ-Chain Reporting (OCR), Chainlink is already evolving toward a general-purpose framework and infrastructure for providing the computational resources that smart contracts require for advanced functionality. The foundation of our plan for Chainlink 2.0 is what we call Decentralized Oracle Networks, or DONs for short. Since we introduced the term “oracle network” in the original Chainlink whitepaper [98], oracles have developed ever richer functionality and breadth of application. In this paper, we oﬀer a fresh deﬁnition of the term according to our future vision for the Chainlink ecosystem. In this view, a DON is a network maintained by a committee of Chainlink nodes. Rooted in a consensus protocol, it supports any of an unlimited range of oracle functions chosen for deployment by the committee. A DON thus acts as a blockchain abstraction layer, providing interfaces to oﬀ-chain resources for both smart contracts and other systems. It also provides access to highly eﬃcient yet decentralized oﬀ-chain computing resources. In general, a DON supports operations on a main chain. Its goal is to enable secure and ﬂexi-

ble hybrid smart contracts, which combine on-chain and oﬀ-chain computation with connection to external resources. We emphasize that even with the use of committees in DONs, Chainlink itself remains inherently permissionless. DONs act as the foundation of a permissionless framework in which nodes can come together to implement custom oracle networks with their own regimes for node inclusion, which may be permissioned or permissionless. With DONs as a foundation, we plan to focus in Chainlink 2.0 on advances in seven key areas: hybrid smart contracts, abstracting away complexity, scaling, conﬁdentiality, order-fairness for transactions, trust minimization, and incentive-based (cryptoeconomic) security. In this paper introduction, we present an overview of Decentralized Oracle Networks in Section 1.1 and then our seven key areas of innovation in Section 1.2. We describe the organization of the rest of this paper in Section 1.3. 1.1 Decentralized Oracle Networks Decentralized Oracle Networks are designed to enhance and extend the capabilities of smart contracts on a target blockchain or main chain through functions that are not available natively. They do so by providing the three basic resources found in computing systems: networking, storage, and computation. A DON aims to oﬀer these resources with strong conﬁdentiality, integrity, and availability properties,1 as well as accountability. DONs are formed by committees of oracle nodes that cooperate to fulﬁll a speciﬁc job or choose to establish a long-lived relationship in order to provide persistent services to clients. DONs are designed in a blockchain-agnostic way. They promise to serve as a powerful and ﬂexible tool for application developers to create oﬀ-chain support for their smart contracts on any supported main chain. Two types of functionalities realize the capabilities of a DON: executables and adapters. Executables are programs that run continuously and in a decentralized manner on the DON. While they do not directly store main-chain assets, they have important beneﬁts, including high performance and the ability to perform conﬁdential computation. Executables run autonomously on a DON and perform deterministic operations. They work in hand with adapters that link the DON to external resources and may be called by executables. Adapters, as we envision them for DONs, are a generalization of the external adapters in Chainlink today. While existing adapters typically only fetch data from data sources, adapters may operate bidirectionally; in DONs, they may additionally leverage joint computation by DON nodes to achieve additional features, such as encrypting reports for privacy-preserving consumption by an executable. To provide a sense of a DON’s basic operation, Fig. 1 shows conceptually how a DON might be used to send reports to a blockchain and thus achieve traditional, existing oracle functionality. DONs can provide many additional features, however, beyond 1The “CIA triad” of information security [123, p. 26, §2.3.5].

Conceptual figure showing how a Decentralized Oracle Network can realize basic oracle functionality by relaying off-chain data to a contract

Chainlink’s existing networks. For example, within the general structure of Fig. 1, the executable could record fetched asset-price data on the DON, using such data to compute, e.g., a trailing average for its reports. Figure 1: Conceptual ﬁgure showing as an example how a Decentralized Oracle Network can realize basic oracle functionality, i.e., relay oﬀ-chain data to a contract. An executable uses adapters to fetch oﬀ-chain data, which it computes on, sending output over another adapter to a target blockchain. (Adapters are initiated by code in the DON, represented by small blue boxes; arrows show the direction of data ﬂow for this particular example.) The executable can additionally read and write to local DON storage to keep state and/or communicate with other executables. Flexible networking, computation, and storage in DONs, all represented here, enable a host of novel applications. A major beneﬁt of DONs is their ability to bootstrap new blockchain services. DONs are a vehicle by which existing oracle networks can quickly stand up service applications that would today require the creation of purpose-built networks. We give a number of examples of such applications in Section 4. In Section 3, we provide more details on DONs, describing their capabilities in terms of the interface they present to developers and users. 1.2 Seven Key Design Goals Here we brieﬂy review the seven key focuses enumerated above for the evolution of Chainlink, namely:

Hybrid smart contracts: Central to our vision for Chainlink is the idea of securely combining on-chain and oﬀ-chain components in smart contracts. We refer to contracts realizing this idea as hybrid smart contracts or hybrid contracts.2 Blockchains are and will continue to play two critical roles in decentralized-service ecosystems: They are both the loci where cryptocurrency ownership is represented and robust anchors for decentralized services. Smart contracts must therefore be represented or executed on chain, but their on-chain capabilities are severely limited. Purely on-chain contract code is slow, expensive, and insular, unable to beneﬁt from real-world data and a variety of functionalities that are inherently unachievable on chain, including various forms of conﬁdential computation, generation of (pseudo)randomness secure against miner / validator manipulation, etc. For smart contracts to realize their full potential therefore requires smart contracts to be architected with two parts: an on-chain part (which we typically denote by SC) and an oﬀ-chain part, an executable running on a DON (which we typically denote by exec). The goal is to achieve a secure composition of on-chain functionality with the multiplicity of oﬀ-chain services that DONs aim to provide. Together, the two parts make up a hybrid contract. We present the idea conceptually in Fig. 2. Already today, Chainlink services3 such as data feeds and VRFs are enabling otherwise unachievable smart contract applications, ranging from DeFi to fairly generated NFTs to decentralized insurance, as ﬁrst steps toward a more general framework. As Chainlink services expand and grow more performant according to our vision in this whitepaper, so too will the power of smart contract systems across all blockchains. Our other six key focuses in this whitepaper may be viewed as acting in the service of the ﬁrst, overarching one of hybrid contracts. These focuses involve removing visible complexity from hybrid contracts, creating additional oﬀ-chain services that enable the construction of ever more capable hybrid contracts, and, in the case of trust minimization, bolstering the security properties achieved by hybrid contracts. We leave the idea of hybrid contracts implicit throughout much of the paper, but any combination of MAINCHAIN logic with a DON may be viewed as a hybrid contract. Abstracting away complexity: DONs are designed to make use of decentralized systems easy for developers and users by abstracting away the often complex machinery behind DONs’ powerful and ﬂexible array of services. Existing Chainlink services already have this feature. For example, data feeds in Chainlink today present onchain interfaces that do not require developers to concern themselves with protocollevel details, such as the means by which OCR enforces consensus reporting among a 2The idea of on-chain / oﬀ-chain contract composition has arisen previously in various constrained forms, e.g., layer-2 systems, TEE-based blockchains [80], etc. Our goal is to support and generalize these approaches and ensure that they can encompass oﬀ-chain data access and other key oracle services. 3Chainlink services comprise a variety of decentralized services and functionality available through the network. They are oﬀered by the numerous node operators composed into various oracle networks across the ecosystem.

Conceptual figure depicting on-chain and off-chain contract composition in a hybrid smart contract architecture

Figure 2: Conceptual ﬁgure depicting on-chain / oﬀ-chain contract composition. A hybrid smart contract 3⃝consists of two complementary components: an on-chain component SC 1⃝, resident on a blockchain, and an oﬀ-chain component exec 2⃝that executes on a DON. The DON serves as a bridge between the two components as well as connecting the hybrid contract with oﬀ-chain resources such as web services, other blockchains, decentralized storage, etc. decentralized set of nodes. DONs go a step further in the sense that they expand the range of services for which Chainlink can oﬀer developers an abstraction layer with accompanying streamlined interfaces for high-level services. We present several application examples in Section 4 that highlight this approach. We envision enterprises, for instance, using DONs as a form of secure middleware to connect their legacy systems to blockchains. (See Section 4.2.) This use of DONs abstracts away the complexity of general blockchain dynamics (fees, reorgs, etc.). It also abstracts away the features of speciﬁc blockchains, thereby enabling enterprises to connect their existing systems to an ever-broadening array of blockchain systems without a need for specialized expertise in these systems or, more generally, in decentralizedsystems development. Ultimately, our ambition is to push the degree of abstraction achieved by Chainlink to the point of implementing what we refer to as a decentralized metalayer. Such a layer would abstract away the on-chain / oﬀ-chain distinction for all classes of developers and users of DApps, allowing seamless creation and use of decentralized services.

To simplify the development process, developers could specify DApp functionality in the metalayer as a virtual application in a uniﬁed machine model. They could then use a decentralized-metalayer compiler to instantiate the DApp automatically as a set of interoperating decentralized functionalities spanning blockchains, DONs, and external services. (One of these external services could be an enterprise system, making the metalayer useful for applications involving legacy enterprise systems.) Such compilation is akin to how modern compilers and software-development kits (SDKs) support generalist programmers in using the full potential of heterogeneous hardware architectures consisting of a general-purpose CPU and specialized hardware like GPUs, machine-learning accelerators, or trusted enclaves. Fig. 3 presents this idea at a conceptual level. Hybrid smart contracts are a ﬁrst step along the way to this vision and to a concept we call meta contracts. Meta contracts are applications coded on a decentralized metalayer and implicitly encompass on-chain logic (smart contracts), as well as oﬀchain computation and connectivity among various blockchains and existing oﬀ-chain services. Given the need for language and compiler support, new security models, and conceptual and technical harmonization of disparate technologies, however, realization of a true decentralized metalayer is an ambitious goal to which we aspire over a long time horizon. It is nonetheless a helpful ideal model to keep in mind while reading this paper, not detailed here, but something we plan to focus on in our future work on Chainlink. Scaling: A goal of preeminent importance in our evolving designs is enabling the Chainlink network to meet the growing scaling needs of the blockchain ecosystem. With network congestion becoming a recurring problem in existing permissionless blockchains [86], new and more performant blockchain designs are coming into use, e.g., [103, 120, 203], as well as complementary layer-2 scaling technologies, e.g., [5, 12, 121, 141, 169, 186, 187]. Oracle services must achieve latencies and throughputs that meet the performance demands of these systems while minimizing on-chain fees (e.g., gas costs) for contract operators and ordinary users alike. With DONs, Chainlink functionality aims to go further and deliver performance high enough for purely webbased systems. DONs derive much of their performance gain from their use of fast, committeebased or permissionless consensus protocols, which they combine with the blockchains they support. We expect many DONs with diﬀerent conﬁgurations to run in parallel; diﬀerent DApps and users can navigate tradeoﬀs in underlying consensus choices according to their application requirements. DONs may be viewed in eﬀect as layer-2 technologies. We expect that among other services, DONs will support the Transaction Execution Framework (TEF), which facilitates eﬃcient integration of DONs and thus oracles with other high-performance layer-2 systems—e.g., rollups, systems which bundle transactions oﬀchain to achieve performance improvements. We introduce the TEF in Section 6.

Conceptual figure showing ideal realization of a decentralized metalayer that abstracts blockchain and DON complexity

Figure 3: Conceptual ﬁgure showing ideal realization of a decentralized metalayer. For ease of development, a developer speciﬁes a DApp, highlighted in pink, as a virtual application in a uniﬁed machine model. A decentralized-metalayer compiler automatically generates corresponding interoperating functionalities: smart contracts (denoted by SC), logic (denoted by exec) on DONs, adapters connecting to target external services, and so forth, as indicated in yellow highlight. Fig. 4 shows conceptually how DONs improve blockchain (smart contract) scaling by concentrating transaction and oracle-report processing oﬀchain, rather than on chain. This shift in the main locus of computation reduces transaction latency and fees while boosting transaction throughput. Conﬁdentiality: Blockchains provide unprecedented transparency for smart contracts and the applications they realize. But there is a basic tension between transparency and conﬁdentiality. Today, for example, users’ decentralized exchange trans-

Conceptual figure showing how DONs improve blockchain smart contract scaling by moving computation off-chain

Figure 4: Conceptual ﬁgure showing how Decentralized Oracle Networks improve the scaling of blockchain-enabled smart contracts. Figure A ⃝shows a conventional oracle architecture. Transactions are sent directly to the blockchain, as are oracle reports. Thus the blockchain, highlighted in yellow, is the main locus for transaction processing. Figure B⃝shows use of a DON to support contracts on the blockchain. A DON executable processes transactions along with data from external systems and forwards results—e.g., bundled transactions or contract state changes resulting from the transactions’ eﬀects—to the blockchain. The DON, highlighted in yellow, is thus the main locus for transaction processing. actions are recorded on chain, making it easy to monitor exchange behavior, but also making users’ ﬁnancial transactions publicly visible. Similarly, data relayed to smart contracts remains on chain. This makes such data conveniently auditable, but acts as a disincentive for data providers wishing to furnish smart contracts with sensitive or proprietary data. We believe that oracle networks will play a pivotal role in catalyzing next-generation systems that combine blockchains’ innate transparency with new conﬁdentiality protections. In this paper, we show how they will do so using three main approaches: • Conﬁdentiality-preserving adapters: Two technologies with planned deployment in Chainlink’s networks, DECO [234] and Town Crier [233], enable oracle nodes to retrieve data from oﬀ-chain systems in ways that protect user privacy and data conﬁdentiality. They will play a key role in the design of adapters for DONs. (See Section 3.6.2 for details on these two technologies.) • Conﬁdential computation: DONs can simply conceal their computation from relying blockchains. Using secure multi-party computation and/or trusted execution environments, stronger conﬁdentiality is also possible in which DON nodes compute over data into which they themselves do not have visibility.

Conceptual diagram of confidentiality-preserving operations in a DON processing sensitive data through adapters

• Support for conﬁdential layer-2 systems: The TEF is designed to support a variety of layer-2 systems, many of which use zero-knowledge proofs to provide various forms of transaction conﬁdentiality. We discuss these approaches in Section 3 (with additional details in Section 6, Appendix B.1, and Appendix B.2). Fig. 5 presents a conceptual view of how sensitive data might ﬂow from external sources to a smart contract by means of conﬁdentiality-preserving adapters and conﬁdential computation in a DON. Figure 5: Conceptual diagram of conﬁdentiality-preserving operations in a DON on sensitive data (highlighted in yellow). Sensitive source data (black circles) in web servers is extracted to the DON using conﬁdentiality-preserving adapters (blue, doublearrowed lines). The DON receives derived data (hollow circles) from these adapters— the result of applying either a function or, e.g., secret-sharing, to the sensitive source data. An executable on the DON may apply conﬁdential computation to derived data to construct a report (double circle), which it sends over an adapter to the blockchain. We believe that powerful tools for handling conﬁdential data will open up a whole range of applications. Among these are private decentralized (and centralized) ﬁnance, decentralized identity, credit-based on-chain lending, and more eﬃcient and user-friendly know-your-customer and accreditation protocols, as we discuss in Section 4. Order-fairness for transactions: Today’s blockchain designs have a dirty little open secret: They are ephemerally centralized. Miners and validators can order trans-

Example comparing standard mining with Fair Sequencing Services showing how FSS prevents transaction reordering

actions however they choose. Transaction order can also be manipulated by users as a function of the network fees they pay (e.g., gas prices in Ethereum) and to some extent by taking advantage of fast network connections. Such manipulation can, for example, take the form of front-running, in which a strategic actor such as a miner observes a user’s transaction and inserts its own exploitative transaction into an earlier position in the same block—eﬀectively stealing money from the user by leveraging advance knowledge of the user’s transaction. For example, a bot may place a buy order before a user’s. It can then take advantage of the asset price increase induced by the user’s trade. Front-running by some bots that harms ordinary users—analogous to high-frequency trading on Wall Street—is already prevalent and well documented [90], as are related attacks such as back-running [159] and automated transaction mimicking [195]. Proposals to systematize order exploitation by miners have even surfaced recently [110]. Layer-2 technologies such as rollups don’t solve the problem, but merely re-centralize ordering, placing it in the hands of the entity that creates a rollup. One of our goals is to introduce into Chainlink a service called Fair Sequencing Services (FSS) [137]. FSS helps smart contract designers ensure fair ordering for their transactions and avoid front-running, back-running, and related attacks on user transactions as well as other types of transactions, such as oracle report transmission. FSS enables a DON to implement ideas such as the rigorous, temporal notion of orderfairness introduced in [144]. As an incidental beneﬁt, FSS can also lower users’ network fees (e.g., gas costs). Brieﬂy, in FSS, transactions pass through the DON, rather than propagating directly to a target smart contract. The DON orders the transactions and then forwards them to the contract. Figure 6: Example of how FSS is beneﬁcial. Fig. A ⃝shows how a miner, exploiting its centralized power to order transactions, may swap a pair of transactions: transaction 1⃝ arrives before 2⃝, but the miner instead sequences it after 2⃝. In contrast, Fig. B⃝shows how a DON decentralizes the ordering process among DON nodes. If a quorum of honest nodes receive 1⃝before 2⃝, the FSS causes 1⃝to appear before 2⃝on chain— preventing miner reordering by attaching contract-enforceable sequence numbers. Fig. 6 compares standard mining with FSS. It shows how in standard mining,

the process of transaction ordering is centralized with the miner and thus subject to manipulation, such as reordering a pair of transactions with respect to their arrival times. In contrast, in FSS, the process is decentralized among DON nodes. Assuming a quorum of honest nodes, FSS helps enforce policies such as temporal ordering of transactions, reducing opportunities for manipulation by miners and other entities. Additionally, since users need not compete for preferential ordering based on gas price, they can pay relatively low gas prices (while transactions from the DON can be batched for gas savings). Trust minimization: Our general aim in the design of DONs is to facilitate a highly trustworthy layer of support for smart contracts and other oracle-dependent systems by means of decentralization, cryptographic tools, and cryptoeconomic guarantees. A DON itself is decentralized, and users can choose from any available DON that supports the main chain on which they wish to operate or spawn additional DONs with committees of nodes they trust. For some applications, however, particularly smart contracts, Chainlink users may favor a trust model that treats the main chain supported by a DON as more trustworthy than the DON itself. For such users, we already have or plan to incorporate into the architecture of the Chainlink network a number of mechanisms that enable contracts on a main chain to strengthen the security assurances provided by DONs, while at the same time also enforcing protections against the possibility of corrupted data sources such as the web servers from which the DON obtains data. We describe these mechanisms in Section 7. They fall under ﬁve main headings: • Data-source authentication: Tools that enable data providers to digitally sign their data and thereby strengthen the chain of custody between the origin and relying contract. • DON minority reports: Flags issued by a minority subset of DON nodes that observes majority malfeasance in the DON. • Guard rails: Logic on a main chain that detects anomalous conditions and pauses or halts contract execution (or invokes other remediations). • Trust-minimized governance: Use of gradual-release updates to facilitate community inspection, as well as decentralized emergency interventions for rapid response to system failures. • Decentralized entity authentication: Use of public-key infrastructure (PKI) to identify entities in the Chainlink network. Fig. 7 presents a conceptual schematic of our trust-minimization goals. Incentive-based (cryptoeconomic) security: Decentralization of report generation across oracle nodes helps ensure security even when some nodes are corrupted.

Conceptual depiction of Chainlink trust-minimization goal showing DON and data source trust loci

Figure 7: Conceptual depiction of Chainlink’s trust-minimization goal, which is to minimize users’ need for correct behavior of the DON and data sources such as web servers. Yellow highlights in the ﬁgure indicate trust-minimization loci: the DON and individual or minority sets of web servers. Pink highlights indicate system components that are highly trustworthy by assumption: contracts on the blockchain and a majority of web servers, i.e., web servers in the aggregate. Equally important, though, is ensuring that nodes have a ﬁnancial incentive to behave correctly. Staking, i.e., requiring nodes to provide deposits of LINK and slashing (conﬁscating) these deposits in case of misbehavior, will play a key role in Chainlink. It is an important incentive design already used in a number of blockchains, e.g., [81, 103, 120, 204]. Staking in Chainlink, however, looks very diﬀerent from staking in standalone blockchains. Staking in blockchains aims to prevent attacks on consensus. It has a diﬀerent goal in Chainlink: to ensure timely delivery of correct oracle reports. A welldesigned staking system for an oracle network should render attacks such as bribery unproﬁtable for an adversary, even when the target is a smart contract with high monetary value. In this paper, we present a general approach to staking in Chainlink with three key innovations:

Conceptual diagram depicting super-linear scaling in Chainlink staking where briber cost grows faster than combined node deposits

A powerful adversarial model that encompasses attacks overlooked in existing approaches. One example is what we call prospective bribery. This is a form of bribery that determines which nodes receive bribes on a conditional basis, e.g., oﬀers guaranteed bribes in advance to nodes that a staking mechanism selects at random for particular roles (such as triggering report adjudication).
Super-linear staking impact, meaning informally that to be successful, an adversary must have a budget $B greater than the combined deposits of all oracle nodes. More precisely, we mean that as a function of n, $B(n) ≫$dn in a network of n oracle nodes each with a ﬁxed deposit amount $d (more formally, $B(n) is asymptotically larger in n than $dn). Fig. 8 gives a conceptual view of this property.
The Implicit-Incentive Framework (IIF), an incentive model we have devised to encompass empirically measurable incentives beyond explicit deposited staking funds, including nodes’ future fee opportunities. The IIF extends the notion of stake beyond explicit node deposits. Figure 8: Conceptual diagram depicting super-linear scaling in Chainlink staking. The bribe $B(n) required by an adversary grows faster in n than the combined deposits $dn of all oracle nodes. We show how the IIF and super-linear staking impact together induce what we call a virtuous cycle of economic security for oracle networks. When new users enter

the system, increasing potential future earnings from running Chainlink nodes, the marginal cost of economic security drops for current and future users. In a regime of elastic demand, this diminished cost incentivizes additional users to make use of the network, continuously perpetuating adoption in an ongoing virtuous cycle. Note: While this whitepaper outlines important elements of our vision for the evolution of Chainlink, it is informal and includes few detailed technical speciﬁcs. We plan to release focused technical papers on additional features and approaches as they evolve. Furthermore, it is important to emphasize that many elements of the vision presented here (scaling improvements, conﬁdentiality technologies, FSS, etc.) can and will be deployed in preliminary form even before advanced DONs become a basic feature of Chainlink. 1.3 Organization of this Paper We present our security model and notation in Section 2 and outline the Decentralized Oracle Network API in Section 3. In Section 4, we present a number of examples of applications for which DONs provide an appealing deployment platform. Readers can learn most of the key concepts of the paper by reading up to this point. The remainder of the paper contains further details. We describe Fair Sequencing Services (FSS) in Section 5 and the Transaction-Execution Framework (TEF) in Section 6. We describe our approach to trust minimization in Section 7. We consider some important DON deployment requirements, namely incremental rollout of features, dynamic ledger membership, and accountability in Section 8. Finally, in Section 9, we give an overview of our developing approach to incentive design. We conclude in Section 10. To help readers who have limited familiarity with the concepts in this paper, we provide a glossary in Appendix A. We present further detail on the DON interface and functionality in Appendix B and present some example adapters in Appendix C. In Appendix D, we describe a cryptographic primitive for trust-minimized data-source authentication called functional signatures and introduce a new variant called discretized functional signatures. We discuss some considerations bearing on committee selection for DONs in Appendix F.

Introdução

Conceptual figure showing how a Decentralized Oracle Network can realize basic oracle functionality by relaying off-chain data to a contract

Conceptual figure depicting on-chain and off-chain contract composition in a hybrid smart contract architecture

Blockchain oracles são frequentemente vistos hoje como serviços descentralizados com um objetivo: para encaminhar dados de recursos fora da cadeia para blockchains. É um passo curto, porém, desde o encaminhamento de dados até a computação neles, armazenamento ou transmissão bidirecional. Esta observação justifica uma noção muito mais ampla da funcionalidade de oracles. Então também atendem aos crescentes requisitos de serviço de smart contracts e cada vez mais multifacetados tecnologias que dependem de redes oracle. Resumindo, um oracle pode e precisará ser uma interface de uso geral, bidirecional e habilitada para computação entre sistemas onchain e off-chain. O papel dos oráculos no ecossistema blockchain é melhorar o desempenho, funcionalidade e interoperabilidade de smart contracts para que eles possam trazer novos modelos de confiança e transparência para uma multiplicidade de indústrias. Esta transformação ocorrerá através da ampliação do uso de smart contracts híbridos, que fundem Propriedades especiais de blockchains com os recursos exclusivos de sistemas off-chain, como oracle redes e, assim, alcançar muito maior alcance e poder do que os sistemas on-chain isoladamente. Neste whitepaper, articulamos uma visão para o que chamamos de Chainlink 2.0, uma evolução de Chainlink além de sua concepção inicial no whitepaper Chainlink original [98]. Prevemos um papel cada vez mais expansivo para as redes oracle, em que eles complementam e aprimoram blockchains existentes e novos, fornecendo conectividade e computação universais rápidas, confiáveis e que preservam a confidencialidade para sistemas híbridos. smart contracts. Acreditamos que as redes oracle evoluirão até se tornarem serviços públicos para exportar dados de grau blockchain de alta integridade para sistemas além do blockchain ecossistema. Hoje, os nós Chainlink executados por um conjunto diversificado de entidades se reúnem em redes oracle para retransmitir dados para smart contracts no que é conhecido como relatórios. Podemos ver tal oracle nós como um comitê semelhante ao de um consenso clássico blockchain [72], mas com o objetivo de oferecer suporte a blockchains existentes, em vez de fornecer funcionalidade independente. Com funções aleatórias verificáveis (VRF) e relatórios fora da cadeia (OCR), Chainlink já está evoluindo em direção a uma estrutura e infraestrutura de uso geral para fornecer os recursos computacionais que smart contracts exigem para funcionalidade avançada. A base do nosso plano para Chainlink 2.0 é o que chamamos de Oracle Descentralizado Redes, ou DONs, para abreviar. Desde que introduzimos o termo “rede oracle” no white paper original Chainlink [98], oracles desenvolveram funcionalidades cada vez mais ricas e amplitude de aplicação. Neste artigo, oferecemos uma nova definição do termo de acordo com para a nossa visão futura para o ecossistema Chainlink. Nesta visão, um DON é uma rede mantido por um comitê de nós Chainlink. Enraizado num protocolo de consenso, suporta qualquer uma de uma gama ilimitada de funções oracle escolhidas para implantação pelo comitê. Um DON atua, portanto, como uma camada de abstração blockchain, fornecendo interfaces para recursos fora da cadeia para smart contracts e outros sistemas. Também fornece acesso a recursos de computação off-chain altamente eficientes, porém descentralizados. Em geral, a DON suporta operações em uma cadeia principal. Seu objetivo é permitir um acesso seguro e ﬂexi-híbridos smart contracts, que combinam computação on-chain e off-chain com conexão com recursos externos. Ressaltamos que mesmo com a utilização de comitês em DONs, o próprio Chainlink permanece inerentemente sem permissão. DONs atuam como a base de um sistema sem permissão estrutura na qual os nós podem se unir para implementar redes oracle personalizadas com seus próprios regimes para inclusão de nós, que podem ser com ou sem permissão. Com DONs como base, planejamos focar em Chainlink 2.0 em avanços em sete áreas principais: smart contracts híbridos, abstração de complexidade, escalabilidade, confidencialidade, justiça de ordem para transações, minimização de confiança e segurança baseada em incentivos (criptoeconômica). Na introdução deste artigo, apresentamos uma visão geral da Descentralização Oracle Networks na Seção 1.1 e, em seguida, nossas sete principais áreas de inovação na Seção 1.2. Descrevemos a organização do restante deste artigo na Seção 1.3. 1.1 Redes Oracle Descentralizadas As Oracle Networks descentralizadas são projetadas para aprimorar e ampliar os recursos de smart contracts em um alvo blockchain ou cadeia principal por meio de funções que são não está disponível nativamente. Eles fazem isso fornecendo os três recursos básicos encontrados em sistemas de computação: rede, armazenamento e computação. Um DON visa oferecer esses recursos com fortes propriedades de confidencialidade, integridade e disponibilidade,1 como bem como a responsabilização. DONs são formados por comitês de nós oracle que cooperam para cumprir um determinado emprego ou optar por estabelecer um relacionamento duradouro para fornecer serviços persistentes aos clientes. DONs são projetados de maneira agnóstica blockchain. Eles prometem servir como uma ferramenta poderosa e flexível para desenvolvedores de aplicativos criarem suporte fora da cadeia para seus smart contracts em qualquer cadeia principal suportada. Dois tipos de funcionalidades realizam os recursos de um DON: executáveis e adaptadores. Executáveis são programas executados continuamente e de forma descentralizada no DON. Embora não armazenem diretamente ativos da cadeia principal, eles apresentam benefícios importantes, incluindo alto desempenho e a capacidade de realizar operações confidenciais. computação. Os executáveis são executados de forma autônoma em um DON e executam tarefas determinísticas operações. Eles trabalham em conjunto com adaptadores que vinculam o DON a recursos externos e pode ser chamado por executáveis. Adaptadores, como os imaginamos para DONs, são um generalização dos adaptadores externos em Chainlink hoje. Embora os adaptadores existentes normalmente buscam dados apenas de fontes de dados, os adaptadores podem operar bidirecionalmente; em DONs, eles também podem aproveitar a computação conjunta por nós DON para alcançar recursos adicionais, como criptografia de relatórios para consumo com preservação de privacidade por um executável. Para fornecer uma ideia da operação básica de um DON, a Fig. 1 mostra conceitualmente como um DON pode ser usado para enviar relatórios para um blockchain e, assim, obter a funcionalidade oracle tradicional e existente. DONs podem fornecer muitos recursos adicionais, porém, além 1A “tríade da CIA” de segurança da informação [123, p. 26, §2.3.5].Redes existentes de Chainlink. Por exemplo, dentro da estrutura geral da Fig. 1, o executável poderia registrar dados de preços de ativos buscados no DON, usando esses dados para calcular, por exemplo, uma média final para seus relatórios. Figura 1: Figura conceitual mostrando como exemplo como uma Rede Oracle Descentralizada pode realizar a funcionalidade básica oracle, ou seja, retransmitir dados fora da cadeia para um contrato. Um executável usa adaptadores para buscar dados fora da cadeia, nos quais ele computa, enviando saída sobre outro adaptador para um destino blockchain. (Os adaptadores são iniciados pelo código no DON, representado por pequenas caixas azuis; setas mostram a direção do fluxo de dados para este exemplo específico.) O executável também pode ler e gravar em DON local armazenamento para manter o estado e/ou se comunicar com outros executáveis. Rede flexível, computação e armazenamento em DONs, todos representados aqui, permitem uma série de novidades aplicações. Um grande benefício dos DONs é sua capacidade de inicializar novos serviços blockchain. DONs são um veículo pelo qual as redes oracle existentes podem rapidamente suportar aplicações de serviço isso exigiria hoje a criação de redes construídas especificamente. Damos uma série de exemplos de tais aplicações na Seção 4. Na Seção 3, fornecemos mais detalhes sobre DONs, descrevendo suas capacidades em termos da interface que apresentam aos desenvolvedores e usuários. 1.2 Sete objetivos principais de design Aqui revisamos brevemente os sete focos principais enumerados acima para a evolução da Chainlink, a saber:smart contracts híbridos: Central para nossa visão para Chainlink é a ideia de segurança combinando componentes on-chain e off-chain em smart contracts. Referimo-nos a contratos concretizando essa ideia como smart contracts híbridos ou contratos híbridos.2 Blockchains são e continuarão a desempenhar dois papéis críticos no serviço descentralizado ecossistemas: ambos são os locais onde a propriedade de criptomoedas é representada e âncoras robustas para serviços descentralizados. Os contratos inteligentes devem, portanto, ser representados ou executados em cadeia, mas as suas capacidades em cadeia são severamente limitadas. Puramente o código de contrato na cadeia é lento, caro e insular, incapaz de se beneficiar do mundo real dados e uma variedade de funcionalidades que são inerentemente inatingíveis em cadeia, incluindo várias formas de computação confidencial, geração de (pseudo) aleatoriedade segura contra manipulação de mineradores/validator, etc. Para que smart contracts realizem todo o seu potencial, portanto, são necessários smart contracts a ser arquitetado com duas partes: uma parte na cadeia (que normalmente denotamos por SC) e uma parte off-chain, um executável rodando em um DON (que normalmente denotamos por executivo). O objetivo é alcançar uma composição segura de funcionalidade on-chain com o multiplicidade de serviços fora da cadeia que DONs pretendem fornecer. Juntas, as duas partes elaborar um contrato híbrido. Apresentamos a ideia conceitualmente na Fig. 2. Já hoje, Chainlink serviços3 como feeds de dados e VRFs estão possibilitando smart contract aplicações, variando de DeFi a NFTs gerados de forma justa e seguros descentralizados, como primeiros passos em direção a uma estrutura mais geral. Como serviços Chainlink expandir e ter mais desempenho de acordo com nossa visão neste whitepaper, assim como será o poder dos sistemas smart contract em todos os blockchains. Nossos outros seis focos principais neste whitepaper podem ser vistos como atuação no serviço do primeiro, abrangendo um dos contratos híbridos. Esses focos envolvem a remoção de visíveis complexidade de contratos híbridos, criando serviços adicionais fora da cadeia que permitem o construção de contratos híbridos cada vez mais capazes e, no caso da minimização da confiança, reforçando as propriedades de segurança alcançadas pelos contratos híbridos. Deixamos a ideia de contratos híbridos implícitos em grande parte do artigo, mas qualquer combinação de A lógica MAINCHAIN com DON pode ser vista como um contrato híbrido. Abstraindo a complexidade: DONs são projetados para fazer uso de recursos descentralizados sistemas fáceis para desenvolvedores e usuários, abstraindo o maquinário muitas vezes complexo por trás da poderosa e flexível gama de serviços de DONs. Serviços Chainlink existentes já possui esse recurso. Por exemplo, os feeds de dados em Chainlink hoje apresentam interfaces onchain que não exigem que os desenvolvedores se preocupem com detalhes de nível de protocolo, como os meios pelos quais o OCR impõe relatórios de consenso entre um 2A ideia de composição de contrato on-chain/off-chain surgiu anteriormente em vários países restritos. formulários, por exemplo, sistemas de camada 2, blockchains [80] baseados em TEE, etc. Nosso objetivo é apoiar e generalizar essas abordagens e garantir que elas possam abranger o acesso a dados fora da cadeia e outras oracle chaves serviços. 3Chainlink serviços compreendem uma variedade de serviços e funcionalidades descentralizados disponíveis através a rede. Eles são oferecidos por numerosos operadores de nós compostos em várias redes oracle em todo o ecossistema.Figura 2: Figura conceitual que descreve a composição do contrato on-chain/off-chain. Um híbrido smart contract 3⃝consiste em dois componentes complementares: um on-chain componente SC 1⃝, residente em um blockchain, e um componente off-chain exec 2⃝que é executado em um DON. O DON também serve como uma ponte entre os dois componentes como conectar o contrato híbrido com recursos fora da cadeia, como serviços da web, outros blockchains, armazenamento descentralizado, etc. conjunto descentralizado de nós. DONs vão um passo além no sentido de que expandem o gama de serviços para os quais Chainlink pode oferecer aos desenvolvedores uma camada de abstração com acompanhando interfaces simplificadas para serviços de alto nível. Apresentamos vários exemplos de aplicação na Seção 4 que destacam essa abordagem. Imaginamos empresas, por exemplo, usando DONs como uma forma de middleware seguro para conectar seus sistemas legados a blockchains. (Veja a Seção 4.2.) Este uso de DONs abstrai a complexidade da dinâmica geral de blockchain (taxas, reorganizações, etc.). Também abstrai os recursos de blockchains específicos, permitindo assim que as empresas conectem seus sistemas existentes a uma gama cada vez maior de sistemas blockchain sem necessidade de conhecimentos especializados nestes sistemas ou, mais genericamente, no desenvolvimento de sistemas descentralizados. Em última análise, a nossa ambição é aumentar o grau de abstração alcançado por Chainlink a ponto de implementar o que chamamos de metacamada descentralizada. Essa camada abstrairia a distinção on-chain/off-chain para todas as classes de desenvolvedores e usuários de DApps, permitindo a criação e uso contínuo de serviços descentralizados.Para simplificar o processo de desenvolvimento, os desenvolvedores poderiam especificar a funcionalidade DApp na metacamada como uma aplicação virtual em um modelo de máquina unificado. Eles poderiam em seguida, use um compilador de metacamada descentralizado para instanciar o DApp automaticamente como um conjunto de funcionalidades descentralizadas interoperacionais abrangendo blockchains, DONs e serviços externos. (Um desses serviços externos poderia ser um sistema empresarial, tornando a metacamada útil para aplicações que envolvem sistemas empresariais legados.) Tal a compilação é semelhante à forma como os compiladores modernos e os kits de desenvolvimento de software (SDKs) apoiar programadores generalistas no uso de todo o potencial de hardware heterogêneo arquiteturas que consistem em uma CPU de uso geral e hardware especializado como GPUs, aceleradores de aprendizado de máquina ou enclaves confiáveis. A Fig. 3 apresenta esta ideia a nível conceptual. Os smart contracts híbridos são um primeiro passo no caminho para esta visão e para um conceito que chamamos de metacontratos. Metacontratos são aplicações codificadas de forma descentralizada metalayer e abrange implicitamente a lógica on-chain (smart contracts), bem como a computação off-chain e a conectividade entre vários blockchains e off-chain existentes serviços. Dada a necessidade de suporte a linguagens e compiladores, novos modelos de segurança e harmonização conceitual e técnica de tecnologias díspares, no entanto, a realização de uma verdadeira metacamada descentralizada é uma meta ambiciosa à qual aspiramos há muito tempo. horizonte de tempo. No entanto, é um modelo ideal útil para se ter em mente durante a leitura este artigo, não detalhado aqui, mas algo em que planejamos focar em nosso trabalho futuro sobre Chainlink. Dimensionamento: Um objetivo de importância preeminente em nossos projetos em evolução é permitir que o Rede Chainlink para atender às crescentes necessidades de expansão do ecossistema blockchain. Com o congestionamento da rede se tornando um problema recorrente em redes sem permissão existentes blockchains [86], designs blockchain novos e com melhor desempenho estão entrando em uso, por exemplo, [103, 120, 203], bem como tecnologias complementares de escalonamento de camada 2, por exemplo, [5, 12, 121, 141, 169, 186, 187]. Os serviços Oracle devem atingir latências e taxas de transferência que atendem às demandas de desempenho desses sistemas, ao mesmo tempo que minimizam as taxas na rede (por exemplo, custos do gás) tanto para os operadores contratuais como para os utilizadores comuns. Com DONs, Chainlink a funcionalidade visa ir além e oferecer desempenho alto o suficiente para sistemas puramente baseados na web. DONs derivam grande parte de seu ganho de desempenho do uso de protocolos de consenso rápidos, baseados em comitês ou sem permissão, que eles combinam com os blockchains eles apoiam. Esperamos que muitos DONs com configurações diferentes sejam executados em paralelo; diferentes DApps e usuários podem navegar pelas compensações nas escolhas de consenso subjacentes de acordo com seus requisitos de aplicação. DONs podem ser vistos, na verdade, como tecnologias de camada 2. Esperamos que entre outros serviços, DONs suportarão o Transaction Execution Framework (TEF), que facilita a integração eficiente de DONs e, portanto, oracles com outros de alto desempenho sistemas de camada 2 - por exemplo, rollups, sistemas que agrupam transações off-chain para alcançar melhorias de desempenho. Apresentamos o TEF na Seção 6.

Conceptual figure showing ideal realization of a decentralized metalayer that abstracts blockchain and DON complexity

Figura 3: Figura conceitual mostrando a realização ideal de uma metacamada descentralizada. Para facilidade de desenvolvimento, um desenvolvedor especifica um DApp, destacado em rosa, como um virtual aplicação em um modelo de máquina unificado. Um compilador descentralizado de metacamada gera automaticamente funcionalidades de interoperabilidade correspondentes: smart contracts (denotado por SC), lógica (denotada por exec) em DONs, adaptadores conectados a serviços externos de destino e assim por diante, conforme indicado em destaque amarelo. A Figura 4 mostra conceitualmente como DONs melhoram o dimensionamento de blockchain (smart contract) concentrando o processamento de transações e relatórios oracle fora da cadeia, em vez de em cadeia. Esta mudança no locus principal de computação reduz a latência da transação e taxas e, ao mesmo tempo, aumentar o rendimento das transações. Confidencialidade: Blockchains fornecem transparência sem precedentes para smart contracts e para as aplicações que eles realizam. Mas existe uma tensão básica entre transparência e confidencialidade. Hoje, por exemplo, as transações de câmbio descentralizadas dos usuáriosFigura 4: Figura conceitual mostrando como as Redes Oracle Descentralizadas melhoram o dimensionamento de blockchains habilitados para blockchain. Figura A ⃝mostra um oracle convencional arquitetura. As transações são enviadas diretamente para blockchain, assim como os relatórios oracle. Assim o blockchain, destacado em amarelo, é o principal locus de processamento das transações. A Figura B⃝mostra o uso de um DON para apoiar contratos no blockchain. Um DON executável processa transações junto com dados de sistemas externos e encaminha resultados - por exemplo, transações agrupadas ou alterações no estado do contrato resultantes dos efeitos das transações - para blockchain. O DON, destacado em amarelo, é assim o principal locus para processamento de transações. as ações são registradas em cadeia, facilitando o monitoramento do comportamento da bolsa, mas também tornar as transações financeiras dos usuários publicamente visíveis. Da mesma forma, os dados transmitidos para sistemas inteligentes os contratos permanecem em cadeia. Isto torna esses dados convenientemente auditáveis, mas funciona como um desincentivo para provedores de dados que desejam fornecer smart contracts informações confidenciais ou dados proprietários. Acreditamos que as redes oracle desempenharão um papel fundamental na catalisação da próxima geração sistemas que combinam a transparência inata de blockchains com novas proteções de confidencialidade. Neste artigo, mostramos como eles farão isso usando três abordagens principais: • Adaptadores que preservam a confidencialidade: duas tecnologias com implantação planejada nas redes de Chainlink, DECO [234] e Town Crier [233], habilite os nós oracle para recuperar dados de sistemas fora da cadeia de forma a proteger a privacidade e os dados do usuário confidencialidade. Eles desempenharão um papel fundamental no projeto de adaptadores para DONs. (Consulte a Seção 3.6.2 para obter detalhes sobre essas duas tecnologias.) • Computação confidencial: DONs podem simplesmente ocultar sua computação de blockchains confiáveis. Usando computação multipartidária segura e/ou ambientes de execução confiáveis, uma confidencialidade mais forte também é possível em que nós DON computar dados sobre os quais eles próprios não têm visibilidade.

Example comparing standard mining with Fair Sequencing Services showing how FSS prevents transaction reordering

Conceptual diagram of confidentiality-preserving operations in a DON processing sensitive data through adapters

• Suporte para sistemas confidenciais de camada 2: O TEF foi projetado para suportar uma variedade de sistemas de camada 2, muitos dos quais usam provas de conhecimento zero para fornecer diversas formas de confidencialidade da transação. Discutimos essas abordagens na Seção 3 (com detalhes adicionais na Seção 6, Apêndice B.1 e Apêndice B.2). A Figura 5 apresenta uma visão conceitual de como os dados confidenciais podem fluir de fontes externas para um smart contract por meio de adaptadores que preservam a confidencialidade e cálculo confidencial em um DON. Figura 5: Diagrama conceitual de operações de preservação de confidencialidade em um DON em dados sensíveis (destacados em amarelo). Dados de origem confidenciais (círculos pretos) na web servidores é extraído para DON usando adaptadores de preservação de confidencialidade (linhas azuis com setas duplas). O DON recebe dados derivados (círculos vazios) desses adaptadores— o resultado da aplicação de uma função ou, por exemplo, do compartilhamento de segredo, à fonte confidencial dados. Um executável em DON pode aplicar computação confidencial a dados derivados para construir um relatório (círculo duplo), que envia por meio de um adaptador para o blockchain. Acreditamos que ferramentas poderosas para lidar com dados confidenciais abrirão todo um gama de aplicações. Entre eles estão o financiamento privado descentralizado (e centralizado), a identidade descentralizada, os empréstimos em cadeia baseados em crédito e empréstimos mais eficientes e protocolos fáceis de conhecer seu cliente e de credenciamento, conforme discutimos na Seção 4. Justiça de ordem para transações: Os designs blockchain de hoje têm um pouco de sujeira segredo aberto: Eles são efêmeros centralizados. Mineiros e validators podem solicitar trans-ações como quiserem. A ordem de transação também pode ser manipulada pelos usuários como em função das taxas de rede que pagam (por exemplo, preços do gás em Ethereum) e para alguns extensão, aproveitando conexões de rede rápidas. Tal manipulação pode, por exemplo, assumir a forma de front-running, em que um ator estratégico como uma mineradora observa a transação de um usuário e insere sua própria transação exploratória em uma transação anterior posição no mesmo bloco - roubando efetivamente dinheiro do usuário, aproveitando o conhecimento prévio da transação do usuário. Por exemplo, um bot pode fazer um pedido de compra antes de um usuário. Poderá então tirar partido do aumento dos preços dos activos induzido pela comércio do usuário. Front-running por alguns bots que prejudica usuários comuns – análogo ao de alta frequência negociação em Wall Street - já é predominante e bem documentado [90], assim como estão relacionados ataques como back-running [159] e simulação de transação automatizada [195]. Propostas para sistematizar a exploração de pedidos por mineradores surgiram recentemente [110]. Tecnologias de camada 2, como rollups, não resolvem o problema, apenas recentralizam encomenda, colocando-o nas mãos da entidade que cria um rollup. Um dos nossos objetivos é introduzir em Chainlink um serviço chamado Fair Sequencing Serviços (FSS) [137]. O FSS ajuda os designers de smart contract a garantir pedidos justos para seus transações e evitar ataques front-running, back-running e ataques relacionados às transações do usuário, bem como outros tipos de transações, como transmissão de relatórios oracle. FSS permite que um DON implemente ideias como a noção rigorosa e temporal de ordem e justiça introduzida em [144]. Como benefício incidental, o FSS também pode reduzir a rede dos usuários. taxas (por exemplo, custos de gás). Resumidamente, no FSS, as transações passam pelo DON, em vez de serem propagadas diretamente para um destino smart contract. O DON ordena as transações e depois encaminha -los ao contrato. Figura 6: Exemplo de como o FSS é benéfico. Figura A ⃝mostra como um mineiro, explorando seu poder centralizado para ordenar transações, pode trocar um par de transações: transação 1⃝ chega antes de 2⃝, mas o mineiro o sequencia depois de 2⃝. Em contraste, a Fig. B⃝mostra como um DON descentraliza o processo de pedido entre os nós DON. Se um quórum de nós honestos recebem 1⃝antes de 2⃝, o FSS faz com que 1⃝ apareça antes de 2⃝na cadeia— evitando o reordenamento dos mineradores anexando números de sequência executáveis ao contrato. A Figura 6 compara a mineração padrão com o FSS. Mostra como na mineração padrão,o processo de pedido de transação é centralizado com o minerador e, portanto, sujeito a manipulação, como reordenar um par de transações em relação à sua chegada vezes. Em contraste, no FSS, o processo é descentralizado entre os nós DON. Supondo um quórum de nós honestos, o FSS ajuda a aplicar políticas como ordenação temporal de transações, reduzindo oportunidades de manipulação por mineradores e outras entidades. Além disso, como os usuários não precisam competir por pedidos preferenciais com base no preço do gás, eles podem pagar preços de gás relativamente baixos (enquanto as transações do DON podem ser agrupadas para economia de gás). Minimização da confiança: Nosso objetivo geral no projeto de DONs é facilitar um altamente camada confiável de suporte para smart contracts e outros sistemas dependentes de oracle por meio de descentralização, ferramentas criptográficas e garantias criptoeconômicas. O próprio DON é descentralizado e os usuários podem escolher entre qualquer DON disponível que suporta a cadeia principal na qual desejam operar ou gerar DONs adicionais com comitês de nós em que confiam. Para alguns aplicativos, no entanto, especialmente smart contracts, os usuários de Chainlink podem favorecer um modelo de confiança que trate a cadeia principal apoiada por um DON como mais confiável do que o próprio DON. Para esses usuários, já temos ou planejamos incorporar ao arquitetura da rede Chainlink uma série de mecanismos que permitem contratos em uma cadeia principal para fortalecer as garantias de segurança fornecidas por DONs, enquanto no ao mesmo tempo, também aplicando proteções contra a possibilidade de fontes de dados corrompidas como os servidores web dos quais DON obtém dados. Descrevemos esses mecanismos na Seção 7. Eles se enquadram em cinco títulos principais: • Autenticação de fonte de dados: ferramentas que permitem que provedores de dados assinem digitalmente seus dados e, assim, fortalecer a cadeia de custódia entre a origem e contrato confiável. • DON relatórios minoritários: sinalizadores emitidos por um subconjunto minoritário de nós DON que observa prevaricação majoritária no DON. • Guard rails: Lógica em uma cadeia principal que detecta condições anômalas e pausas ou interrompe a execução do contrato (ou invoca outras remediações). • Governança com confiança minimizada: Uso de atualizações de liberação gradual para facilitar a inspeção comunitária, bem como intervenções de emergência descentralizadas para rápida resposta a falhas do sistema. • Autenticação de entidade descentralizada: Uso de infraestrutura de chave pública (PKI) para identificar entidades na rede Chainlink. A Figura 7 apresenta um esquema conceitual de nossos objetivos de minimização de confiança. Segurança baseada em incentivos (criptoeconômica): A descentralização da geração de relatórios entre nós oracle ajuda a garantir a segurança mesmo quando alguns nós estão corrompidos.

Conceptual diagram depicting super-linear scaling in Chainlink staking where briber cost grows faster than combined node deposits

Conceptual depiction of Chainlink trust-minimization goal showing DON and data source trust loci

Figura 7: Representação conceitual da meta de minimização da confiança de Chainlink, que é minimizar a necessidade dos usuários de comportamento correto de DON e fontes de dados como a web servidores. Os destaques amarelos na figura indicam loci de minimização de confiança: o DON e conjuntos individuais ou minoritários de servidores web. Destaques rosa indicam componentes do sistema que são altamente confiáveis por suposição: contratos no blockchain e uma maioria de servidores web, ou seja, servidores web no agregado. Igualmente importante, porém, é garantir que os nós tenham um incentivo financeiro para se comportarem corretamente. Staking, ou seja, exigir que os nós forneçam depósitos de LINK e slashing (confiscar) esses depósitos em caso de mau comportamento desempenhará um papel fundamental em Chainlink. É um projeto de incentivo importante já usado em vários blockchains, por exemplo, [81, 103, 120, 204]. No entanto, piquetar em Chainlink parece muito diferente de staking em modo autônomo blockchains. A aposta em blockchains visa prevenir ataques ao consenso. Tem um objetivo diferente em Chainlink: garantir a entrega oportuna de relatórios oracle corretos. Um sistema staking bem projetado para uma rede oracle deve renderizar ataques como suborno não lucrativo para um adversário, mesmo quando o alvo é um smart contract com alto valor monetário. Neste artigo, apresentamos uma abordagem geral para staking em Chainlink com três chaves inovações:1. Um modelo adversário poderoso que engloba ataques negligenciados nas abordagens. Um exemplo é o que chamamos de suborno prospectivo. Esta é uma forma de suborno que determina quais nós recebem subornos de forma condicional, por exemplo, oferece subornos garantidos antecipadamente aos nós que um mecanismo staking seleciona em aleatório para funções específicas (como acionar a adjudicação de relatórios). 2. Impacto staking superlinear, significando informalmente que, para ter sucesso, um adversário deve ter um orçamento em $B maior do que os depósitos combinados de todos os oracle nós. Mais precisamente, queremos dizer que em função de n, $B(n) ≫$dn em um rede de n oracle nós, cada um com um valor de depósito fixo $d (mais formalmente, $B(n) is asymptotically larger in n than $dn). A Fig. 8 dá uma visão conceitual de esta propriedade. 3. O Quadro de Incentivos Implícitos (IIF), um modelo de incentivo que desenvolvemos para abrangem incentivos empiricamente mensuráveis além dos depositados explícitos staking fundos, incluindo oportunidades futuras de taxas dos nós. O IIF amplia a noção de aposta além dos depósitos explícitos de nós. Figura 8: Diagrama conceitual representando escala superlinear em Chainlink staking. O o suborno $B(n) exigido por um adversário cresce mais rápido em n do que os depósitos combinados $dn de todos os nós oracle. Mostramos como o impacto IIF e super-linear staking juntos induzem o que chamamos de ciclo virtuoso de segurança econômica para redes oracle. Quando novos usuários entram

o sistema, aumentando os ganhos futuros potenciais com a execução de nós Chainlink, o o custo marginal da segurança económica cai para os utilizadores actuais e futuros. Num regime de demanda elástica, esse custo reduzido incentiva usuários adicionais a fazer uso do rede, perpetuando continuamente a adoção em um ciclo virtuoso contínuo. Observação: embora este whitepaper descreva elementos importantes de nossa visão para a evolução de Chainlink, ele é informal e inclui poucas especificações técnicas detalhadas. Nós planejamos lançar artigos técnicos focados em recursos e abordagens adicionais à medida que evoluem. Além disso, é importante ressaltar que muitos elementos da visão apresentada aqui (melhorias de escala, tecnologias de confidencialidade, FSS, etc.) podem e serão implantado de forma preliminar, mesmo antes de DONs avançados se tornarem um recurso básico de Chainlink. 1.3 Organização deste artigo Apresentamos nosso modelo de segurança e notação na Seção 2 e descrevemos o Sistema Descentralizado API Oracle Network na Seção 3. Na Seção 4, apresentamos vários exemplos de aplicativos para os quais DONs fornecem uma plataforma de implantação atraente. Os leitores podem aprenda a maioria dos conceitos-chave do artigo lendo até este ponto. O restante do artigo contém mais detalhes. Descrevemos o sequenciamento justo Services (FSS) na Seção 5 e o Transaction-Execution Framework (TEF) na Seção 6. Descrevemos nossa abordagem para minimização de confiança na Seção 7. Consideramos alguns requisitos importantes de implantação DON, ou seja, implementação incremental de recursos, associação de razão dinâmica e responsabilidade na Seção 8. Finalmente, na Seção 9, damos uma visão geral de nossa abordagem em desenvolvimento para design de incentivos. Concluímos na Seção 10. Para ajudar os leitores que têm familiaridade limitada com os conceitos deste artigo, nós fornecemos um glossário no Apêndice A. Apresentamos mais detalhes sobre a interface DON e funcionalidade no Apêndice B e apresentam alguns exemplos de adaptadores no Apêndice C. No Apêndice D, descrevemos uma primitiva criptográfica para fontes de dados com confiança minimizada. autenticação chamada assinaturas funcionais e introduzir uma nova variante chamada assinaturas funcionais discretizadas. Discutimos algumas considerações pertinentes à comissão seleção para DONs no Apêndice F.

Conceptual figure showing how DONs improve blockchain smart contract scaling by moving computation off-chain

Security Model and Goals

A Decentralized Oracle Network is a distinct distributed system that we expect will initially be implemented typically—although not necessarily—by a committee-based consensus protocol and run by a set of oracle nodes. A DON is designed primarily to augment the capabilities of a smart contract on a main chain with oracle reports and other services, but it can provide those same supporting services to other nonblockchain systems, and thus need not be associated with a particular main chain.

The model and properties we consider are therefore largely independent of the use of the particular applications of a DON. 2.1 Current Architectural Model It is important to emphasize that Chainlink today is not a monolithic service, but rather a permissionless framework within which it is possible to launch distinct, independent networks of oracle nodes [77]. Networks have heterogeneous sets of node operators and designs. They may also diﬀer in terms of the types of services they provide, which can include, e.g., data feeds, Proof of Reserves, veriﬁable randomness, and so forth. Other diﬀerences can include the degree of decentralization, size of the network in terms of locked value it supports, and various service-level parameters, such as data frequency and accuracy. Chainlink’s permissionless model encourages the growth of an ecosystem in which providers specialize in the services they are best able to furnish to the community. This model is likely to result in lower costs to users and higher service quality than a model that requires all nodes and networks to provide a full range of services, an approach that can easily devolve into system-wide adoption of the services representing the least common denominator of resources available to nodes. As Chainlink evolves toward DON-based designs in Chainlink 2.0, we continue to support the model of a permissionless, open framework, keeping in view the goal of providing users with a range of service choices that globally result in the best match with particular application requirements. 2.2 Consensus Assumptions We use the term Decentralized Oracle Network to encompass the full functionality of the oracle system we describe: both the data structure that oracle nodes maintain and the core API layered on top of it. We use the term ledger (lower case), denoted by L, to mean the underlying data structure maintained by a DON and used to support the particular services it provides. We emphasize that our DON framework does not treat L as a freestanding system like a blockchain: Its purpose is to support blockchains and other systems. Blockchains are, of course, one way of realizing a trustworthy ledger, but there are others. We expect DONs in many cases to realize their underlying ledgers using Byzantine Fault Tolerant (BFT) systems, which considerably predate blockchains such as Bitcoin [174]. We use BFT-type notation and properties throughout the paper for convenience, although we emphasize that DONs can be realized using permissionless consensus protocols. Conceptually, a ledger L is a bulletin board on which data is linearly ordered. We view a ledger generally as having a few key properties commonly ascribed to blockchains [115]. A ledger is: • Append-only: Data, once added, cannot be removed or modiﬁed.

• Public: Anyone can read its contents, which are consistent across time in the view of all users.4 • Available: The ledger can always be written to by authorized writers and read by anyone in a timely way. Alternative properties are possible in the ledger for a DON when realized by a committee. For instance, ledger write access might be restricted to certain users, as might read access for some applications, i.e., the ledger need not be public as deﬁned above. Similarly, ledger rules might permit modiﬁcation or redaction of data. We don’t explicitly consider such variants in this paper, however. The modular design of DONs can support any of a wide variety of modern BFT protocols, e.g., Hotstuﬀ[231]. The exact choice will depend on trust assumptions and network characteristics among the oracle nodes. A DON could in principle alternatively use a highly performant permissionless blockchain for its ledger in its role supporting an equally scalable layer-2 or blockchain system. Similarly, hybridization is also possible: The DON could in principle be composed of nodes that are validators in an existing blockchain, e.g., in Proof-of-Stake systems in which committees are selected to execute transactions, e.g., [8, 81, 120, 146, 204]. This particular mode of operation requires that nodes operate in a dual-use manner, i.e., operate both as blockchain nodes and DON nodes. (See Section 8.2 for a discussion of techniques to ensure continuity in changing committees and Appendix F for some caveats on random committee selection.) In practice, in modern BFT algorithms, nodes digitally sign messages on the ledger. We assume for convenience that L has an associated public key pkL and that its contents are signed by the corresponding private key. This general notation applies even when data on L are signed using threshold signatures.5 Threshold signatures are convenient, as they enable a persistent identity for a DON even with changes of membership in the nodes running it. (See Appendix B.1.3.) We thus assume that $sk_L$ is secret-shared in a $(k, n)$-threshold manner for some security parameter $k$, e.g., $k = 2f + 1$ and $n = 3f + 1$, where $f$ is the number of potentially faulty nodes. (By choosing $k$ in this way, we ensure that faulty nodes can neither learn $sk_L$ nor mount a denial-of-service attack preventing its use.) A message on L takes the form M = (m, z), where m is a string and z a unique sequential index number. Where applicable, we write messages in the form m = ⟨MessageType : payload⟩. The message type MessageType is syntactic sugar that indicates the function of a particular message. 4In cases where a blockchain without ﬁnality realizes a ledger, inconsistency is typically abstracted away by disregarding insuﬃciently deep blocks or “pruning” [115]. 5In practice, some code bases, e.g., LibraBFT [205], a variant of Hotstuﬀ, have currently adopted multi-signatures, rather than threshold signatures, trading oﬀreduced communication complexity for simpler engineering. With some added cost, oracle nodes can append threshold signatures to messages written to L even if the consensus protocol used for L doesn’t employ them.

2.3 Notation We denote the set of $n$ oracle nodes running the ledger by $O = \{O_i\}_{i=1}^{n}$. Such a set of nodes is often called a committee. For simplicity, we assume that the set of oracles implementing DON functionality, i.e., services on top of L, is identical with that maintaining L, but they can be distinct. We let $pk_i$ denote the public key of player $O_i$, and $sk_i$ the corresponding private key. Most BFT algorithms require at least $n = 3f + 1$ nodes, where $f$ is the number of potentially faulty nodes; remaining nodes are honest, in the sense that they follow the protocol exactly as speciﬁed. We refer to the committee O as honest if it meets this requirement, i.e., has greater than a $2/3$-fraction of honest nodes. Unless otherwise stated, we assume that O is honest (and a static model of corruption). We use $pk_O$ / $sk_O$ interchangeably with $pk_L$ / $sk_L$, depending on the context. We let $\sigma = \text{Sig}_{pk}[m]$ denote a signature on message $m$ with respect to $pk$, i.e., using corresponding private key $sk$. Let $\text{verify}(pk, \sigma, m) \rightarrow \{false, true\}$ denote a corresponding signature veriﬁcation algorithm. (We leave key generation implicit throughout the paper.) We use the notation $S$ to denote a data source and $\mathcal{S}$ to denote the full set of $n_S$ sources in a given context. We denote by MAINCHAIN a smart-contract enabled blockchain supported by a DON. We use the term relying contract to denote any smart contract on MAINCHAIN that communicates with a DON, and use the notation SC to denote such a contract. We generally assume that a DON supports a single main chain MAINCHAIN, although it can support multiple such chains, as we show in examples in Section 4. A DON can and typically will support multiple relying contracts on MAINCHAIN. (As noted above, a DON can alternatively support non-blockchain services.) 2.4 Note on Trust Models As noted above, DONs may be built atop committee-based consensus protocols, and we expect they will commonly use such protocols. There are many strong arguments that one of the two alternatives, committee-based or permissionless blockchains, provides stronger security than the other. It is important to recognize that the security of committee-based vs. permissionless decentralized systems is incommensurable. Compromising a PoW or a PoS blockchain via 51% attack requires that an adversary obtain majority resources ephemerally and potentially anonymously, for example by renting hash power in a PoW system. Such attacks in practice have already impacted several blockchains [200, 34]. In contrast, compromising a committee-based system means corrupting a threshold number (typically one-third) of its nodes, where the nodes may be publicly known, well resourced, and trustworthy entities. On the other hand, committee-based systems (as well as “hybrid” permissionless systems that support committees) can support more functionality than strictly per-

missionless systems. This includes the ability to maintain persistent secrets, such as signing and/or encryption keys—one possibility in our designs. We emphasize that DONs can in principle be built atop either a committee-based or permissionless consensus protocol and DON deployers may ultimately choose to adopt either approach. Bolstering trust models: A key feature of Chainlink today is the ability of users to select nodes based on decentralized records of their performance histories, as discussed in Section 3.6.4. The staking mechanism and Implicit-Incentive Framework we introduce in Section 9 together constitute a broadly scoped and rigorous mechanism-design framework that will empower users with a greatly expanded ability to gauge the security of DONs. This same framework will also make it possible for DONs themselves to enforce various security requirements on participating nodes and ensure operation within strong trust models. It is also possible using tools described in this paper for DONs to enforce special trust-model requirements, such as compliance with regulatory requirements. For example, using techniques discussed in Section 4.3, nodes can present evidence of node-operator characteristics, e.g., territory of operation, that can be used to help enforce compliance with, e.g., the General Data Protection Regulation (GDPR) Article 3 (“Territorial Scope”) [105]. Such compliance can otherwise be challenging to meet in decentralized systems [45]. Additionally, in Section 7 we discuss plans to strengthen the robustness of DONs through trust-minimization mechanisms on the main chains they support.

Modelo e metas de segurança

Uma Rede Oracle Descentralizada é um sistema distribuído distinto que esperamos que inicialmente ser implementado normalmente - embora não necessariamente - por um comitê baseado em protocolo de consenso e executado por um conjunto de nós oracle. Um DON foi projetado principalmente para aumentar os recursos de um smart contract em uma cadeia principal com relatórios oracle e outros serviços, mas pode fornecer esses mesmos serviços de suporte a outros sistemas nãoblockchain e, portanto, não precisa estar associado a uma cadeia principal específica.

O modelo e as propriedades que consideramos são, portanto, em grande parte independentes do uso de as aplicações específicas de um DON. 2.1 Modelo Arquitetônico Atual É importante ressaltar que Chainlink hoje não é um serviço monolítico, mas sim uma estrutura sem permissão dentro da qual é possível lançar recursos distintos e independentes redes de oracle nós [77]. As redes têm conjuntos heterogêneos de operadores de nós e projetos. Eles também podem diferir em termos dos tipos de serviços que prestam, o que pode incluem, por exemplo, feeds de dados, Prova de Reservas, aleatoriedade verificável e assim por diante. Outro As diferenças podem incluir o grau de descentralização, o tamanho da rede em termos de valor bloqueado que ele suporta e vários parâmetros de nível de serviço, como frequência de dados e precisão. O modelo sem permissão de Chainlink incentiva o crescimento de um ecossistema no qual os provedores se especializam nos serviços que são mais capazes de fornecer à comunidade. Isto modelo provavelmente resultará em custos mais baixos para os usuários e maior qualidade de serviço do que um modelo que exige que todos os nós e redes forneçam uma gama completa de serviços, uma abordagem que pode facilmente evoluir para a adoção em todo o sistema dos serviços que representam menos denominador comum de recursos disponíveis para os nós. À medida que Chainlink evolui em direção a designs baseados em DON em Chainlink 2.0, continuamos a apoiar o modelo de uma estrutura aberta e sem permissão, tendo em vista o objetivo de fornecendo aos usuários uma variedade de opções de serviços que resultam globalmente na melhor combinação com requisitos de aplicação específicos. 2.2 Suposições de consenso Usamos o termo Rede Oracle Descentralizada para abranger toda a funcionalidade do o sistema oracle que descrevemos: tanto a estrutura de dados que os nós oracle mantêm e a API principal colocada em cima dela. Usamos o termo razão (minúsculas), denotado por L, para significar os dados subjacentes estrutura mantida por DON e usada para dar suporte aos serviços específicos que ele fornece. Enfatizamos que nossa estrutura DON não trata L como um sistema independente como a blockchain: Sua finalidade é oferecer suporte a blockchains e outros sistemas. Blockchains são, é claro, uma forma de realizar um livro-razão confiável, mas existem outras. Nós esperamos DONs, em muitos casos, para realizar seus livros contábeis subjacentes usando Byzantine Fault Tolerant (BFT), que são consideravelmente anteriores a blockchains, como Bitcoin [174]. Nós usamos notação e propriedades do tipo BFT em todo o artigo por conveniência, embora enfatize que DONs podem ser realizados usando protocolos de consenso sem permissão. Conceitualmente, um livro-razão L é um quadro de avisos no qual os dados são ordenados linearmente. Vemos um livro-razão geralmente como tendo algumas propriedades-chave comumente atribuídas a blockchains [115]. Um livro razão é: • Somente acréscimo: Os dados, uma vez adicionados, não podem ser removidos ou modificados.• Público: Qualquer pessoa pode ler seu conteúdo, que é consistente ao longo do tempo no visualização de todos os usuários.4 • Disponível: O razão sempre pode ser gravado por escritores autorizados e lido por qualquer pessoa em tempo hábil. Propriedades alternativas são possíveis no razão para um DON quando realizadas por um comitê. Por exemplo, o acesso à gravação do razão pode ser restrito a determinados usuários, como pode ler o acesso para algumas aplicações, ou seja, o razão não precisa ser público conforme definido acima. Da mesma forma, as regras contábeis podem permitir a modificação ou redação de dados. Nós não considere explicitamente tais variantes neste artigo, no entanto. O design modular de DONs pode suportar qualquer uma de uma ampla variedade de BFT modernos protocolos, por exemplo, Hotstuﬀ[231]. A escolha exata dependerá de suposições de confiança e características de rede entre os nós oracle. Um DON poderia, em princípio, alternativamente usar um blockchain sem permissão de alto desempenho para seu razão em sua função de suporte a um sistema igualmente escalonável de camada 2 ou blockchain. Da mesma forma, a hibridização também é possível: O DON poderia, em princípio, ser composto de nós que são validators em um existente blockchain, por exemplo, em sistemas de Prova de Participação nos quais os comitês são selecionados para executar transações, por exemplo, [8, 81, 120, 146, 204]. Este modo específico de operação requer que os nós operam de maneira de uso duplo, ou seja, operam como nós blockchain e como nós DON nós. (Veja a Seção 8.2 para uma discussão de técnicas para garantir a continuidade na mudança comitês e Apêndice F para algumas advertências sobre a seleção aleatória de comitês.) Na prática, nos algoritmos BFT modernos, os nós assinam digitalmente as mensagens no livro-razão. Assumimos por conveniência que L tem uma chave pública associada pkL e que seu conteúdo são assinados pela chave privada correspondente. Esta notação geral se aplica mesmo quando os dados em L são assinados usando assinaturas de limite.5 Assinaturas de limite são convenientes, pois permitem uma identidade persistente para um DON mesmo com mudanças de associação em os nós que o executam. (Veja o Apêndice B.1.3.) Assim, assumimos que skL é compartilhado em segredo de uma maneira (k, n)-limiar para algum parâmetro de segurança k, por exemplo, k = 2f + 1 e n = 3f + 1, onde f é o número de nós potencialmente defeituosos. (Ao escolher k neste Dessa forma, garantimos que nós defeituosos não possam aprender skL nem montar um sistema de negação de serviço ataque impedindo seu uso.) Uma mensagem em L assume a forma M = (m, z), onde m é uma string e z um único número de índice sequencial. Quando aplicável, escrevemos mensagens no formato m = ⟨MessageType: carga útil⟩. O tipo de mensagem MessageType é um açúcar sintático que indica a função de uma mensagem específica. 4Nos casos em que um blockchain sem finalidade realiza um livro-razão, a inconsistência é normalmente abstraída eliminado desconsiderando blocos insuficientemente profundos ou “podando” [115]. 5Na prática, algumas bases de código, por exemplo, LibraBFT [205], uma variante do Hotstuﬀ, adotaram atualmente assinaturas múltiplas, em vez de assinaturas de limite, trocando complexidade de comunicação reduzida por engenharia mais simples. Com algum custo adicional, os nós oracle podem anexar assinaturas de limite às mensagens escritos em L mesmo que o protocolo de consenso usado para L não os empregue.2.3 Notação Denotamos o conjunto de n nós oracle executando o razão por O = {Oi}n eu=1. Tal conjunto de nós é frequentemente chamado de comitê. Para simplificar, assumimos que o conjunto de oracles implementando a funcionalidade DON, ou seja, serviços em cima de L, é idêntico a que mantendo L, mas eles podem ser distintos. Deixamos pki denotar a chave pública de jogador Oi, e esquie a chave privada correspondente. A maioria dos algoritmos BFT requerem pelo menos n = 3f + 1 nós, onde f é o número de nós potencialmente defeituosos; os nós restantes são honestos, no sentido de que seguem o protocolo exatamente como especificado. Referimo-nos ao comitê O como honesto se atender a este requisito, ou seja, tem mais de 2/3 fração de nós honestos. A menos que de outra forma afirmado, assumimos que O é honesto (e um modelo estático de corrupção). Usamos pkO / skO de forma intercambiável com pkL/skL, dependendo do contexto. Deixamos σ = Sigpk[m] denotar uma assinatura na mensagem m em relação a pk, ou seja, usando chave privada correspondente sk. Deixe verify(pk, σ, m) →{false, true} denotar um algoritmo de verificação de assinatura correspondente. (Deixamos a geração de chaves implícita ao longo do artigo.) Usamos a notação S para denotar uma fonte de dados e S para denotar o conjunto completo de Fontes nS em um determinado contexto. Denotamos por MAINCHAIN um contrato inteligente habilitado blockchain suportado por um DON. Usamos o termo contrato confiável para denotar qualquer contrato inteligente contrato no MAINCHAIN que se comunica com um DON e use a notação SC para denotar tal contrato. Geralmente assumimos que um DON suporta uma única cadeia principal MAINCHAIN, embora possa suportar múltiplas dessas cadeias, como mostramos nos exemplos da Seção 4. A DON pode e normalmente oferecerá suporte a vários contratos dependentes no MAINCHAIN. (Como mencionado acima, um DON pode alternativamente suportar serviços não blockchain.) 2.4 Nota sobre modelos de confiança Conforme observado acima, DONs podem ser construídos com base em protocolos de consenso baseados em comitês, e nós esperamos que eles normalmente usem esses protocolos. Existem muitos argumentos fortes que uma das duas alternativas, blockchains com base em comitê ou sem permissão, fornece segurança mais forte que o outro. É importante reconhecer que a segurança dos sistemas baseados em comitês versus os sistemas sem permissão sistemas descentralizados é incomensurável. Comprometendo um PoW ou PoS blockchain via ataque de 51% exige que um adversário obtenha recursos majoritários de forma efêmera e potencialmente anonimamente, por exemplo, alugando hash energia em um sistema PoW. Tal os ataques na prática já impactaram vários blockchains [200, 34]. Em contraste, comprometer um sistema baseado em comitê significa corromper um número limite (normalmente um terço) de seus nós, onde os nós podem ser conhecidos publicamente, ter bons recursos, e entidades confiáveis. Por outro lado, sistemas baseados em comitês (bem como sistemas “híbridos” sem permissão) sistemas que apoiam comitês) podem suportar mais funcionalidades do que estritamentesistemas sem missão. Isso inclui a capacidade de manter segredos persistentes, como chaves de assinatura e/ou criptografia – uma possibilidade em nossos projetos. Enfatizamos que DONs podem, em princípio, ser construídos em cima de um comitê baseado ou protocolo de consenso sem permissão e os implantadores DON podem, em última análise, optar por adotar qualquer abordagem. Reforçando os modelos de confiança: Um recurso importante do Chainlink hoje é a capacidade dos usuários de selecionar nós com base em registros descentralizados de seus históricos de desempenho, conforme discutido na Seção 3.6.4. O mecanismo staking e a Estrutura de Incentivos Implícitos que apresentamos na Seção 9 juntos constituem um projeto de mecanismo rigoroso e de amplo escopo estrutura que capacitará os usuários com uma capacidade bastante ampliada de avaliar a segurança de DONs. Esta mesma estrutura também tornará possível para os próprios DONs para impor vários requisitos de segurança nos nós participantes e garantir a operação dentro de modelos de confiança fortes. Também é possível usar as ferramentas descritas neste documento para DONs para impor requisitos especiais de modelo de confiança, como conformidade com requisitos regulatórios. Para Por exemplo, usando técnicas discutidas na Seção 4.3, os nós podem apresentar evidências de características do operador do nó, por exemplo, território de operação, que podem ser usadas para ajudar impor a conformidade com, por exemplo, o Artigo 3 do Regulamento Geral de Proteção de Dados (GDPR) (“Âmbito Territorial”) [105]. Caso contrário, tal conformidade pode ser um desafio para atendem em sistemas descentralizados [45]. Além disso, na Seção 7 discutimos planos para fortalecer a robustez de DONs através de mecanismos de minimização de confiança nas principais cadeias que apoiam.

Decentralized Oracle Network Interface and Ca-

pabilities Here we brieﬂy sketch the capabilities of DONs in terms of the simple but powerful interface they are designed to realize. Applications on a DON are composed of executables and adapters. An executable is a program whose core logic is a deterministic program, analogous to a smart contract. An executable also has a number of accompanying initiators, programs that call entry points in the executable’s logic when predetermined events occur—e.g., at certain times (like a cron job), when a price crosses a threshold, etc.—much like Keepers (see Section 3.6.3). Adapters provide interfaces to oﬀ-chain resources and may be called by either the initiators or core logic in executables. As their behavior may depend on that of external resources, initiators and adapters may behave non-deterministically. We describe the DON developer interface and the functioning of executables and adapters in terms of the three resources typically used to characterize computing systems: networking, compute, and storage. We give a brief overview of each of these resources below and provide more details in Appendix B.

Adapters connecting a DON with different resources including blockchains, web servers, storage, and IoT devices

3.1 Networking Adapters are interfaces through which executables running on a DON can send and receive data from oﬀ-DON systems. Adapters may be viewed as a generalization of the adapters used in Chainlink today [20]. Adapters may be bidirectional—i.e., they cannot just pull, but push data from a DON to a web server. They may also leverage distributed protocols as well as cryptographic functionality such as secure multi-party computation. Figure 9: Adapters connecting a DON, denoted DON1, with a range of diﬀerent resources, including another DON, denoted DON2, a blockchain (main chain) and its mempool, external storage, a web server, and IoT devices (via a web server). Examples of external resources for which adapters might be created are shown in Fig. 9. They include: • Blockchains: An adapter can deﬁne how to send transactions to a blockchain and how to read blocks, individual transactions, or other state from it. An adapter can also be deﬁned for a blockchain’s mempool. (See Section 3.5.) • Web servers: Adapters can deﬁne APIs through which data may be retrieved from web servers, including legacy systems that are not specially adapted for interfacing with DONs. Such adapters can also include APIs to send data to such servers. The web servers to which a DON connects may serve as gateways to additional resources, such as Internet-of-Things (IoT) devices.

• External storage: An adapter can deﬁne methods to read and write to storage services outside the DON, such as a decentralized ﬁle system [40, 188] or cloud storage. • Other DONs: Adapters can retrieve and transmit data between DONs. We expect that initial deployments of DONs will include a set of building block adapters for such commonly used external resources and will further allow DON-speciﬁc adapters to be published by DON nodes. As smart contract developers write adapters today, we expect that they will build even more powerful adapters using this advanced functionality. We expect that ultimately it will be possible for users to create new adapters in a permissionless manner. Some adapters must be constructed in a way that ensures the persistence and availability of external resources controlled by a DON. For example, cloud storage may require maintenance of a cloud services account. Additionally, a DON can perform decentralized management of private keys on behalf of users (as in, e.g., [160]) and/or executables. Consequently, the DON is capable of controlling resources, such as cryptocurrency, that may be used, e.g., for sending transactions on a target blockchain. See Appendix B.1 for further details on DON adapters, as Appendix C for a few example adapters. 3.2 Computation An executable is the basic unit of code on a DON. An executable is a pair exec = (logic, init). Here, logic is a deterministic program with a number of designated entry points (logic1, logic2, . . . , logicℓ) and init is a set of corresponding initiators (init1, init2, . . . , inite). To ensure the full auditability of the DON, an executable’s logic uses the underlying ledger L for all inputs and outputs. Thus, for instance, any adapter data serving as input to an executable must be stored ﬁrst on L. Initiators: Initiators in Chainlink today cause event-dependent job executions on Chainlink nodes [21]. Initiators in DONs function in much the same way. A DON initiator, however, is speciﬁcally associated with an executable. An initiator may depend on an external event or state, on the current time, or on a predicate on DON state. With their dependency on events, initiators may of course behave non-deterministically (as of course may adapters). An initiator can execute within individual DON nodes and so need not rely on an adapter. (See Example 1 below.) Initiators are an important feature distinguishing executables from smart contracts. Because an executable can run in response to an initiator, it can eﬀectively operate autonomously, as of course by extension can a hybrid contract incorporating the executable. One form of initiators today are Chainlink Keepers, which provide transaction

automation services, triggering smart contract execution—such as liquidation of undercollateralized loans and execution of limit-order trades—based on oracle reports. Conveniently, initiators in DONs may also be viewed as a way of specifying the service agreements that apply to an executable, as they deﬁne the circumstances under which the DON must call it. The following example illustrates how initiators work within an executable: Example 1 (Deviation-triggered price feed). A smart contract SC may require fresh price-feed data (see Section 3.6.3) whenever there is a substantial change, e.g., 1%, in the exchange rate between a pair of assets, e.g., ETH-USD. Volatility-sensitive price feeds are supported in Chainlink today, but it is instructive to see how they can be realized on a DON by means of an executable execfeed. The executable execfeed maintains the most recent ETH-USD price r on L, in the form of a sequence of ⟨NewPrice : j, r⟩entries, where j is an index incremented with each price update. An initiator init1 causes each node Oi to monitor the current ETH-USD price for deviations of at least 1% from the most recently stored price r with index j. Upon detection of such a deviation, Oi writes its current view ri of the new price to L using an entry of the form ⟨PriceView : i, j + 1, ri⟩. A second initiator init2 ﬁres when at least k such PriceView-entries with new price values for index j + 1 created by distinct nodes have accumulated on L. Then, init2 invokes an entry point logic2 to compute the median $\rho$ of the ﬁrst $k$ fresh, valid priceview values and writes a fresh value ⟨NewPrice : j + 1, ρ⟩to L . (Operationally, nodes may take turns as designated writers.) A third initiator init3 watches for NewPrice entries on L. Whenever a new report ⟨NewPrice : j, r⟩appears there, it invokes an entry point logic3 that pushes (j, r) to SC using an adapter. As we have noted, an executable is similar in its capabilities to a smart contract. Apart from its higher performance, though, it diﬀers from a typical main chain contract in two essential ways: 1. Conﬁdentiality: An executable can perform conﬁdential computation, i.e., a secret program may process cleartext inputs, or a published program may process secret input data, or a combination of both. In a simple model, secret data can be accessed by DON nodes, which conceal intermediate results and disclose only processed and sanitized values to MAINCHAIN. It is also possible to conceal sensitive data from DONs themselves: DONs are meant to support approaches such as multi-party computation, e.g., [42, 157], and trusted execution environments (TEEs) [84, 133, 152, 229] for this purpose.6 6By extension, keeping executables themselves secret with respect to DON nodes is also possible, although this is only practical today for non-trivial executables using TEEs.

Supporting role: An executable is meant to support smart contracts on a main chain, rather than replace them. An executable has several limitations that a smart contract does not: (a) Trust model: An executable operates within the trust model deﬁned by the DON: Its correct execution relies on the honest behavior of O. (A main chain can, however, provide some guard rails against DON malfeasance, as discussed in Section 7.3.) (b) Asset access: A DON can control an account on a blockchain—and thus control assets on it through an adapter. But a DON cannot authoritatively represent assets created on a main chain, e.g., Ether or ERC20 tokens, since their native chain maintains the authoritative record of their ownership. (c) Lifecycle: DONs may be stood up intentionally with limited lifetimes, as deﬁned by on-chain service level agreements between DONs and the owners of relying contracts. Blockchains, in contrast, are meant to function as permanent archival systems. See Appendix B.2 for further details on DON computation. 3.3 Storage As a committee-based system, a DON can store moderate amounts of data persistently on L at much lower cost than a permissionless blockchain. Additionally, via adapters, DONs can reference external decentralized systems for data storage, e.g., Filecoin [85], and can thereby connect such systems to smart contracts. This option is particularly attractive for bulk data as a means of addressing the pervasive problem of “bloat” in blockchain systems. DONs can thus store data locally or externally for use in their speciﬁcally supported services. A DON can additionally make use of such data in a conﬁdential way, computing on data that is: (1) secret-shared across DON nodes or encrypted under a key managed by DON nodes in ways suitable for secure multi-party computation or partial or fully homomorphic encryption; or (2) protected using a trusted execution environment. We expect that DONs will adopt a simple memory-management model common to smart-contract systems: An executable may only write to its own memory. Executables may, however, read from the memory of other executables. See Appendix B.3 for further details on DON storage. 3.4 Transaction-Execution Framework (TEF) DONs are intended to support contracts on a main chain MAINCHAIN (or on multiple main chains). The Transaction-Execution Framework (TEF), discussed in detail

in Section 6, is a general-purpose approach to the eﬃcient execution of a contract SC across MAINCHAIN and a DON. The TEF is intended to support FSS and layer-2 technologies—simultaneously, if desired. Indeed, it is likely to serve as the main vehicle for use of FSS (and for that reason, we do not further discuss FSS in this section). Brieﬂy, in TEF an original target contract SC designed or developed for MAINCHAIN is refactored into a hybrid contract. This refactoring produces the two interoperating pieces of the hybrid contract: a MAINCHAIN contract SCa that we refer to for clarity in the context of TEFs as an anchor contract and an executable execs on a DON. The contract SCa custodies users’ assets, executes authoritative state transitions, and also provides guard rails (see Section 7.3) against failures in the DON. The executable execs sequences transactions and provides associated oracle data for them. It can bundle transactions for SCa in any of a number of ways—e.g., using validity-proof-based or optimistic rollups, conﬁdential execution by the DON, etc. We expect to develop tools that make it easy for developers to partition a contract SC written in a high-level language into pieces of MAINCHAIN and DON logic, SCa and execs respectively, that compose securely and eﬃciently. Using TEF to integrate high-performance transaction schemes with high-performance oracles is integral to our oracle scaling approach. 3.5 Mempool Services An important application-layer feature that we intend to deploy on DONs in support of FSS and the TEF are Mempool Services (MS). MS may be viewed as an adapter, but one with ﬁrst-class support. MS provides support for legacy-compatible transaction processing. In this use, MS ingests from a main chain’s mempool those transactions intended for a target contract SC on MAINCHAIN. MS then passes these transactions to an executable on the DON, where they are processed in the desired way. MS data can be used by the DON to compose transactions that can then be passed directly to SC from the DON or to another contract that calls SC. For example, the DON can forward transactions harvested via MS, or it can use MS data to set gas prices for transactions it sends to MAINCHAIN. Because it monitors the mempool, MS can obtain transactions from users interacting directly with SC. Thus users may continue to generate their transactions using legacy software, i.e., applications unaware of the existence of MS and MS-conﬁgured contracts. (In this case, SC must be changed to ignore the original transactions and accept only those processed by the MS, so as to avoid double-processing.) For use with a target contract SC, MS can be used with FSS and/or the TEF.

3.6 Stepping Stones: Existing Chainlink Capabilities 3.6.1 Oﬀ-Chain Reporting (OCR) Oﬀ-Chain Reporting (OCR) [60] is a mechanism in Chainlink for oracle report aggregation and transmission to a relying contract SC. Recently deployed for Chainlink price feed networks, it represents a ﬁrst step along the path to full DONs. At its core, OCR is a BFT protocol designed to operate in a partially synchronous network. It ensures liveness and correctness in the presence of $f < n/3$ arbitrarily faulty nodes, guaranteeing the properties of Byzantine reliable broadcast, but it is not a complete BFT consensus protocol. Nodes do not maintain message logs that are consistent in the sense of representing a ledger that is identical in all of their views, and the leader of the protocol may equivocate without violating safety. OCR is currently designed for a particular message type: medianized aggregation of (at least $2f + 1$) values reported by participating nodes. It provides a key assurance on the reports it outputs for SC, called attested reports: The median value in an attested report is equal to or lies between values reported by two honest nodes. This property is the key safety condition for OCR. The leader may have some inﬂuence on the median value in an attested report, but only subject to this correctness condition. OCR can be extended to message types that aggregate values in diﬀerent ways. While the Chainlink network’s liveness and correctness goals today do not require OCR to be a full-blown consensus protocol, they do require OCR to provide some additional forms of functionality not present in conventional BFT protocols, most notably: 1. All-or-nothing oﬀ-chain report broadcast: OCR ensures that an attested report is made quickly available to all honest nodes or none of them. This is a fairness property that helps ensure that honest nodes have an opportunity to participate in attested report transmission. 2. Reliable transmission: OCR ensures, even in the presence of faulty or malicious nodes, that all OCR reports and messages are transmitted to SC within a certain, pre-deﬁned interval of time. This is a liveness property. 3. Contract-based trust minimization: SC ﬁlters out potentially erroneous OCRgenerated reports, e.g., if their reported values deviate signiﬁcantly from other recently received ones. This is a form of extra-protocol correctness enforcement. All three of these properties will play a natural role in DONs. All-or-nothing oﬀchain (DON) broadcast is an important building block for cryptoeconomic assurances around reliable transmission, which is in turn an essential adapter property. Trust minimization in SC is a type of guard rail, as discussed in Section 7.3. OCR also provides a basis for operational deployment and reﬁnement of BFT protocols in Chainlink’s oracle networks and thus, as noted above, a path to the full functionality of DONs.

3.6.2 DECO and Town Crier DECO [234] and Town Crier [233] are a pair of related technologies currently being developed in Chainlink networks. Most web servers today allow users to connect over a secure channel using a protocol called Transport Layer Security (TLS) [94]. (HTTPS indicates a variant of HTTP that is enabled with TLS, i.e., URLs preﬁxed with “https” denote use of TLS for security.) Most TLS-enabled servers have a notable limitation, though: They don’t digitally sign data. Consequently, a user or Prover cannot present the data she receives from a server to a third party or Veriﬁer, such as an oracle or smart contract, in a way that ensures the data’s authenticity. Even if a server were to digitally sign data, there remains a problem of conﬁdentiality. A Prover may wish to redact or modify sensitive data before presenting it to a Veriﬁer. Digital signatures are designed speciﬁcally to invalidate modiﬁed data, however. They thus prevent a Prover from making conﬁdentiality-preserving alterations to data. (See Section 7.1 for more discussion.) DECO and Town Crier are designed to allow a Prover to obtain data from a web server and present it to a Veriﬁer in a way that ensures integrity and conﬁdentiality. The two systems preserve integrity in the sense that they ensure that data presented by the Prover to the Veriﬁer originates authentically from the target server. They support conﬁdentiality in the sense of allowing the Prover to redact or modify data (while still preserving integrity). A key feature of both systems is that they do not require any modiﬁcations to a target web server. They can operate with any existing TLS-enabled server. In fact, they are transparent to the server: From the viewpoint of the server, the Prover is establishing an ordinary connection. The two systems have similar goals, but diﬀer in their trust models and implementations as we now brieﬂy explain. DECO makes fundamental use of cryptographic protocols to achieve its integrity and conﬁdentiality properties. While establishing a session with a target server using DECO, the Prover engages at the same time in an interactive protocol with the Veriﬁer. This protocol enables the Prover to prove to the Veriﬁer that it has received a given piece of data D from the server during its current session. The Prover can alternatively present the Veriﬁer with a zero-knowledge proof of some property of D and thus not reveal D directly. In a typical use of DECO, a user or a single node can export data D from a private session with a web server to all of the nodes in a DON. As a result, the full DON can attest to the authenticity of D (or a fact derived from D via a zero-knowledge proof). In addition to the example applications given later in the paper, this capability can be used to amplify high-integrity access to a data source by a DON. Even if only one node has direct access to a data source—due, for instance, to an exclusive arrangement with a data provider—it remains possible for the entire DON to attest to the correctness of

reports emitted by that node. Town Crier relies on the use of a trusted execution environment (TEE) such as Intel SGX. Brieﬂy, a TEE functions as a kind of black box that executes applications in a tamperproof and conﬁdential way. In principle, even the owner of the host on which the TEE is running can neither (undetectably) alter a TEE-protected application nor view the application’s state, which may include secret data. Town Crier can achieve all of the functionality of DECO and more. DECO constrains the Prover to interaction with a single Veriﬁer. In contrast, Town Crier enables a Prover to generate a publicly veriﬁable proof on data D fetched from a target server, i.e., a proof that anyone, even a smart contract, can verify directly. Town Crier can also securely ingest and make use of secrets (e.g., user credentials). The main limitation of Town Crier is its reliance on TEEs. Production TEEs have recently been shown to have a number of serious vulnerabilities, although the technology is in its infancy and will undoubtedly mature. See Appendices B.2.1 and B.2.2 for further discussion of TEEs. For a few example applications of DECO and Town Crier, see Sections 4.3, 4.5 and 9.4.3 and Appendix C.1. 3.6.3 Existing On-Chain Chainlink Services Chainlink oracle networks provide a number of main services across a multiplicity of blockchains and other decentralized systems today. Further evolution as described in this whitepaper will endow these existing services with additional capabilities and reach. Three examples are: Data feeds: Today, the majority of Chainlink users relying on smart contracts make use of data feeds. These are reports on the current value of key pieces of data according to authoritative oﬀ-chain sources. For example, price feeds are feeds reporting the prices of assets—cryptocurrencies, commodities, forex, indexes, equities, etc.—according to exchanges or data-aggregation services. Such feeds today already help secure billions of dollars in on-chain value through their use in DeFi systems such as Aave [147] and Synthetix [208]. Other examples of Chainlink data feeds include weather data for parametric crop insurance [75] and election data [93], among a number of others. The deployment of DONs and other technologies described in this paper will enhance provision of data feeds in Chainlink networks in many ways, including: • Scaling: OCR and subsequently DONs aim to enable Chainlink services to scale dramatically across the many blockchains they support. For example, we expect that DONs will help increase the number of data feeds provided by nodes using Chainlink from 100s to 1000s and beyond. Such scaling will help the Chainlink ecosystem achieve its goal of furnishing data relevant to smart contracts comprehensively and both meeting and anticipating existing and future needs.

• Enhanced security: By storing intermediate reports, DONs will retain records of node behaviors for high-ﬁdelity monitoring and measurement of their performance and accuracy, enabling strong empirical grounding of reputation systems for Chainlink nodes. FSS and the TEF will enable price feeds to be incorporated with transaction data in ﬂexible ways that prevent attacks such as front-running. (Explicit) staking will bolster existing cryptoeconomic protection of the security of data feeds. • Feed agility: As blockchain-agnostic systems (indeed, more broadly, consumeragnostic systems), DONs can facilitate the provision of data feeds to a multiplicity of relying systems. A single DON can push a given feed simultaneously to a set of diﬀerent blockchains, eliminating the need for per-chain oracle networks and enabling rapid deployment of existing feeds on new blockchains and of additional feeds across currently serviced blockchains. • Conﬁdentiality: The ability to perform generalized computation in a DON enables computations on sensitive data to take place oﬀchain, avoiding on-chain exposure. Additionally, using DECO or Town Crier, it is possible to achieve even stronger conﬁdentiality, allowing report generation based on data that isn’t exposed even to DON nodes. See Section 4.3 and Section 4.5 for examples. Veriﬁable Random Functions (VRFs): Several types of DApps require a veriﬁably correct source of randomness to enable veriﬁcation of their own fair operation. Non-Fungible Tokens (NFTs) are an example. The rarity of NFT features in Aavegotchi [23] and Axie Inﬁnity [35] is determined by Chainlink VRF, as is the distribution of NFTs by means of ticket-based drawings in Ether Cards [102]; the wide variety of gaming DApps whose outcomes are randomized; and unconventional ﬁnancial instruments, e.g., no-loss savings games such as PoolTogether [89], which allocate funds to random winners. Other blockchain and non-blockchain applications also require secure sources of randomness, including selection of decentralized-system committees and the execution of lotteries. While block hashes can serve as a source of unpredictable randomness, they are vulnerable to manipulation by adversarial miners (and to some extent by users submitting transactions). Chainlink VRF [78] oﬀers a considerably more secure alternative. An oracle has an associated private / public key pair (sk, pk) whose private key is maintained oﬀchain and whose public key pk is published. To output a random value, it applies sk to an unpredictable seed x furnished by a relying contract (e.g., a block hash and DApp-speciﬁc parameters) using a function F, yielding y = Fsk(x) along with a proof of correctness. (See [180] for the VRF available on Chainlink.) What makes a VRF veriﬁable is the fact that with knowledge of pk, it is possible to check the correctness of the proof and therefore of y. The value y is consequently unpredictable to an adversary that cannot predict x or learn sk and infeasible for the service to manipulate.

Chainlink VRF may be viewed as just one of a family of applications that involve custodianship of private keys oﬀchain. More generally, DONs can oﬀer secure, decentralized storage of individual keys for applications and/or users, and combine this capability with generalized computation. The result is a host of applications, of which we give some examples in this paper, including key management for Proof of Reserves (see Section 4.1) and for users’ decentralized credentials (and other digital assets) (see Section 4.3). Keepers: Chainlink Keepers [87] enable developers to write code for decentralized execution of oﬀ-chain jobs, generally to trigger execution of relying smart contracts. Before the advent of Keepers, it was common for developers to operate such oﬀ-chain logic themselves, creating centralized points of failure (as well as considerable duplicated development eﬀort). Keepers instead provide an easy-to-use framework for decentralized outsourcing of these operations, enabling shorter development cycles and strong assurance of liveness and other security properties. Keepers can support any of a wide variety of triggering goals, including price-dependent liquidation of loans or execution of ﬁnancial transactions, time-dependent initiation of airdrops or payments in systems with yield harvesting, and so forth. In the DON framework, initiators may be viewed as a generalization of Keepers in several senses. Initiators may make use of adapters, and thus can leverage a modularized library of interfaces to on-chain and oﬀ-chain systems, permitting rapid development of secure, sophisticated functionality. Initiators initiate computation in executables, which themselves oﬀer the full versatility of DONs, permitting the wide range of decentralized services we present in this paper for on-chain and oﬀ-chain applications. 3.6.4 Node Reputation / Performance History The existing Chainlink ecosystem natively documents the performance histories of contributing nodes on chain. This feature has given rise to a collection of reputationoriented resources that ingest, ﬁlter, and visualize performance data on individual node operators and data feeds. Users can reference these resources to make informed decisions in their selection of nodes and to monitor the operation of existing networks. Similar capabilities will help users choose DONs. For example, permissionless marketplaces today such as market.link allow node operators to list their oracle services and attest to their oﬀ-chain identities through services such as Keybase [4], which bind the proﬁle of a node in Chainlink to its owner’s existing domain names and social media accounts. Additionally, performance analytics tools, such as those available at market.link and reputation.link, allow users to view statistics on the historical performance of individual nodes, including their average response latency, the deviation of values in their reports from consensus values relayed on chain, revenue generated, jobs fulﬁlled, and more. These analytics tools also allow users to track the adoption of various oracle networks by other users, a form of

implicit endorsement of the nodes securing such networks. The result is a ﬂat “web of trust” in which, by using particular nodes, high-value decentralized applications create a signal of their trust in those nodes that other users can observe and factor into their own node-selection decisions. With DONs (and initially with OCR) comes a shift in transaction processing and contract activity more generally oﬀchain. A decentralized model for recording node performance remains possible within the DON itself. Indeed, the high performance and data capacity of DONs make it possible to construct records in a ﬁne-grained way and also to perform decentralized computation on these records, yielding trustworthy summaries that can be consumed by reputation services and checkpointed on MAINCHAIN. While it is possible for a DON in principle to misrepresent the behavior of constituent nodes if a large fraction of nodes is corrupted, we note that the collective performance of a DON itself in delivering on-chain data is visible on MAINCHAIN and thus cannot be misrepresented. Additionally, we plan to explore mechanisms that incentivize accurate internal reporting of node behaviors in a DON. For example, by reporting the subset of high-performing nodes that most quickly return data contributing to a report relayed on chain, a DON creates an incentive for nodes to contest incorrect reports: Incorrectly including nodes in this subset means incorrectly excluding nodes that should have been included and therefore invalidly penalizing them. Repeated reporting failures by a DON would also create an incentive for honest nodes to leave the DON. Decentralized compilation of accurate performance histories and the consequent ability of users to identify high-performing nodes and for node operators to build reputations are important distinguishing features of the Chainlink ecosystem. We show in Section 9 how we can reason about them as a key piece of a rigorous and expansive view of the economic security provided by DONs.

Interface de rede Oracle descentralizada e Ca-

habilidades Aqui esboçamos brevemente as capacidades de DONs em termos do simples, mas poderoso interface que eles foram projetados para realizar. Os aplicativos em DON são compostos de executáveis e adaptadores. Um executável é um programa cuja lógica central é um programa determinístico, análogo a um smart contract. Um executável também possui vários iniciadores, programas que chamam entrada pontos na lógica do executável quando ocorrem eventos predeterminados - por exemplo, em determinados momentos (como um cron job), quando um preço ultrapassa um limite, etc. – muito parecido com o Keepers (consulte a Seção 3.6.3). Adaptadores fornecem interfaces para recursos fora da cadeia e podem ser chamados por os iniciadores ou a lógica central dos executáveis. Como o comportamento deles pode depender disso de recursos externos, iniciadores e adaptadores podem se comportar de forma não determinística. Descrevemos a interface do desenvolvedor DON e o funcionamento de executáveis e adaptadores em termos dos três recursos normalmente usados para caracterizar sistemas de computação: rede, computação e armazenamento. Damos uma breve visão geral de cada um desses recursos abaixo e forneça mais detalhes no Apêndice B.

Adapters connecting a DON with different resources including blockchains, web servers, storage, and IoT devices

3.1 Rede Adaptadores são interfaces através das quais executáveis em execução em um DON podem enviar e receber dados de sistemas off-DON. Adaptadores podem ser vistos como uma generalização de os adaptadores usados em Chainlink hoje [20]. Os adaptadores podem ser bidirecionais, ou seja, eles não pode apenas extrair, mas enviar dados de um DON para um servidor web. Eles também podem aproveitar protocolos distribuídos, bem como funcionalidade criptográfica, como segurança multipartidária computação. Figura 9: Adaptadores conectando um DON, denotado DON1, com uma variedade de recursos diferentes, incluindo outro DON, denotado DON2, um blockchain (cadeia principal) e seu mempool, armazenamento externo, um servidor web e dispositivos IoT (por meio de um servidor web). São mostrados exemplos de recursos externos para os quais adaptadores podem ser criados na Fig. 9. Eles incluem: • Blockchains: um adaptador pode definir como enviar transações para um blockchain e como ler blocos, transações individuais ou outro estado dele. Um adaptador também pode ser definido para um mempool de blockchain. (Ver Seção 3.5.) • Servidores Web: Os adaptadores podem definir APIs através das quais os dados podem ser recuperados de servidores web, incluindo sistemas legados que não são especialmente adaptados para fazendo interface com DONs. Esses adaptadores também podem incluir APIs para enviar dados para tais servidores. Os servidores web aos quais um DON se conecta podem servir como gateways a recursos adicionais, como dispositivos de Internet das Coisas (IoT).• Armazenamento externo: um adaptador pode definir métodos para ler e gravar no armazenamento serviços fora do DON, como um sistema de arquivos descentralizado [40, 188] ou nuvem armazenamento. • Outros DONs: Os adaptadores podem recuperar e transmitir dados entre DONs. Esperamos que as implantações iniciais de DONs incluam um conjunto de blocos de construção adaptadores para recursos externos comumente usados e permitirá ainda DON específicos adaptadores a serem publicados pelos nós DON. À medida que os desenvolvedores smart contract escrevem adaptadores hoje, esperamos que eles construam adaptadores ainda mais poderosos usando este avançado funcionalidade. Esperamos que, em última análise, seja possível aos usuários criar novos adaptadores em um maneira sem permissão. Alguns adaptadores devem ser construídos de forma a garantir a persistência e disponibilidade de recursos externos controlados por um DON. Por exemplo, o armazenamento em nuvem pode exigem a manutenção de uma conta de serviços em nuvem. Além disso, um DON pode executar gerenciamento descentralizado de chaves privadas em nome dos usuários (como em, por exemplo, [160]) e/ou executáveis. Consequentemente, o DON é capaz de controlar recursos, como criptomoeda, que podem ser usados, por exemplo, para enviar transações em um alvo blockchain. Consulte o Apêndice B.1 para obter mais detalhes sobre os adaptadores DON, assim como o Apêndice C para alguns exemplo de adaptadores. 3.2 Computação Um executável é a unidade básica de código em um DON. Um executável é um par exec = (lógica, inicialização). Aqui, a lógica é um programa determinístico com um número de entradas designadas pontos (logic1, logic2, . . . , logicℓ) e init é um conjunto de iniciadores correspondentes (init1, init2, . . . , iniciar). Para garantir a auditabilidade total do DON, a lógica de um executável usa o razão subjacente L para todas as entradas e saídas. Assim, por exemplo, qualquer adaptador os dados que servem como entrada para um executável devem ser armazenados primeiro em L. Iniciadores: Os iniciadores em Chainlink hoje causam execuções de tarefas dependentes de eventos em Chainlink nós [21]. Os iniciadores em DONs funcionam da mesma maneira. Um iniciador DON, entretanto, está especificamente associado a um executável. Um iniciador pode depender em um evento ou estado externo, na hora atual ou em um predicado no estado DON. Com a sua dependência de eventos, os iniciadores podem, naturalmente, comportar-se de forma não determinística. (como é claro, os adaptadores). Um iniciador pode ser executado em nós DON individuais e portanto não precisa depender de um adaptador. (Veja o Exemplo 1 abaixo.) Iniciadores são um recurso importante que distingue executáveis de smart contracts. Como um executável pode ser executado em resposta a um iniciador, ele pode operar efetivamente de forma autônoma, como é claro, por extensão, um contrato híbrido que incorpora o executável. Uma forma de iniciadores hoje são Chainlink Keepers, que fornecem transaçõesserviços de automação, desencadeando a execução de smart contract – como liquidação de empréstimos com garantia insuficiente e execução de negociações com ordens de limite – com base em relatórios oracle. Convenientemente, os iniciadores em DONs também podem ser vistos como uma forma de especificar o contratos de serviço que se aplicam a um executável, pois definem as circunstâncias sob qual o DON deve chamá-lo. O exemplo a seguir ilustra como os iniciadores funcionam em um executável: Exemplo 1 (feed de preço acionado por desvio). Um smart contract SC pode exigir novos dados de alimentação de preços (ver Seção 3.6.3) sempre que houver uma mudança substancial, por exemplo, 1%, em a taxa de câmbio entre um par de ativos, por exemplo, ETH-USD. Preço sensível à volatilidade feeds são suportados em Chainlink hoje, mas é instrutivo ver como eles podem ser realizado em um DON por meio de um execfeed executável. O executável execfeed mantém o preço ETH-USD mais recente r em L, no forma de uma sequência de ⟨NewPrice: j, r⟩entries, onde j é um índice incrementado com cada atualização de preço. Um iniciador init1 faz com que cada nó Oi monitore o preço atual do ETH-USD para desvios de pelo menos 1% do preço armazenado mais recentemente r com índice j. Após detecção de tal desvio, a Oi escreve sua visão atual ri do novo preço para L usando uma entrada no formato ⟨PriceView : i, j + 1, ri⟩. Um segundo iniciador init2 é acionado quando pelo menos k dessas entradas PriceView com novo preço valores para o índice j + 1 criados por nós distintos foram acumulados em L. Então, init2 invoca uma lógica de ponto de entrada2 para calcular a mediana ρ dos primeiros k valores novos e válidos de priceview e grava um novo valor ⟨NewPrice : j + 1, ρ⟩to L . (Operacionalmente, nós podem se revezar como escritores designados.) Um terceiro iniciador init3 observa as entradas NewPrice em L. Sempre que um novo relatório ⟨NewPrice : j, r⟩aparece lá, invoca uma lógica de ponto de entrada3 que empurra (j, r) para SC usando um adaptador. Como observamos, um executável é semelhante em suas capacidades a um smart contract. Além de seu desempenho superior, difere de um contrato típico da cadeia principal. de duas maneiras essenciais: 1. Confidencialidade: Um executável pode realizar computação confidencial, ou seja, um programa secreto pode processar entradas de texto não criptografado, ou um programa publicado pode processar dados de entrada secretos ou uma combinação de ambos. Num modelo simples, os dados secretos podem ser acessado por nós DON, que ocultam resultados intermediários e divulgam apenas valores processados e higienizados para MAINCHAIN. Também é possível ocultar dados confidenciais dos próprios DONs: DONs destinam-se a apoiar abordagens como como computação multipartidária, por exemplo, [42, 157] e ambientes de execução confiáveis (TEEs) [84, 133, 152, 229] para esse fim.6 6Por extensão, também é possível manter os próprios executáveis em segredo em relação aos nós DON, embora isso só seja prático hoje para executáveis não triviais usando TEEs.2. Função de suporte: um executável destina-se a suportar smart contracts em um servidor principal cadeia, em vez de substituí-los. Um executável tem várias limitações que um smart contract não: (a) Modelo de confiança: um executável opera dentro do modelo de confiança definido pelo DON: Sua execução correta depende do comportamento honesto de O. (A principal cadeia pode, no entanto, fornecer algumas barreiras de proteção contra DON prevaricação, como discutido na Seção 7.3.) (b) Acesso a ativos: Um DON pode controlar uma conta em um blockchain - e, portanto, controlar ativos nele por meio de um adaptador. Mas um DON não pode ser autorizado representam ativos criados em uma cadeia principal, por exemplo, Ether ou ERC20 tokens, uma vez que sua cadeia nativa mantém o registro oficial de sua propriedade. (c) Ciclo de vida: DONs podem ser levantados intencionalmente com vida útil limitada, como definido por acordos de nível de serviço na cadeia entre DONs e os proprietários de contratos confiáveis. Blockchains, por outro lado, devem funcionar como sistemas de arquivo permanente. Consulte o Apêndice B.2 para obter mais detalhes sobre o cálculo de DON. 3.3 Armazenamento Como um sistema baseado em comitê, um DON pode armazenar quantidades moderadas de dados de forma persistente em L a um custo muito menor do que um blockchain sem permissão. Além disso, através de adaptadores, DONs podem fazer referência a sistemas descentralizados externos para armazenamento de dados, por exemplo, Filecoin [85], e pode, assim, conectar tais sistemas a smart contracts. Esta opção é particularmente atraente para dados em massa como forma de resolver o problema generalizado de “inchaço” em blockchain sistemas. DONs podem, portanto, armazenar dados local ou externamente para uso em seus serviços especificamente suportados. Um DON também pode fazer uso desses dados de forma confidencial, computação em dados que são: (1) compartilhados em segredo entre nós DON ou criptografados em uma chave gerenciada por nós DON de maneira adequada para computação multipartidária segura ou criptografia parcial ou totalmente homomórfica; ou (2) protegido usando uma execução confiável ambiente. Esperamos que DONs adotem um modelo simples de gerenciamento de memória comum a sistemas de contrato inteligente: um executável só pode gravar em sua própria memória. Executáveis pode, no entanto, ler da memória de outros executáveis. Consulte o Apêndice B.3 para obter mais detalhes sobre o armazenamento DON. 3.4 Estrutura de Execução de Transações (TEF) DONs destinam-se a apoiar contratos em uma cadeia principal MAINCHAIN (ou em várias cadeias principais). O Transaction-Execution Framework (TEF), discutido em detalhesna Seção 6, é uma abordagem de propósito geral para a execução eficiente de um contrato SC em MAINCHAIN e um DON. O TEF destina-se a apoiar FSS e camada 2 tecnologias - simultaneamente, se desejado. Na verdade, é provável que sirva como o principal veículo para uso do FSS (e por essa razão, não discutiremos mais detalhadamente o FSS nesta seção). Resumidamente, no TEF, um contrato-alvo original SC projetado ou desenvolvido para MAINCHAIN é refatorado em um contrato híbrido. Essa refatoração produz os dois processos interoperacionais partes do contrato híbrido: um contrato MAINCHAIN SCa ao qual nos referimos para maior clareza no contexto dos TEFs como um contrato âncora e um executivo executável em um DON. O O contrato SCa custodia os ativos dos usuários, executa transições de estado autorizadas e também fornece guarda-corpos (consulte a Seção 7.3) contra falhas no DON. Os executivos executáveis sequencia transações e fornece dados oracle associados para elas. Pode agrupar transações para SCa de várias maneiras - por exemplo, usando provas de validade ou rollups otimistas, execução confidencial por DON, etc. Esperamos desenvolver ferramentas que facilitem aos desenvolvedores a partição de um contrato SC escrito em uma linguagem de alto nível em partes da lógica MAINCHAIN e DON, SCa e executivos respectivamente, que compõem com segurança e eficiência. Usando TEF para integrar esquemas de transações de alto desempenho com transações de alto desempenho oracles é parte integrante da nossa abordagem de escalonamento oracle. 3.5 Serviços de mempool Um recurso importante da camada de aplicação que pretendemos implantar em DONs para suporte do FSS e do TEF são Mempool Services (MS). MS pode ser visto como um adaptador, mas com suporte de primeira classe. MS fornece suporte para processamento de transações compatíveis com legado. Neste uso, MS ingere do mempool de uma cadeia principal as transações destinadas a um contrato alvo SC em MAINCHAIN. A MS então passa essas transações para um executável no DON, onde são processados da maneira desejada. Os dados MS podem ser usados pelo DON para compor transações que podem então ser passadas diretamente para SC a partir do DON ou para outro contrato que chama SC. Por exemplo, o DON pode encaminhar transações colhido via MS, ou pode usar dados do MS para definir os preços do gás para as transações que envia para MAINCHAIN. Por monitorar o mempool, o MS pode obter transações de usuários interagindo diretamente com o SC. Assim, os usuários podem continuar a gerar suas transações usando software legado, ou seja, aplicativos que desconhecem a existência de MS e software configurado por MS contratos. (Neste caso, SC deve ser alterado para ignorar as transações originais e aceitar apenas os processados pelo MS, de modo a evitar o duplo processamento.) Para uso com um SC de contrato-alvo, o MS pode ser usado com o FSS e/ou o TEF.3.6 trampolins: capacidades Chainlink existentes 3.6.1 Relatórios fora da cadeia (OCR) Relatórios fora da cadeia (OCR) [60] é um mecanismo em Chainlink para oracle agregação e transmissão de relatórios para um SC de contrato confiável. Implantado recentemente pelo preço de Chainlink redes de alimentação, representa um primeiro passo no caminho para DONs completos. Em sua essência, OCR é um protocolo BFT projetado para operar de forma parcialmente síncrona. rede. Garante vivacidade e correção na presença de f <n/3 arbitrariamente nós defeituosos, garantindo as propriedades da transmissão confiável bizantina, mas não é um protocolo de consenso BFT completo. Os nós não mantêm logs de mensagens que são consistente no sentido de representar um livro-razão que é idêntico em todas as suas visões, e o líder do protocolo pode equivocar-se sem violar a segurança. OCR é atualmente projetado para um tipo específico de mensagem: agregação mediana de (pelo menos 2f +1) valores relatados pelos nós participantes. Ele fornece uma garantia fundamental sobre os relatórios que ele gera para SC, chamados de relatórios atestados: O valor mediano em um atestado report é igual ou está entre os valores relatados por dois nós honestos. Esta propriedade é a principal condição de segurança para OCR. O líder pode ter alguma influência sobre a mediana valor em laudo atestado, mas somente sujeito a esta condição de correção. OCR pode ser estendido a tipos de mensagens que agregam valores de diferentes maneiras. Embora as metas de atividade e correção da rede Chainlink hoje não exijam Para que o OCR seja um protocolo de consenso completo, eles exigem que o OCR forneça algumas formas adicionais de funcionalidade não presentes nos protocolos BFT convencionais, mais notavelmente: 1. Transmissão de relatório fora da cadeia do tipo tudo ou nada: OCR garante que um relatório atestado é disponibilizado rapidamente para todos os nós honestos ou para nenhum deles. Isto é uma justiça propriedade que ajuda a garantir que nós honestos tenham a oportunidade de participar na transmissão de relatório atestado. 2. Transmissão confiável: OCR garante, mesmo na presença de falhas ou mal-intencionados nós, que todos os relatórios e mensagens de OCR são transmitidos ao SC dentro de um determinado, intervalo de tempo pré-definido. Esta é uma propriedade de vivacidade. 3. Minimização da confiança baseada em contrato: o SC filtra relatórios gerados por OCR potencialmente errados, por exemplo, se seus valores relatados se desviarem significativamente de outros recebidos recentemente. Esta é uma forma de aplicação de correção extraprotocolo. Todas essas três propriedades desempenharão um papel natural em DONs. A transmissão off-chain do tipo tudo ou nada (DON) é um importante alicerce para garantias criptoeconômicas em torno da transmissão confiável, que por sua vez é uma propriedade essencial do adaptador. Confiança a minimização em SC é um tipo de guarda-corpo, conforme discutido na Seção 7.3. OCR também fornece uma base para implantação operacional e refinamento de protocolos BFT nas redes Chainlink de oracle e, portanto, como observado acima, um caminho para a plena funcionalidade de DONs.3.6.2 DECO e Pregoeiro DECO [234] e Town Crier [233] são um par de tecnologias relacionadas atualmente em desenvolvido em redes Chainlink. A maioria dos servidores web hoje permite que os usuários se conectem através de um canal seguro usando um protocolo chamado Transport Layer Security (TLS) [94]. (HTTPS indica uma variante de HTTP que está habilitado com TLS, ou seja, URLs prefixados com “https” indicam o uso de TLS para segurança.) A maioria dos servidores habilitados para TLS tem uma limitação notável: eles não assinam digitalmente dados. Consequentemente, um usuário ou Prover não pode apresentar os dados que recebe de um servidor a um terceiro ou verificador, como um oracle ou smart contract, de uma forma que garanta a autenticidade dos dados. Mesmo que um servidor assinasse digitalmente os dados, ainda existiria um problema de confidencialidade. Um Provador pode desejar redigir ou modificar dados confidenciais antes de apresentá-los a um Verificador. Entretanto, as assinaturas digitais são projetadas especificamente para invalidar dados modificados. Assim, evitam que um Provador faça alterações que preservem a confidencialidade. aos dados. (Veja a Seção 7.1 para mais discussão.) DECO e Town Crier são projetados para permitir que um provador obtenha dados de uma web servidor e apresentá-lo a um verificador de uma forma que garanta integridade e confidencialidade. Os dois sistemas preservam a integridade no sentido de garantirem que os dados apresentados pelos o Provador para o Verificador se origina autenticamente do servidor de destino. Eles apoiam confidencialidade no sentido de permitir que o Provador edite ou modifique os dados (enquanto ainda preservando a integridade). Uma característica fundamental de ambos os sistemas é que eles não exigem nenhuma modificação em um servidor web de destino. Eles podem operar com qualquer servidor existente habilitado para TLS. Na verdade, eles são transparentes para o servidor: Do ponto de vista do servidor, o Provador é estabelecendo uma conexão comum. Os dois sistemas têm objetivos semelhantes, mas diferem em seus modelos de confiança e implementações, como explicaremos brevemente agora. DECO faz uso fundamental de protocolos criptográficos para alcançar sua integridade e propriedades de confidencialidade. Ao estabelecer uma sessão com um servidor alvo usando DECO, o Provador se envolve ao mesmo tempo em um protocolo interativo com o Verificador. Este protocolo permite ao Provador provar ao Verificador que recebeu um determinado dado D do servidor durante sua sessão atual. O Provador pode alternativamente, apresente ao Verificador uma prova de conhecimento zero de alguma propriedade de D e, portanto, não revela D diretamente. Em um uso típico do DECO, um usuário ou um único nó pode exportar dados D de um servidor privado. sessão com um servidor web para todos os nós em um DON. Como resultado, o DON completo pode atestar a autenticidade de D (ou um fato derivado de D através de uma prova de conhecimento zero). Além dos exemplos de aplicações dados posteriormente neste artigo, esse recurso pode ser usado para amplificar o acesso de alta integridade a uma fonte de dados por um DON. Mesmo que apenas um nó tem acesso direto a uma fonte de dados – devido, por exemplo, a um acordo exclusivo com um provedor de dados - ainda é possível para todo o DON atestar a exatidão derelatórios emitidos por esse nó. Town Crier depende do uso de um ambiente de execução confiável (TEE), como Intel SGX. Resumidamente, um TEE funciona como uma espécie de caixa preta que executa aplicações de uma forma forma inviolável e confidencial. Em princípio, mesmo o proprietário do host no qual o TEE está em execução não pode alterar (de forma indetectável) um aplicativo protegido por TEE nem visualizar o estado do aplicativo, que pode incluir dados secretos. Town Crier pode alcançar todas as funcionalidades do DECO e muito mais. DECO restringe o Provador à interação com um único Verificador. Em contraste, o Town Crier permite um provador para gerar uma prova publicamente verificável sobre os dados D obtidos de um servidor de destino, ou seja, uma prova que qualquer pessoa, mesmo um smart contract, pode verificar diretamente. O Pregoeiro da Cidade pode também ingerir e usar segredos com segurança (por exemplo, credenciais de usuário). A principal limitação do Town Crier é a sua dependência dos TEEs. Os ETEs de produção têm recentemente demonstrou ter uma série de vulnerabilidades graves, embora a tecnologia esteja na sua infância e irá, sem dúvida, amadurecer. Consulte os Apêndices B.2.1 e B.2.2 para discussão mais aprofundada sobre ETEs. Para alguns exemplos de aplicações de DECO e Town Crier, consulte as Seções 4.3, 4.5 e 9.4.3 e Apêndice C.1. 3.6.3 Serviços Chainlink existentes na rede As redes Chainlink oracle fornecem vários serviços principais em uma multiplicidade de blockchains e outros sistemas descentralizados hoje. Evolução adicional conforme descrito neste whitepaper dotará esses serviços existentes com recursos adicionais e alcance. Três exemplos são: Feeds de dados: Hoje, a maioria dos usuários de Chainlink que dependem de smart contracts fazem uso de feeds de dados. Estes são relatórios sobre o valor atual dos principais dados de acordo com para fontes oficiais fora da cadeia. Por exemplo, feeds de preços são feeds que informam os preços de ativos - criptomoedas, commodities, forex, índices, ações, etc. - de acordo com trocas ou serviços de agregação de dados. Esses feeds hoje já ajudam a garantir bilhões de dólares em valor na cadeia por meio de seu uso em sistemas DeFi como Aave [147] e Sintetix [208]. Outros exemplos de feeds de dados Chainlink incluem dados meteorológicos para seguro agrícola paramétrico [75] e dados eleitorais [93], entre vários outros. A implantação de DONs e outras tecnologias descritas neste documento melhorará o fornecimento de feeds de dados em redes Chainlink de várias maneiras, incluindo: • Dimensionamento: OCR e subsequentemente DONs visam permitir o dimensionamento dos serviços Chainlink dramaticamente nos muitos blockchains que eles suportam. Por exemplo, esperamos que DONs ajudarão a aumentar o número de feeds de dados fornecidos pelos nós usando Chainlink de 100 a 1000 e além. Esse dimensionamento ajudará o Chainlink ecossistema atingir seu objetivo de fornecer dados relevantes para smart contracts de forma abrangente e atender e antecipar as necessidades existentes e futuras.• Segurança aprimorada: ao armazenar relatórios intermediários, DONs reterão registros de comportamentos de nós para monitoramento e medição de alta fidelidade de seu desempenho e precisão, permitindo uma forte base empírica de sistemas de reputação para nós Chainlink. O FSS e o TEF permitirão a incorporação de feeds de preços com dados de transação de maneiras flexíveis que evitam ataques como front-running. (Explícito) staking reforçará a proteção criptoeconômica existente da segurança de feeds de dados. • Agilidade de alimentação: como sistemas agnósticos blockchain (na verdade, mais amplamente, sistemas agnósticos de consumo), DONs podem facilitar o fornecimento de feeds de dados para uma multiplicidade de sistemas confiáveis. Um único DON pode enviar um determinado feed simultaneamente para um conjunto de diferentes blockchains, eliminando a necessidade de redes oracle por cadeia e permitindo a rápida implantação de feeds existentes em novos blockchains e de adicionais feeds em blockchains atualmente atendidos. • Confidencialidade: A capacidade de realizar computação generalizada em um DON permite que cálculos em dados confidenciais ocorram off-chain, evitando on-chain exposição. Além disso, utilizando DECO ou Town Crier, é possível conseguir confidencialidade ainda mais forte, permitindo a geração de relatórios com base em dados que não são exposto até mesmo a nós DON. Consulte a Seção 4.3 e a Seção 4.5 para exemplos. Funções aleatórias verificáveis (VRFs): Vários tipos de DApps exigem uma fonte de aleatoriedade comprovadamente correta para permitir a verificação de sua própria operação justa. Tokens Não Fungíveis (NFTs) são um exemplo. A raridade dos recursos NFT em Aavegotchi [23] e Axie Infinity [35] é determinada por Chainlink VRF, assim como a distribuição de NFTs por meio de sorteios baseados em tickets em Cartões Ether [102]; a grande variedade de DApps de jogos cujos resultados são aleatórios; e instrumentos financeiros não convencionais, por exemplo, jogos de poupança sem perdas, como PoolTogether [89], que alocam fundos para vencedores aleatórios. Outros aplicativos blockchain e não blockchain também exigem segurança fontes de aleatoriedade, incluindo a seleção de comitês do sistema descentralizado e o execução de loterias. Embora os blocos hashes possam servir como uma fonte de aleatoriedade imprevisível, eles são vulneráveis à manipulação por mineradores adversários (e, até certo ponto, por usuários que enviam transações). Chainlink VRF [78] oferece uma alternativa consideravelmente mais segura. Um oracle possui um par de chaves privada/pública associado (sk, pk) cuja chave privada é mantida off-chain e cuja chave pública pk é publicada. Para gerar um valor aleatório, é aplica sk a uma semente imprevisível x fornecida por um contrato confiável (por exemplo, um bloco hash e parâmetros específicos do DApp) usando uma função F, produzindo y = Fsk(x) junto com um prova de correção. (Consulte [180] para o VRF disponível em Chainlink.) O que torna um VRF verificável é o fato de que com o conhecimento de pk é possível verificar a exatidão da prova e, portanto, de y. O valor y é consequentemente imprevisível para um adversário que não pode prever x ou aprender sk e é inviável para o serviço manipular.Chainlink VRF pode ser visto apenas como parte de uma família de aplicações que envolvem a custódia de chaves privadas off-chain. De forma mais geral, DONs podem oferecer segurança, armazenamento descentralizado de chaves individuais para aplicativos e/ou usuários e combinar esta capacidade com computação generalizada. O resultado é uma série de aplicações, de que damos alguns exemplos neste artigo, incluindo gerenciamento de chaves para Prova de Reservas (ver Seção 4.1) e para credenciais descentralizadas de usuários (e outras activos) (ver Secção 4.3). Guardiões: Chainlink Keepers [87] permitem que os desenvolvedores escrevam código para sistemas descentralizados execução de trabalhos fora da cadeia, geralmente para acionar a execução de smart contracts confiáveis. Antes do advento dos Keepers, era comum que os desenvolvedores operassem tais plataformas fora da cadeia. lógica, criando pontos de falha centralizados (bem como esforços de desenvolvimento duplicados consideráveis). Em vez disso, os Keepers fornecem uma estrutura fácil de usar para terceirização descentralizada dessas operações, possibilitando ciclos de desenvolvimento mais curtos e forte garantia de vivacidade e outras propriedades de segurança. Os Keepers podem apoiar qualquer de uma ampla variedade de objetivos desencadeadores, incluindo liquidação de empréstimos dependente do preço ou execução de transações financeiras, início dependente do tempo de lançamentos aéreos ou pagamentos em sistemas com colheita produtiva e assim por diante. Na estrutura DON, os iniciadores podem ser vistos como uma generalização dos Guardiões em vários sentidos. Os iniciadores podem fazer uso de adaptadores e, portanto, podem aproveitar uma biblioteca modularizada de interfaces para sistemas on-chain e off-chain, permitindo rápida desenvolvimento de funcionalidades seguras e sofisticadas. Iniciadores iniciam a computação em executáveis, que oferecem toda a versatilidade dos DONs, permitindo a ampla gama de serviços descentralizados que apresentamos neste artigo para aplicações on-chain e off-chain. 3.6.4 Reputação do nó/histórico de desempenho O ecossistema Chainlink existente documenta nativamente os históricos de desempenho de nós contribuintes na cadeia. Esse recurso deu origem a uma coleção de recursos orientados à reputação que ingerem, filtram e visualizam dados de desempenho de indivíduos. operadores de nós e feeds de dados. Os usuários podem consultar esses recursos para obter informações decisões na seleção de nós e monitorar a operação das redes existentes. Recursos semelhantes ajudarão os usuários a escolher DONs. Por exemplo, hoje em dia, os mercados sem permissão, como market.link, permitem que o nó operadores listem seus serviços oracle e ateste suas identidades fora da cadeia por meio serviços como Keybase [4], que vinculam o perfil de um nó em Chainlink ao seu nomes de domínio existentes e contas de mídia social do proprietário. Além disso, o desempenho ferramentas analíticas, como as disponíveis em market.link e reputação.link, permitem usuários visualizem estatísticas sobre o desempenho histórico de nós individuais, incluindo seus latência média de resposta, o desvio dos valores em seus relatórios dos valores de consenso retransmitidos na cadeia, receitas geradas, empregos realizados e muito mais. Essas ferramentas analíticas também permitir que os usuários rastreiem a adoção de várias redes oracle por outros usuários, uma forma deendosso implícito dos nós que protegem essas redes. O resultado é uma “rede de confiança” na qual, ao usar nós específicos, aplicações descentralizadas de alto valor criam um sinal de sua confiança nos nós que outros usuários podem observar e levar em consideração em seus próprias decisões de seleção de nós. Com DONs (e inicialmente com OCR) ocorre uma mudança no processamento de transações e atividade de contrato mais geralmente fora da cadeia. Um modelo descentralizado para nó de gravação o desempenho permanece possível dentro do próprio DON. Na verdade, o alto desempenho e a capacidade de dados de DONs tornam possível construir registros de maneira ﬁna maneira e também para realizar computação descentralizada nesses registros, produzindo resumos confiáveis que podem ser consumidos por serviços de reputação e verificados em MAINCHAIN. Embora seja possível, em princípio, que um DON deturpe o comportamento dos nós constituintes se uma grande fração dos nós estiver corrompida, notamos que o coletivo o desempenho do próprio DON na entrega de dados on-chain é visível em MAINCHAIN e, portanto, não pode ser deturpada. Além disso, planejamos explorar mecanismos que incentivar relatórios internos precisos sobre o comportamento dos nós em um DON. Por exemplo, reportando o subconjunto de nós de alto desempenho que retornam mais rapidamente dados que contribuem para um relatório transmitido em cadeia, um DON cria um incentivo para os nós contestarem relatórios: incluir nós incorretamente neste subconjunto significa excluir nós incorretamente que deveriam ter sido incluídos e, portanto, penalizá-los inválidamente. Falhas repetidas de relatórios por parte de um DON também criariam um incentivo para que os nós honestos deixassem o DON. Compilação descentralizada de históricos de desempenho precisos e a consequente capacidade dos usuários de identificar nós de alto desempenho e de os operadores de nós construírem reputações são características distintivas importantes do ecossistema Chainlink. Nós mostrar na Seção 9 como podemos raciocinar sobre eles como uma peça-chave de uma abordagem rigorosa e visão expansiva da segurança econômica fornecida por DONs.

Decentralized Services Enabled by Decentralized

Oracle Networks To illustrate the versatility of DONs and how they enable a host of new services, we present ﬁve examples of DON-based applications in this section and describe the hybrid contracts that realize them: (1) Proof of Reserves, a form of cross-chain service; (2) Interfacing with enterprise / legacy systems, that is, creating a middleware-based abstraction layer that facilitates development of blockchain applications with minimal blockchain-speciﬁc code or expertise; (3) Decentralized identity, tools enabling users to obtain and manage their own identity documents and credentials; (4) Priority channels, a service that ensures timely inclusion of critical-infrastructure transactions (e.g., oracle reports) on a blockchain; and (5) Conﬁdentiality-preserving DeFi, that is, ﬁnancial smart contracts that conceal the sensitive data of participating parties. Here, we

use SC to denote the MAINCHAIN part of a hybrid contract and describe the DON component separately or in terms of an executable exec. 4.1 Proof of Reserves For many applications, it is useful to relay state between or among blockchains. A popular application of such services is cryptocurrency wrapping. Wrapped coins such as WBTC [15] are becoming a popular asset in Decentralized Finance (DeFi). They involve depositing the “wrapped” backing asset on its source blockchain MAINCHAIN(1) and creating a corresponding token on a diﬀerent, target blockchain MAINCHAIN(2). For example, WBTC is an ERC20 token on the Ethereum blockchain that corresponds to BTC on the Bitcoin blockchain. Because contracts on MAINCHAIN(2) do not have direct visibility into MAINCHAIN(1), they must rely explicitly or implicitly on an oracle to report on deposits of the wrapped asset in a smart contract, producing what is sometimes called a Proof of Reserves. In WBTC [15], for example, custodian BitGo holds BTC and issues WBTC, with the Chainlink network providing Proofs of Reserve [76]. A DON can itself provide a Proof of Reserves. With a DON, however, it is possible to go further. A DON can manage secrets and, through use of appropriate adapters, can transact on any desired blockchain. Consequently, it is possible for the DON to act as one among a number of custodians—or even as a sole, decentralized custodian—for a wrapped asset. DONs can thereby serve as a platform to enhance the security of existing services that use Proofs of Reserves. For example, suppose that MAINCHAIN(1) is Bitcoin and MAINCHAIN(2) is Ethereum. On MAINCHAIN(2), a contract SC issues tokens representing wrapped BTC. The DON controls a BTC address addr(1) DON. To wrap BTC, then, a user U sends X BTC from addr(1) U to addr(1) DON along with a MAINCHAIN(2)-address addr(2) U . The DON monitors addr(1) DON via an adapter to MAINCHAIN(1). On observing U’s deposit, with suﬃciently high-probability conﬁrmation, it sends a message to SC via an adapter to MAINCHAIN(2). This message instructs SC to mint X tokens for addr(2) U . For U to release X tokens, the reverse happens. On MAINCHAIN(1), however, addr(1) DON sends X BTC to addr(1) U (or to another address, if thus requested by the user). These protocols can be adapted, of course, to work with exchanges, rather than directly with users. 4.2 Interfacing with Enterprise / Legacy Systems DONs can serve as bridges between and among blockchains, as in the example of Proof of Reserves, but another objective is for them to act as bidirectional bridges between blockchains and legacy systems [176] or blockchain-like systems such as central bank digital currencies [30]. Enterprises face a number of challenges in connecting their existing systems and processes to decentralized systems, including:

• Blockchain agility: Blockchain systems change rapidly. An enterprise may confront the rapid new appearance or rise in popularity of blockchains on which counterparties wish to conduct transactions, but for which the enterprise has no support in its existing infrastructure. In general, blockchains’ dynamism makes it diﬃcult for individual enterprises to remain abreast of the full ecosystem. • Blockchain-speciﬁc development resources: For many organizations, hiring or incubating cutting-edge blockchain expertise is diﬃcult, particularly in view of the challenge of agility. • Private-key management: Managing private keys for blockchains or cryptocurrencies requires operational expertise distinct from that of traditional cybersecurity practices and unavailable to many enterprises. • Conﬁdentiality: Enterprises are leery of exposing their sensitive and proprietary data on chain. To address the ﬁrst three of these diﬃculties, developers can simply use a DON as a secure middleware layer to enable enterprise systems to read from or write to blockchains. The DON can abstract away detailed technical considerations such as gas dynamics, chain reorganization, and so forth, for both developers and users. By presenting a streamlined blockchain interface to enterprise systems, a DON can thus considerably simplify the development of blockchain-aware enterprise applications, removing the burden from enterprises of acquiring or incubating blockchain-speciﬁc development resources. Such use of DONs is especially attractive in that it enables enterprise developers to create smart-contract applications that are largely blockchain agnostic. As a result, the larger the set of blockchains for which a DON is instrumented to act as middleware, the larger the set of blockchains to which enterprise users can gain easy access. Developers can port applications from existing blockchains to new ones with minimal modiﬁcation to their internally developed applications. To address the additional problem of conﬁdentiality, developers can appeal to the tools we introduce in this paper and expect to deploy in support of DON applications. These include DECO and Town Crier Section 3.6.2 as well as conﬁdentiality-preserving API modiﬁcations discussed in Section 7.1.2 and a number of application-speciﬁc approaches covered in the remainder of this section. These DON systems can provide high-integrity, on-chain attestations about enterprise system state without revealing sensitive enterprise source data on chain. 4.3 Decentralized Identity Decentralized identity is a general term for the notion that users should be able to obtain and manage their own credentials, rather than relying on third parties to do so. Decentralized credentials are attestations to attributes or assertions of the holder,

which are often called claims. Credentials are digitally signed by entities, often called issuers, that can authoritatively associate claims with users. In most proposed schemes, claims are associated with a Decentralized Identiﬁer (DID), a universal identiﬁer for a given user. Credentials are bound to a public key whose private key the user holds. The user can thus prove possession of a claim using her private key. Visionary as decentralized identity is, existing and proposed schemes, e.g., [14, 92, 129, 216], have three severe limitations: • Lack of legacy compatibility: Existing decentralized identity systems rely on a community of authorities, called issuers, to produce DID credentials. Because existing web services do not generally digitally sign data, issuers must be launched as special-purpose systems. Because there is no incentive to do this without a decentralized-identity ecosystem, a chicken-and-the-egg problem results. In other words, it’s unclear how to bootstrap an issuer ecosystem. • Unworkable key management: Decentralized identity systems require users to manage private keys, something that experience with cryptocurrency has shown to be an unworkable onus. It is estimated that some 4,000,000 Bitcoin have been lost forever because of key management failures [194], and many users store their crypto assets with exchanges [193], thereby undermining decentralization. • Lack of privacy-preserving Sybil resistance: A basic security requirement of applications such as voting, fair allocation of tokens during token sales, etc. is that users be unable to assert multiple identities. Existing decentralized identity proposals require users to reveal their real-world identities in order to achieve such Sybil resistance, thereby undermining important privacy assurances. It is possible to address these problems using a combination of a committee of nodes performing distributed computation within a DON and the use of tools such as DECO or Town Crier, as shown in a system called CanDID [160]. DECO or Town Crier can by design turn existing web services without modiﬁcation into conﬁdentiality-preserving credential issuers. They enable a DON to export relevant data for this purpose into a credential while concealing sensitive data that should not appear in the credential. In addition, to facilitate key recovery for users, thus addressing the key-management problem, a DON can allow users to store private keys in secret-shared form. Users can recover their keys by proving to the nodes in the DON—similarly, using Town Crier or DECO—an ability to log into accounts with a set of predetermined web providers (e.g., Twitter, Google, Facebook). The beneﬁt of using Town Crier or DECO, as opposed to OAUTH, is user privacy. Those two tools enable a user to avoid revealing to the DON a web provider identiﬁer—from which real-world identities can often be derived. Finally, to provide Sybil resistance, as shown in [160], it is possible for a DON to perform a privacy-preserving transformation of unique real-world identiﬁers for users (e.g., Social Security Numbers (SSNs)) into on-chain identiﬁers upon user registration.

The system can thereby detect duplicate registrations without sensitive data such as SSNs being revealed to individual DON nodes.7 A DON can provide any of these services on behalf of external decentralized identity systems on permissionless or permissioned blockchains, e.g., instances of Hyperledger Indy [129]. Example application: KYC: Decentralized identity holds promise as a means to streamline requirements for ﬁnancial applications on blockchains while improving user privacy. Two challenges it can help address are accreditation and compliance obligations under anti-money-laundering / know-your-customer (AML / KYC) regulations. AML regulations in many countries require ﬁnancial institutions (and other businesses) to establish and verify the identities of individuals and businesses with which they perform transactions. KYC forms one component of a ﬁnancial institution’s broader AML policy, which also typically involves monitoring user behaviors and watching fund ﬂows, among other things. KYC typically involves user presentation of identity credentials in some form (e.g., entry into an online web form, holding up an identity document in front of a user’s face in a video session, etc.). Secure creation of and presentation of decentralized credentials could in principle be a beneﬁcial alternative in several respects, namely by: (1) Making the KYC process more eﬃcient for users and ﬁnancial institutions, because once a credential is obtained, it could be presented seamlessly to any ﬁnancial institution; (2) Reducing fraud by reducing opportunities for identity theft through compromise of personally identiﬁable information (PII) and spooﬁng during video veriﬁcation; and (3) Reducing the risk of PII compromise in ﬁnancial institutions, as users retain control of their own data. Given the multi-billion-dollar penalties paid by ﬁnancial institutions for AML compliance failures, and the many ﬁnancial institutions spending millions of dollars annually on KYC, improvements could yield considerable savings for ﬁnancial institutions and, by extension, for consumers [196]. While the traditional ﬁnancial sector is slow to adopt new compliance tools, DeFi systems are increasingly embracing it [43]. Example application: Under-collateralized loans: Most DeFi applications that support lending today originate only fully collateralized loans. These are loans made to borrowers who deposit cryptocurrency assets of value exceeding that of the loans. Interest has arisen recently in what the DeFi community generally refers to as undercollateralized loans. These, by contrast, are loans for which the corresponding collateral has value that is less than that of the principal of the loan. Under-collateralized loans resemble loans often made by traditional ﬁnancial institutions. Rather than relying on deposited collateral as a guarantee of loan repayment, they instead base lending decisions on the credit histories of borrowers. 7This transformation relies on a distributed pseudorandom function (PRF).

Under-collateralized loans constitute a nascent but growing part of the DeFi lending market. They rely upon mechanisms like those employed by traditional ﬁnancial institutions, such as legal contracts [91]. An essential requirement for their growth will be the ability to furnish data on user creditworthiness—a key factor in conventional lending decisions—to DeFi systems in a way that provides strong integrity, i.e., assurance of correct data. A DON-enabled decentralized identity system would enable would-be borrowers to generate high-assurance credentials attesting to their creditworthiness while preserving the conﬁdentiality of sensitive information. Speciﬁcally, borrowers can generate these credentials based on records from authoritative online sources while exposing only the data attested to by the DON, without exposing other, potentially sensitive data. For example, a borrower can generate a credential indicating that her credit score with a set of credit bureaus exceeds a particular threshold (e.g., 750), without revealing her precise score or any other data in her records. Additionally, if desired, such credentials can be generated anonymously, i.e., the user’s name can be treated as sensitive data and itself not exposed to oracle nodes or in her decentralized credential. The credential itself can be used on chain or oﬀchain, depending on the application. In summary, a borrower can provide essential information to lenders on their credit histories with strong integrity and without risk of exposure of unnecessary, sensitive data. A borrower can also provide a variety of other conﬁdentiality-preserving credentials helpful in making lending decisions. For example, credentials can attest to a borrower’s possession of (oﬀ-chain) assets, as we show in our next example. Example application: Accreditation: Many jurisdictions limit the class of investor to which unregistered securities may be sold. For example, in the U.S., SEC Regulation D stipulates that to be accredited for such investment opportunities, an individual must possess a net worth of $1 million, meet certain minimum income requirements, or have certain professional qualiﬁcations [209, 210]. Current accreditation processes are cumbersome and ineﬃcient, often requiring a letter of attestation from an accountant, or similar evidence. A decentralized identity system would enable users to generate credentials from existing online ﬁnancial services accounts that prove compliance with accreditation regulations, facilitating a more eﬃcient and privacy-preserving KYC process. The privacy-preserving properties of DECO and Town Crier, moreover, would allow these credentials to be generated with a strong assurance of integrity without directly revealing details of a user’s ﬁnancial status. For example, a user could generate a credential proving that she has a net worth of at least $1 million without revealing any additional information about her ﬁnancial status. 4.4 Priority Channels Priority channels are a useful new service that is easy to build using a DON. Their

Priority channel diagram showing a miner guarantee for transaction ordering to protect against MEV

goal is to deliver select, high-priority transactions in a timely way on MAINCHAIN during periods of network congestion. Priority channels may be viewed as a form of futures contract on block space and thus as a cryptocommodity, a term coined as part of Project Chicago [61, 136]. Priority channels are intended speciﬁcally for miners to enable infrastructure services, such as oracles, governance functions for contracts, etc.—not for ordinary userlevel activities such as ﬁnancial transactions. In fact, as designed here, a priority channel implemented by less than 100% of the mining power in the network can only provide loose bounds on delivery times, preventing its use for highly speed-dependent goals such as front-running. Figure 10: A priority channel is a guarantee by a miner M—or, more generally, a set of miners M—to a user U that her transaction $\tau$ will be mined within D blocks of inclusion in the mempool. A contract SC can use DON monitoring to enforce the service terms of the channel. A priority channel takes the form of an agreement between a miner or set of miners (or mining pools) M that provides the channel and a user U that pays a fee for access. M agrees that when U submits a transaction $\tau$ to the mempool (with any gas price,

but a pre-agreed-upon gas limit), M will place it on chain within the next D blocks.8 The idea is depicted schematically in Fig. 10. Priority-channel contract description: A priority channel may be realized as a hybrid smart contract roughly as follows. We let SC denote the logic on MAINCHAIN and that on the DON by exec. SC accepts a deposit / stake $d from M and an advance payment $p from U. A DON executable exec monitors the mempool, triggering on placement of a transaction by U. It sends a success message to SC if U submits a transaction that M mines in a timely way and a failure message in case of a service failure. SC sends payment $p to M given a success message and sends all remaining funds, including $d, to U if it receives a failure message. Upon successful termination, it releases deposit $d to M. The miner M can of course provide priority channels simultaneously to multiple users and can open a priority channel with U for a pre-agreed-upon number of messages. 4.5 Conﬁdentiality-Preserving DeFi / Mixicles Today, DeFi applications [1] provide little to no conﬁdentiality for users: All transactions are visible on chain. Various zero-knowledge-based approaches, e.g., [149, 217], can provide transaction privacy, and the TEF is general enough to support them. But these approaches are not comprehensive, and do not, for example, typically conceal the asset on which a transaction is based. The broad set of computational tools we ultimately intend to support in DONs will enable privacy in a number of diﬀerent ways that can plug such gaps, helping complement the privacy assurances of other systems. For example, Mixicles, a conﬁdentialitypreserving DeFi instrument proposed by Chainlink Labs researchers [135], can conceal the asset type backing a ﬁnancial instrument, and ﬁt very naturally into the DON framework. Mixicles are most easily explained in terms of their use to realize a simple binary option. A binary option is a ﬁnancial instrument in which two users, which we’ll refer to here for consistency with [135] as players, bet on an event with two possible outcomes, e.g., whether or not an asset exceeds a target price at a predesignated time. The following example illustrates the idea. Example 2. Alice and Bob are parties to a binary option based on the value of an asset called Carol’s Bubble Token (CBT). Alice bets that CBT will have a market price of at least 250 USD at time T = noon on 21 June 2025; Bob bets the reverse. Each player deposits 100 ETH by a prespeciﬁed deadline. The player with the winning position receives 200 ETH (i.e., gains 100 ETH). 8D must of course be large enough to ensure that M can comply with high probability. For instance, if M controls 20% of the mining power in the network, it might choose D = 100, ensuring a failure probability of ≈2 × 10−10, i.e., less than one in a billion.

Diagram of basic Mixicle showing on-chain secrecy with private oracle reporting

Given an existing Chainlink oracle network O, it is easy to implement a smart contract SC that realizes the agreement in Example 2. The two players each deposit 100 ETH in SC. Sometime after T, a query q is sent to O requesting the price r of CBT at time T. O sends a report r of this price to SC. SC then sends money to Alice if $r \geq 250$ and Bob if not. This approach, however, reveals $r$ on chain—making it easy for an observer to deduce the asset underlying the binary option. In the terminology of Mixicles, it is helpful to think conceptually of the outcome of SC in terms of a Switch that transmits a binary value computed as a predicate switch($r$). In our example, switch($r$) = 0 if $r \geq 250$; given this outcome, Alice wins. Otherwise switch(r) = 1 and Bob wins. A DON can realize a basic Mixicle as a hybrid contract by running an executable exec that computes switch(r) and reports it on chain to SC. We show this construction in Fig. 11. Figure 11: Diagram of basic Mixicle in Example 2. To provide on-chain secrecy for report r, and thus the asset underlying the binary option, the oracle sends to the contract SC via Switch only the binary value switch(r). We specify an adapter ConfSwitch in Appendix C.3 that makes it easy to achieve this goal in a DON. The basic idea behind ConfSwitch is quite simple. Instead of reporting the value r, ConfSwitch reports only the binary switch value switch(r). SC can be designed to make a correct payment based on switch(r) alone, and switch(r) by itself reveals no information about the underlying asset—CBT in our example. Additionally, by placing a ciphertext on (q, r) on the ledger encrypted under pkaud, the public key of an auditor, the adapter ConfSwitch creates a conﬁdentiality-preserving audit trail. The basic Mixicle we’ve chosen for simplicity to describe here conceals only the asset and bet behind the binary option in our example. A full-blown Mixicle [135] can provide two forms of conﬁdentiality. It conceals from observers: (1) What event the players bet on (i.e., q and r) but also (2) Which player won the bet. Since Mixicles are executed on MAINCHAIN, either one player would need to relay switch(r) from the DON to MAINCHAIN, or an executable exec could be created that

is triggered on output by ConfSwitch and calls another adapter to send switch(r) to MAINCHAIN. A third, subtle type of conﬁdentiality is also worth considering. In a basic implementation of ConfSwitch, O is running the adapter on the DON and thus learns the asset—CBT in our example—and thus the nature of the binary option. As discussed in Appendix C.3, however, it is additionally possible to use DECO or Town Crier to conceal even this information from O. In this case, the O learns no more information than a public observer of SC. For further details on Mixicles, we refer readers to [135].

Serviços descentralizados habilitados por descentralizados

Redes Oracle Para ilustrar a versatilidade dos DONs e como eles permitem uma série de novos serviços, apresentamos cinco exemplos de aplicativos baseados em DON nesta seção e descrevemos o contratos híbridos que os realizam: (1) Prova de Reservas, uma forma de serviço cross-chain; (2) Interface com sistemas corporativos/legados, ou seja, criação de um ambiente baseado em middleware camada de abstração que facilita o desenvolvimento de aplicativos blockchain com o mínimo blockchain-código ou conhecimento específico; (3) Identidade descentralizada, ferramentas que permitem aos utilizadores obter e gerenciar seus próprios documentos e credenciais de identidade; (4) Canais prioritários, um serviço que garante a inclusão oportuna de transações de infraestrutura crítica (por exemplo, oracle relatórios) em blockchain; e (5) DeFi de preservação de confidencialidade, ou seja, financeiro smart contracts que ocultam os dados confidenciais das partes participantes. Aqui, nós

use SC para denotar a parte MAINCHAIN de um contrato híbrido e descreva o DON componente separadamente ou em termos de um executável exec. 4.1 Comprovante de Reservas Para muitas aplicações, é útil retransmitir o estado entre blockchains. Um Uma aplicação popular de tais serviços é o empacotamento de criptomoedas. Moedas embrulhadas como como WBTC [15] estão se tornando um ativo popular nas finanças descentralizadas (DeFi). Eles envolvem o depósito do ativo de garantia “embrulhado” em sua fonte blockchain MAINCHAIN(1) e criando um token correspondente em um destino blockchain MAINCHAIN(2) diferente. Por exemplo, WBTC é um ERC20 token no Ethereum blockchain que corresponde para BTC no Bitcoin blockchain. Como os contratos em MAINCHAIN(2) não têm visibilidade direta em MAINCHAIN(1), eles devem confiar explícita ou implicitamente em um oracle para relatar os depósitos do pacote embalado ativo em um smart contract, produzindo o que às vezes é chamado de Prova de Reservas. Em WBTC [15], por exemplo, o custodiante BitGo detém BTC e emite WBTC, com o Chainlink rede que fornece Comprovantes de Reserva [76]. Um DON pode fornecer uma Prova de Reservas. Com um DON, entretanto, é possível para ir mais longe. Um DON pode gerenciar segredos e, através do uso de adaptadores apropriados, pode fazer transações em qualquer blockchain desejado. Consequentemente, é possível que o DON atue como um entre vários custodiantes - ou mesmo como um único custodiante descentralizado - para um ativo embrulhado. DONs podem servir como uma plataforma para aumentar a segurança de serviços existentes que utilizam Provas de Reservas. Por exemplo, suponha que MAINCHAIN(1) seja Bitcoin e MAINCHAIN(2) seja Ethereum. Em MAINCHAIN(2), um contrato SC emite tokens representando BTC embalado. O DON controla um endereço BTC addr(1) DON. Para encapsular o BTC, então, um usuário U envia X BTC de endereço(1) Você para endereço(1) DON junto com um endereço MAINCHAIN(2) addr(2) Você. O DON monitora endereço(1) DON através de um adaptador para MAINCHAIN(1). Ao observar o depósito de U, com confirmação de probabilidade suficientemente alta, ele envia uma mensagem para SC através de um adaptador para CORRENTE PRINCIPAL(2). Esta mensagem instrui SC a cunhar X tokens para addr(2) Você. Para U liberar X tokens, acontece o inverso. Em MAINCHAIN(1), entretanto, endereço(1) DON envia X BTC para addr(1) U (ou para outro endereço, se assim for solicitado pelo utilizador). Esses protocolos podem ser adaptados, é claro, para funcionar com exchanges, em vez de diretamente com os usuários. 4.2 Interface com sistemas corporativos/legados DONs podem servir como pontes entre blockchains, como no exemplo de Prova de Reservas, mas outro objetivo é que atuem como pontes bidirecionais entre blockchains e sistemas legados [176] ou sistemas semelhantes a blockchain, como banco central moedas digitais [30]. As empresas enfrentam uma série de desafios para conectar seus sistemas existentes e processos para sistemas descentralizados, incluindo:• Agilidade Blockchain: Os sistemas Blockchain mudam rapidamente. Uma empresa pode enfrentar o rápido aparecimento ou aumento de popularidade de blockchains nos quais contrapartes desejam realizar transações, mas para as quais a empresa não tem suporte em sua infra-estrutura existente. Em geral, o dinamismo de blockchains faz com que é difícil para as empresas individuais manterem-se a par de todo o ecossistema. • Recursos de desenvolvimento específicos para Blockchain: Para muitas organizações, contratar ou incubar conhecimentos blockchain de ponta é difícil, especialmente em vista da desafio da agilidade. • Gerenciamento de chaves privadas: o gerenciamento de chaves privadas para blockchains ou criptomoedas requer conhecimento operacional distinto daquele da segurança cibernética tradicional práticas e indisponíveis para muitas empresas. • Confidencialidade: As empresas desconfiam de expor seus dados confidenciais e proprietários dados na cadeia. Para resolver as três primeiras dessas dificuldades, os desenvolvedores podem simplesmente usar um DON como uma camada de middleware segura para permitir que sistemas corporativos leiam ou gravem em blockchains. O DON pode abstrair considerações técnicas detalhadas, como dinâmica de gases, reorganização da cadeia e assim por diante, tanto para desenvolvedores quanto para usuários. Por apresentando uma interface blockchain simplificada para sistemas corporativos, um DON pode, portanto, simplificar consideravelmente o desenvolvimento de aplicativos empresariais com reconhecimento de blockchain, eliminando o fardo das empresas de adquirir ou incubar recursos de desenvolvimento específicos de blockchain. Esse uso de DONs é especialmente atraente porque permite que os desenvolvedores corporativos criar aplicativos de contratos inteligentes que são em grande parte blockchain agnósticos. Como resultado, o maior o conjunto de blockchains para os quais um DON é instrumentado para atuar como middleware, o maior o conjunto de blockchains aos quais os usuários corporativos podem obter acesso fácil. Desenvolvedores pode portar aplicativos de blockchains existentes para novos com modificação mínima às suas aplicações desenvolvidas internamente. Para resolver o problema adicional da confidencialidade, os desenvolvedores podem recorrer ao ferramentas que apresentamos neste documento e esperamos implantar para suporte a aplicativos DON. Estes incluem DECO e Town Crier Seção 3.6.2, bem como sistemas de preservação de confidencialidade Modificações de API discutidas na Seção 7.1.2 e uma série de abordagens específicas de aplicação abordadas no restante desta seção. Esses sistemas DON podem fornecer atestados on-chain de alta integridade sobre o estado do sistema empresarial sem revelar dados confidenciais de origem empresarial na cadeia. 4.3 Identidade Descentralizada Identidade descentralizada é um termo geral para a noção de que os usuários devem ser capazes de obter e gerenciar suas próprias credenciais, em vez de depender de terceiros para fazer então. Credenciais descentralizadas são atestados de atributos ou afirmações do titular,que muitas vezes são chamados de reivindicações. As credenciais são assinadas digitalmente por entidades, muitas vezes chamadas emissores, que podem associar declarações com autoridade aos usuários. Na maioria dos esquemas propostos, reivindicações estão associadas a um Identificador Descentralizado (DID), um identificador universal para um determinado usuário. As credenciais estão vinculadas a uma chave pública cuja chave privada o usuário possui. O usuário pode assim provar a posse de uma reivindicação usando sua chave privada. Por mais visionários que sejam a identidade descentralizada, os esquemas existentes e propostos, por exemplo, [14, 92, 129, 216], têm três limitações severas: • Falta de compatibilidade legada: Os sistemas de identidade descentralizados existentes dependem de um comunidade de autoridades, chamadas emissores, para produzir credenciais DID. Porque os serviços web existentes geralmente não assinam dados digitalmente, os emissores devem ser lançados como sistemas para fins especiais. Porque não há incentivo para fazer isso sem uma ecossistema de identidade descentralizada, o resultado é um problema do ovo e da galinha. Em outro palavras, não está claro como inicializar um ecossistema de emissores. • Gerenciamento de chaves impraticável: Os sistemas de identidade descentralizados exigem que os usuários gerenciar chaves privadas, algo que a experiência com criptomoeda mostrou ser um ônus inviável. Estima-se que cerca de 4.000.000 Bitcoin foram perdidos para sempre devido a falhas de gerenciamento de chaves [194], e muitos usuários armazenam seus ativos criptográficos com exchanges [193], minando assim a descentralização. • Falta de resistência Sybil que preserve a privacidade: Um requisito básico de segurança de aplicações como votação, alocação justa de tokens durante vendas de token, etc. os usuários não poderão afirmar múltiplas identidades. As propostas de identidade descentralizadas existentes exigem que os utilizadores revelem as suas identidades do mundo real, a fim de alcançar tal resistência Sybil, minando assim importantes garantias de privacidade. É possível resolver estes problemas usando uma combinação de um comitê de nós realizando computação distribuída dentro de um DON e o uso de ferramentas como DECO ou Town Crier, conforme mostrado em um sistema chamado CanDID [160]. DECO ou Town Crier podem, por design, transformar serviços web existentes sem modificação em emissores de credenciais que preservam a confidencialidade. Eles permitem que um DON exporte dados relevantes dados para esse fim em uma credencial, ocultando dados confidenciais que não deveriam aparecem na credencial. Além disso, para facilitar a recuperação de chaves para os usuários, abordando assim o problema de gerenciamento de chaves problema, um DON pode permitir que os usuários armazenem chaves privadas em formato secreto compartilhado. Os usuários podem recupere suas chaves provando aos nós no DON - da mesma forma, usando Town Crier ou DECO – uma capacidade de fazer login em contas com um conjunto de provedores da web pré-determinados (por exemplo, Twitter, Google, Facebook). O benefício de usar Town Crier ou DECO, em oposição a OAUTH, é a privacidade do usuário. Essas duas ferramentas permitem que o usuário evite revelar ao DON um identificador de provedor da web – do qual muitas vezes podem ser derivadas identidades do mundo real. Finalmente, para fornecer resistência Sybil, conforme mostrado em [160], é possível que um DON realizar uma transformação que preserva a privacidade de identificadores exclusivos do mundo real para usuários (por exemplo, números de segurança social (SSNs)) em identificadores na rede após o registro do usuário.O sistema pode, assim, detectar registros duplicados sem dados confidenciais, como SSNs sendo revelados para nós DON individuais.7 Um DON pode fornecer qualquer um desses serviços em nome de identidade descentralizada externa sistemas em blockchains sem ou com permissão, por exemplo, instâncias do Hyperledger Indy [129]. Exemplo de aplicação: KYC: A identidade descentralizada é promissora como meio de simplificar os requisitos para aplicações financeiras em blockchains enquanto melhora o usuário privacidade. Dois desafios que pode ajudar a resolver são as obrigações de acreditação e conformidade ao abrigo dos regulamentos anti-lavagem de dinheiro/conheça o seu cliente (AML/KYC). As regulamentações ABC em muitos países exigem que as instituições financeiras (e outras empresas) estabeleçam e verifiquem as identidades de indivíduos e empresas com as quais eles realizam transações. KYC constitui um componente do sistema de uma instituição financeira uma política ABC mais ampla, que normalmente também envolve a monitorização do comportamento dos utilizadores e a observação dos fluxos de fundos, entre outras coisas. O KYC normalmente envolve a apresentação de credenciais de identidade pelo usuário de alguma forma (por exemplo, entrada em um formulário on-line da web, segurando um documento de identidade na frente do rosto do usuário em uma sessão de vídeo, etc.). Criação segura e apresentação de credenciais descentralizadas poderia, em princípio, ser uma alternativa benéfica em vários aspectos, nomeadamente: (1) Fazendo o processo KYC mais eficiente para usuários e instituições financeiras, porque uma vez a credencial for obtida, ela poderá ser apresentada perfeitamente a qualquer instituição financeira; (2) Reduzir a fraude, reduzindo as oportunidades de roubo de identidade através de comprometimento de informações de identificação pessoal (PII) e falsificação durante a verificação de vídeo; e (3) Reduzir o risco de comprometimento de PII em instituições financeiras, à medida que os usuários mantêm o controle dos seus próprios dados. Dadas as multas multibilionárias pagas pelas instituições financeiras por falhas de conformidade com a AML, e as muitas instituições financeiras que gastam milhões de dólares anualmente em KYC, as melhorias poderiam gerar poupanças consideráveis para as instituições financeiras. e, por extensão, para consumidores [196]. Embora o setor financeiro tradicional seja lento para adotar novas ferramentas de conformidade, DeFi os sistemas estão cada vez mais adotando-as [43]. Exemplo de aplicação: Empréstimos com garantia insuficiente: A maioria dos aplicativos DeFi que os empréstimos de apoio hoje originam apenas empréstimos totalmente garantidos. Estes são empréstimos feitos para mutuários que depositam ativos de criptomoeda de valor superior ao dos empréstimos. Recentemente surgiu interesse naquilo que a comunidade DeFi geralmente chama de empréstimos com garantia insuficiente. Estes, pelo contrário, são empréstimos para os quais a garantia correspondente tem valor inferior ao do principal do empréstimo. Empréstimos com garantia insuficiente assemelham-se a empréstimos frequentemente concedidos por instituições financeiras tradicionais. Em vez de confiar na garantia depositada como garantia do reembolso do empréstimo, eles baseiam o empréstimo decisões sobre os históricos de crédito dos mutuários. 7Essa transformação depende de uma função pseudoaleatória distribuída (PRF).Os empréstimos com garantia insuficiente constituem uma parte nascente, mas crescente, do mercado de empréstimos DeFi. Eles dependem de mecanismos como aqueles empregados pelas finanças tradicionais. instituições, como contratos legais [91]. Um requisito essencial para o seu crescimento será a capacidade de fornecer dados sobre a qualidade de crédito do usuário - um fator-chave nas decisões de empréstimo convencionais - para sistemas DeFi de uma forma que forneça forte integridade, ou seja, garantia de dados corretos. Um sistema de identidade descentralizado habilitado para DON permitiria que os possíveis mutuários gerar credenciais de alta garantia que atestem sua qualidade de crédito, preservando ao mesmo tempo a confidencialidade de informações sensíveis. Especificamente, os mutuários podem gerar esses credenciais baseadas em registros de fontes on-line confiáveis, expondo apenas o dados atestados por DON, sem expor outros dados potencialmente sensíveis. Para Por exemplo, um mutuário pode gerar uma credencial indicando que sua pontuação de crédito com um conjunto de agências de crédito excede um limite específico (por exemplo, 750), sem revelar seu pontuação precisa ou quaisquer outros dados em seus registros. Além disso, se desejado, tais credenciais podem ser gerados anonimamente, ou seja, o nome do usuário pode ser tratado como dado sensível e ela própria não está exposta aos nós oracle ou em sua credencial descentralizada. A credencial em si pode ser usado em cadeia ou fora da cadeia, dependendo da aplicação. Em resumo, um mutuário pode fornecer informações essenciais aos credores sobre o seu crédito histórias com forte integridade e sem risco de exposição de informações desnecessárias e sensíveis dados. Um mutuário também pode fornecer uma variedade de outras credenciais que preservam a confidencialidade útil na tomada de decisões de empréstimo. Por exemplo, as credenciais podem atestar a posse de ativos (fora da cadeia), como mostramos em nosso próximo exemplo. Exemplo de aplicação: Credenciamento: Muitas jurisdições limitam a classe de investidores aos quais os títulos não registrados podem ser vendidos. Por exemplo, nos EUA, SEC O Regulamento D estipula que para ser credenciado para tais oportunidades de investimento, um o indivíduo deve possuir um patrimônio líquido de US$ 1 milhão, atender a certos requisitos de renda mínima ou ter certas qualificações profissionais [209, 210]. Credenciamento atual processos são complicados e ineficientes, muitas vezes exigindo uma carta de atestado do um contador ou evidência semelhante. Um sistema de identidade descentralizado permitiria aos usuários gerar credenciais de contas de serviços financeiros on-line existentes que comprovem conformidade com o credenciamento regulamentações, facilitando um processo KYC mais eficiente e que preserva a privacidade. O Além disso, as propriedades de preservação da privacidade da DECO e da Town Crier permitiriam que estes credenciais a serem geradas com uma forte garantia de integridade, sem revelar diretamente detalhes da situação financeira de um usuário. Por exemplo, um usuário pode gerar uma credencial provar que ela tem um patrimônio líquido de pelo menos US$ 1 milhão sem revelar qualquer valor adicional informações sobre sua situação financeira. 4.4 Canais Prioritários Os canais prioritários são um novo serviço útil e fácil de construir usando um DON. Seu

Diagram of basic Mixicle showing on-chain secrecy with private oracle reporting

Priority channel diagram showing a miner guarantee for transaction ordering to protect against MEV

o objetivo é entregar transações selecionadas e de alta prioridade em tempo hábil no MAINCHAIN durante períodos de congestionamento da rede. Os canais prioritários podem ser vistos como uma forma de contrato futuro no espaço do bloco e, portanto, como uma criptomoeda, um termo cunhado como parte do Projeto Chicago [61, 136]. Os canais prioritários destinam-se especificamente aos mineradores para permitir serviços de infraestrutura, como oracles, funções de governança para contratos, etc. – e não para atividades comuns no nível do usuário, como transações financeiras. Na verdade, tal como concebido aqui, uma prioridade canal implementado por menos de 100% do poder de mineração na rede só pode fornecem limites frouxos nos prazos de entrega, evitando seu uso para tarefas altamente dependentes da velocidade. objetivos como a liderança. Figura 10: Um canal prioritário é uma garantia de um minerador M – ou, mais geralmente, um conjunto de mineradores M - para um usuário U que sua transação τ será extraída em D blocos de inclusão no mempool. Um SC de contrato pode usar monitoramento DON para fazer cumprir o termos de serviço do canal. Um canal prioritário assume a forma de um acordo entre um minerador ou um conjunto de mineradores (ou pools de mineração) M que fornece o canal e um usuário U que paga uma taxa pelo acesso. M concorda que quando U envia uma transação τ ao mempool (com qualquer preço de gás,mas um limite de gás pré-acordado), M irá colocá-lo na cadeia nos próximos blocos D.8 A ideia é representada esquematicamente na Fig. Descrição do contrato de canal prioritário: Um canal prioritário pode ser realizado como um híbrido smart contract aproximadamente como segue. Deixamos SC denotar a lógica em MAINCHAIN e isso em DON por exec. SC aceita um depósito/aposta $d from M and an advance payment $p dos EUA DON executável exec monitora o mempool, acionando na colocação de uma transação por U. Ele envia uma mensagem de sucesso para SC se U enviar uma transação que M minera em em tempo hábil e uma mensagem de falha em caso de falha no serviço. SC envia o pagamento $p para M com uma mensagem de sucesso e envia todos os fundos restantes, incluindo $d, para U se receber uma mensagem de falha. Após a rescisão bem-sucedida, libera o depósito $d para M. O minerador M pode, é claro, fornecer canais prioritários simultaneamente para vários usuários e pode abrir um canal prioritário com U para um número pré-acordado de mensagens. 4,5 Preservação de confidencialidade DeFi / Mixicles Hoje, DeFi aplicativos [1] fornecem pouca ou nenhuma confidencialidade aos usuários: todas as transações são visíveis na cadeia. Várias abordagens baseadas em conhecimento zero, por exemplo, [149, 217], podem fornecer privacidade às transações e o TEF é geral o suficiente para apoiá-los. Mas essas abordagens não são abrangentes e, por exemplo, normalmente não escondem o ativo no qual uma transação se baseia. O amplo conjunto de ferramentas computacionais que pretendemos apoiar em DONs irá permitir a privacidade de diversas maneiras diferentes que podem preencher essas lacunas, ajudando a complementar as garantias de privacidade de outros sistemas. Por exemplo, Mixicles, um instrumento de preservação de confidencialidade DeFi proposto por Chainlink pesquisadores do Labs [135], pode ocultar o tipo de ativo que respalda um instrumento financeiro e se enquadra muito naturalmente no DON quadro. Mixicles são mais facilmente explicados em termos de seu uso para realizar um sistema binário simples. opção. Uma opção binária é um instrumento financeiro no qual dois usuários, que iremos consulte aqui para consistência com [135] como jogadores, aposte em um evento com dois possíveis resultados, por exemplo, se um ativo excede ou não um preço-alvo em um momento pré-designado. O exemplo a seguir ilustra a ideia. Exemplo 2. Alice e Bob são partes de uma opção binária baseada no valor de um ativo chamado Carol’s Bubble Token (CBT). Alice aposta que o CBT terá um preço de mercado de pelo menos pelo menos 250 USD no horário T = meio-dia de 21 de junho de 2025; Bob aposta o contrário. Cada jogador deposita 100 ETH em um prazo pré-especificado. O jogador com a posição vencedora recebe 200 ETH (ou seja, ganha 100 ETH). É claro que 8D deve ser grande o suficiente para garantir que M possa cumprir com alta probabilidade. Para Por exemplo, se M controlar 20% do poder de mineração na rede, ele poderá escolher D = 100, garantindo uma probabilidade de falha de ≈2 × 10−10, ou seja, menos de uma em um bilhão.Dada uma rede Chainlink oracle O existente, é fácil implementar um sistema inteligente contrato SC que realiza o acordo no Exemplo 2. Cada um dos dois jogadores deposita 100 ETH em SC. Algum tempo depois de T, uma consulta q é enviada a O solicitando o preço r de CBT no momento T. O envia um relatório r desse preço para SC. SC então envia dinheiro para Alice se r ≥250 e Bob se não. Esta abordagem, no entanto, revela r em cadeia – tornando mais fácil para um observador deduzir o ativo subjacente à opção binária. Na terminologia de Mixicles, é útil pensar conceitualmente no resultado de SC em termos de um Switch que transmite um valor binário calculado como um predicado interruptor (r). Em nosso exemplo, switch(r) = 0 se r ≥250; dado este resultado, Alice vence. Caso contrário switch(r) = 1 e Bob vence. Um DON pode realizar um Mixicle básico como um contrato híbrido executando um executável exec que calcula switch(r) e reporta-o em cadeia para SC. Mostramos esta construção na Figura 11. Figura 11: Diagrama do Mixicle básico no Exemplo 2. Para fornecer sigilo na cadeia para relatório r e, portanto, o ativo subjacente à opção binária, o oracle envia para o contrate SC via Switch apenas o valor binário switch(r). Especificamos um adaptador ConfSwitch no Apêndice C.3 que torna mais fácil conseguir isso meta em um DON. A ideia básica por trás do ConfSwitch é bastante simples. Em vez de relatar o valor r, ConfSwitch relata apenas o valor da chave binária switch(r). SC pode ser projetado para fazer um pagamento correto com base apenas no switch(r) e no switch(r) por si só não revela nenhuma informação sobre o ativo subjacente – CBT em nosso exemplo. Além disso, colocando um texto cifrado em (q, r) no livro-razão criptografado em pkaud, a chave pública de um auditor, o adaptador ConfSwitch cria uma trilha de auditoria que preserva a confidencialidade. O Mixicle básico que escolhemos para simplificar a descrição aqui esconde apenas o ativo e aposta atrás da opção binária em nosso exemplo. Um Mixicle completo [135] pode fornecer duas formas de confidencialidade. Ela esconde dos observadores: (1) Qual evento o os jogadores apostam em (ou seja, q e r), mas também (2) em qual jogador ganhou a aposta. Como os Mixicles são executados no MAINCHAIN, qualquer um dos jogadores precisaria retransmitir switch(r) de DON para MAINCHAIN, ou um executável exec pode ser criado que

é acionado na saída pelo ConfSwitch e chama outro adaptador para enviar switch(r) para MAINCHAIN. Também vale a pena considerar um terceiro tipo sutil de confidencialidade. Em uma implementação básica do ConfSwitch, O está executando o adaptador no DON e, portanto, aprende o ativo – CBT em nosso exemplo – e, portanto, a natureza da opção binária. Conforme discutido no Apêndice C.3, no entanto, também é possível usar DECO ou Town Crier para ocultar até mesmo esta informação de O. Neste caso, o O não aprende mais informações do que um observador público de SC. Para mais detalhes sobre Mixicles, recomendamos aos leitores [135].

Fair Sequencing Services

One important service that we expect DONs will oﬀer that leverages their networking, computation, and storage capabilities is called Fair Sequencing Services (FSS). Although FSS may be viewed simply as an application realized within the DON framework, we highlight it as a service that we believe will be in high demand across blockchains, and which we expect the Chainlink network to support actively. When executed on public blockchain networks, many of today’s DeFi applications reveal information that can be exploited by users to their own beneﬁt, analogous to the kind of insider leaks and manipulation opportunities that are pervasive in existing markets [64, 155]. FSS instead paves the way toward a fair DeFi ecosystem. FSS helps developers to build DeFi contracts that are protected from market manipulation resulting from information leakage. Given the problems we highlight below, FSS is especially attractive for layer-2 services and ﬁts within the framework for such services that we discuss in Section 6. The challenge: In existing permissionless systems, transactions are ordered entirely at the discretion of miners. In permissioned networks, the validator nodes may exert the same power. This is a form of largely unrecognized ephemeral centralization in otherwise decentralized systems. A miner can (temporarily) censor transactions for its own beneﬁt [171] or reorder them to maximize its own gain, a notion called minerextractable value (MEV) [90]. The term MEV is slightly deceptive: It does not refer only to value that miners can capture: Some MEV can be captured by ordinary users. Because miners have more power than ordinary users, however, MEV represents an upper bound on the amount of value any entity can obtain through adversarial reordering and complementary transaction insertion. Even when miners order transactions simply based on fees (gas), without manipulation, users themselves can manipulate gas prices to advantage their transactions over those of less sophistication. Daian et al. [90] document and quantify ways in which bots (not miners) take advantage of gas dynamics in a way that harms users of DeFi systems today and how MEV even threatens the stability of the underlying consensus layer in a blockchain. Other examples of transaction-order manipulation surface regularly, e.g., [50, 154].

New transaction-processing methods such as rollups are a very promising approach to the scaling problems of high-throughput blockchains. They do not, however, address the problem of MEV. Instead, they shift it to the entity that generates the rollup. That entity, whether the operator of a smart contract or a user furnishing a (zk-)rollup with a validity proof, has the power to order and insert transactions. In other words, rollups swap MEV for REV: Rollup-Extractable Value. MEV aﬀects upcoming transactions that have been submitted to the mempool but are not yet committed on chain. Information about such transactions is broadly available in the network. Miners, validators, and ordinary network participants can therefore exploit this knowledge and create dependent transactions. In addition, miners and validators may inﬂuence the order of those transactions that they commit themselves and exploit this to their advantage. The problem of undue inﬂuence by leaders on transaction ordering in consensus protocols has been known in the literature since the 1990s [71, 190], but no satisfying solutions have been realized in practice so far [97]. The main reason is that proposed solutions—at least until very recently—cannot readily be integrated with public blockchains, as they rely on the content of transactions remaining secret until after their ordering has been determined. Fair Sequencing Services (FSS) overview: DONs will provide tools to decentralize transaction ordering and implement it according to a policy speciﬁed by a relying contract creator, ideally one that is fair, and not advantaging actors who wish to manipulate transaction ordering. Collectively, these tools constitute FSS. FSS includes three components. The ﬁrst is monitoring of transactions. In FSS, oracle nodes in O both monitor the mempool of MAINCHAIN and (if desired) permit oﬀ-chain submission of transactions through a specialized channel. The second is sequencing of transactions. The nodes in O order transactions for a relying contract according to a policy deﬁned for that contract. The third is posting of transactions. After the transactions are ordered, the nodes in O jointly send the transactions to the main chain. The potential beneﬁts of FSS include: • Order-fairness: FSS includes tools to help developers ensure that transactions input to a particular contract are ordered in a way that does not give an unfair advantage to well-resourced and/or technically savvy users. Ordering policies can be speciﬁed for this purpose. • Reduction or elimination of information leaks: By ensuring that network participants cannot exploit knowledge about upcoming transactions, FSS can abate or eliminate attacks like front-running that are based on information available in the network before transactions are committed. Preventing exploitation of such leakage ensures that adversarial transactions which depend on original pending transactions cannot enter the ledger before the original transactions are committed.

• Reduced transaction cost: By eliminating players’ need for speed in submitting their transactions to a smart contract, FSS can greatly reduce the cost of transaction processing. • Priority ordering: FSS can automatically give critical transactions special priority ordering. For example, in order to prevent front-running attacks against oracle reports, e.g., [79], FSS can insert an oracle report into a stream of transactions retroactively. An overarching goal of the FSS in DONs is to empower DeFi creators to realize fair ﬁnancial systems, that is, systems that don’t advantage particular users (or miners) over others on the basis of speed, insider knowledge, or ability to perform technical manipulation. While a crisp, general notion of fairness is elusive, and perfect fairness in any reasonable sense is unachievable, FSS aims to provide developers with a powerful set of tools so that they can enforce policies that help meet their design goals for DeFi. We note that while the main goal of FSS is to act as a fair sequencing service for the MAINCHAIN that DONs target, some of the same fairness desiderata that FSS guarantees can also be appropriate for (decentralized) protocols that are run among DON parties. Thus, FSS can be viewed more broadly as a service provided by a subset of DON nodes to fairly sequence not only transactions sent by users of MAINCHAIN but also transactions (i.e., messages) shared among other DON nodes. In this section, we will focus primarily on the goal of sequencing MAINCHAIN transactions. Section organization: In Section 5.1, we describe two high-level applications that motivate the design of FSS: preventing front-running of oracle reports and preventing front-running of user transactions. We then provide more details on the design of FSS in Section 5.2. Section 5.3 describes examples of fair ordering guarantees and means to achieve them. Finally, Section 5.4 and Section 5.5 discuss network-level threats to such policies and means to address them, respectively for network ﬂooding and Sybil attacks. 5.1 The Front-Running Problem To explain the goals and design of FSS, we describe two general forms of front-running attacks and the limitations of existing solutions. Front-running exempliﬁes a class of transaction-ordering attacks: There are a number of related attacks such as backrunning and sandwiching (front-running plus back-running) [237] that we don’t cover here, but which FSS also helps address. 5.1.1 Oracle Front-Running In their traditional role of providing oﬀ-chain data to blockchain applications, oracles become a natural target for front-running attacks.

Consider the common design pattern of using an oracle to supply various price feeds to an on-chain exchange: periodically (say every hour), the oracle collects price data for diﬀerent assets and sends these to an exchange contract. These price-data transactions present obvious arbitrage opportunities: For example, if the newest oracle report lists a much higher price for some asset, an adversary could front-run the oracle report to buy up assets and immediately resell them once the oracle’s report is processed. Speed bumps and retroactive pricing: A natural solution to the oracle frontrunning problem is to give oracle reports special priority over other transactions. For example, oracle reports could be sent with high fees to encourage miners to process them ﬁrst. But this will not prevent front-running if the arbitrage opportunity is high, nor can it prevent arbitrage by the miners themselves. Some exchanges have thus resorted to implementing more heavyweight “speedbumps,” such as queuing user transactions for a number of blocks before processing them, or retroactively adjusting prices when a new oracle report arrives. The disadvantages of these solutions are that they add complexity to the exchange implementation, increase storage requirements and thus transaction costs, and disrupt the user experience as asset exchanges are only conﬁrmed after a signiﬁcant time period. Piggybacking: Before moving on to FSS, we discuss piggybacking, a quite simple and elegant solution to the oracle front-running problem. It is not applicable to address front-running in other scenarios, however. In short, instead of periodically sending reports to the on-chain contract, oracles publish signed reports that users append to their transactions when buying or selling on-chain assets. The exchange then simply checks that the report is valid and fresh (e.g., the oracle can sign a range of blocks for which the report is valid), and extracts the relevant price feed from it. This simple approach has a number of advantages over the above “speed bump” approach: (1) The exchange contract need not keep state of price feeds, which should lead to lower transaction costs; (2) As oracle reports are posted on chain on a byneed basis, oracles can generate more frequent updates (e.g., every minute), thereby minimizing arbitrage opportunities from front-running a report9; (3) Transactions can be validated immediately, as they always include a fresh price feed. The approach is not perfect, however. First, this piggybacking solution puts the onus on the exchange’s users to fetch up-to-date oracle reports and attach them to their transactions. Second, while piggybacking minimizes arbitrage opportunities, it cannot fully prevent them without aﬀecting the liveness of the on-chain contract. Indeed, if an oracle report is valid until some block number n, then a transaction submitted to block n + 1 would require a new valid report. Due to inherent delays in the propagation of reports from oracles to users, the new report that is valid for block n + 1 would have 9Arbitrage is only worthwhile if the exploitable diﬀerence in asset prices exceeds the extraneous fees required to buy and sell the assets, e.g., those collected by miners and the exchange.

to be publicized some period before block n + 1 is mined, say at block n −k, thereby creating a sequence of k blocks where a short-lived arbitrage opportunity exists. We now describe how FSS gets around these limitations. Prioritizing oracle reports with FSS: FSS can address the oracle front-running problem by building upon the above piggybacking solution, but pushing the additional work of augmenting transactions with oracle reports to the Decentralized Oracle Network. At a high level, oracle nodes collect transactions destined for an on-chain exchange, agree on a real-time price feed, and post the price feed along with the collected transactions to the main-chain contract. Conceptually, one can think of this approach as a “data-augmented transaction batching”, where the oracle ensures that an up-to-date price feed is always added to transactions. FSS solutions can be implemented transparently to the exchange’s users, and with minimal changes to contract logic, as we describe in more detail in Section 5.2. Ensuring that fresh oracle reports are always prioritized over user transactions is just one example of an ordering policy that FSS can adopt and enforce. Policies of FSS for ensuring order fairness are described more generally in Section 5.3. 5.1.2 Front-Running User Transactions We now turn to front-running in generic applications, where the defense method above does not work. The problem can be captured broadly through the following scenario: An adversary sees some user transaction tx1 sent into the P2P network and injects its own adversarial transaction tx2, so that tx2 is processed before tx1 (e.g., by paying a higher transaction fee). For instance, this kind of front-running is common among bots that exploit arbitrage opportunities in DeFi systems [90] and has aﬀected users of various decentralized applications [101]. Imposing a fair order among the transactions processed on the blockchain addresses this problem. More fundamentally, seeing the details of tx1 is sometimes not even necessary and knowledge of its mere existence may allow an adversary to front-run tx1 through its own tx2 and defraud the innocent user that created tx1. For example, the user might be known to trade a particular asset at regular times. Preventing such attacks requires mitigations that avoid leakage of metadata as well [62]. Some solutions for this problem exist, but they introduce delays and usability concerns. From network-order to ﬁnalized-order with FSS: Opportunities for front-running arise because existing systems have no mechanisms to ensure that the order in which transactions appear on chain respects the order of events and the information ﬂow outside the network. This represents a problem arising from deﬁciencies in the implementation of applications (e.g., trading platforms) on a blockchain. Ideally, one would ensure that transactions are committed on the blockchain in the same order as they were created and sent to the blockchain’s P2P network. But since the blockchain network

Fair Sequencing Services general schematic showing transaction flow from users through DON to main chain

is distributed, no such order can be captured. FSS therefore introduces mechanisms to safeguard against violations of fairness, which arise only because of the distributed nature of the blockchain network. 5.2 FSS Details Figure 12: Order-fair mempool with two diﬀerent transaction paths: direct and mempool-based. Fig. 12 shows a general schematic of the FSS. For ensuring fairness, the DON providing FSS must interfere with the ﬂow of transactions as they enter MAINCHAIN. Adjustments to clients, to smart contracts on MAINCHAIN, or to both may be necessary. At a high level, processing of transactions by FSS can be decomposed into three phases, described below: (1) Transaction monitoring; (2) Transaction sequencing; and (3) Transaction posting. Depending on the ordering method used for transaction sequencing, additional protocol steps are needed, as described in the next section. 5.2.1 Transaction Processing Transaction monitoring: We envision two diﬀerent approaches for FSS to monitor user transactions destined for a speciﬁc smart contract, direct and mempool-based: • Direct: The direct approach is conceptually simplest, but requires changes to user clients so that transactions are sent directly to the Decentralized Oracle

Network nodes, rather than to the nodes of the main chain. The DON collects user transactions destined to a speciﬁc smart contract SC and orders them based on some ordering policy. The DON then sends the ordered transactions to the smart contract on the main chain. Some ordering mechanisms also require the direct approach because the user that creates a transaction must cryptographically protect it before sending it to FSS. • Mempool-based: To facilitate the integration of FSS with legacy clients, the DON can use Mempool Services (MS) to monitor the main chain’s mempool and collect transactions. Direct transmission is likely to be the preferred implementation for many contracts, and we believe it should be fairly practical in many cases. We brieﬂy discuss how existing DApps could be minimally modiﬁed to support direct transmission while preserving a good user experience. We describe approaches using Ethereum and MetaMask [6] since these are the most popular choices today, but the mentioned techniques should extend to other chains and wallets. A recent Ethereum Improvement Proposal, “EIP-3085: Wallet add Ethereum chain RPC method” [100], will make it easy to target custom Ethereum chains (using a diﬀerent CHAIN ID than that of MAINCHAIN to prevent replay attacks) from MetaMask and other browserbased wallets. After implementation of this proposal, a DApp seeking to use a DON would simply add a single method call to their front-end to be able to directly transmit transactions to any DON exposing an Ethereum-compatible API. In the meantime, “EIP-712: Ethereum typed structured data hashing and signing” [49] provides a slightly more involved but already widely deployed alternative, where a DApp user can use MetaMask to sign structured data specifying a DON transaction. The DApp can send this signed structured data to the DON. Finally, we note that hybrid approaches are also possible. For example, legacy clients can continue to send transactions into the main chain’s mempool, but critical transactions (e.g., oracle reports) are sent to DON nodes directly (in particular, the set of nodes providing oracle reports such as price-feed updates and the set of nodes providing FSS may overlap or be identical). Transaction sequencing: The main purpose of FSS is to guarantee that user transactions are ordered according to a pre-deﬁned policy. The nature of this policy will depend on the application’s needs and the types of unfair transaction orderings that it aims to prevent. Since FSS on the DON is capable of processing data and maintaining local state, they may impose an arbitrary sequencing policy based on the information that is available at the oracles. The particular ordering policies and their implementation are discussed subsequently in Section 5.3.

Transaction posting: After collecting and ordering user transactions, received either directly from users or collected from the mempool, the DON sends these transactions to the main chain. As such, a DON’s interactions with the main chain remain subject to (potentially unfair) transaction ordering governed by the main chain’s miners. To harness the beneﬁts of decentralized transaction ordering, the target smart contract SC thus has to be designed to treat the DON as a “ﬁrst-class” citizen. We distinguish two approaches: • DON-only contracts: The simplest design option is to have the main chain smart contract SC only accept transactions that have been processed by the DON. This ensures that the smart contract processes transactions in the order proposed by the DON, but de-facto restricts the smart contract to operating in a committeebased system (i.e., the DON committee now has ongoing power to determine the ordering and inclusion of transactions). • Dual-class contracts: A preferred, more granular design has the main chain smart contract SC accept transactions originating both from the DON and from legacy users,10 but places traditional “speed bumps” on transactions that were not processed by the DON. For example, transactions from the DON may be processed immediately, whereas legacy transactions get “buﬀered” by the smart contract for a ﬁxed period of time. Other standard mechanisms for preventing front-running such as commit-reveal schemes or VDFs [53] could also be applied to legacy transactions. This ensures that DON-ordered transactions do get processed in the order agreed upon, without giving the DON the unwanted power to censor transactions. As the imposition of transaction ordering by FSS requires that transactions are aggregated “oﬀ-chain,” this solution is naturally combined with other aggregation techniques that aim to reduce on-chain processing costs. For example, after collecting and ordering transactions, the DON may send these transactions to the main chain as a single “batched transaction” (e.g., a rollup), thereby reducing the aggregate transaction fee. Enforcing the transaction order: Whether in a DON-only or dual-class design, the main chain smart contract SC and the DON have to be co-designed so as to guarantee that the DON’s transaction ordering is upheld. Here also, we envision diﬀerent design options: • Sequence numbers: The DON can append a sequence number to each transaction, and send these transactions into the main chain’s mempool. The main 10If the DON’s transaction monitoring is based on the mempool, legacy transactions must be distinguishable from DON transactions so that they are not collected by the DON, e.g., via a special tag embedded in the transaction or by specifying a particular gas price, e.g. DON transactions have gas prices below a certain threshold.

chain smart contract SC ignores transactions that arrive “out-of-sequence.” We note that in this setting, the main-chain miners can decide to ignore the DON’s transaction ordering, thereby causing transactions to fail. It is possible by keeping (expensive) state for SC to enforce correct transaction ordering, somewhat analogously to how TCP buﬀers out-of-order packets until missing packets are received. • Transaction nonces: For many blockchains, and in particular for Ethereum, the above sequence-numbering approach can leverage built-in transaction nonces to enforce that the main-chain smart contract SC processes transactions in sequence. Here, the DON nodes send transactions to the main chain through a single mainchain account, protected with a key shared among the DON nodes. The account’s transaction nonce ensures that transactions are mined and processed in the correct order. • Aggregate transactions: The DON can aggregate multiple transactions in a rollup (or in a bundle similar to a rollup). The main-chain smart contract needs to be designed to handle such aggregate transactions. • Aggregate transactions with a main chain proxy: Here, the DON similarly bundles transactions into one “meta-transaction” for the main chain, but relies on a custom proxy smart contract to unpack the transactions and relay them to the target contract SC. This technique can be useful for legacy compatibility. Metatransactions act like rollups but diﬀer in that they consist of an uncompressed list of transactions posted once to the main chain. The last design has the advantage of seamlessly supporting user transactions that are themselves proxied through a main chain contract before reaching the DON’s target contract SC. For example, consider a user who sends a transaction to some wallet contract, which in turn sends an internal transaction to SC. Assigning a sequence number to such a transaction would be tricky, unless the user’s wallet contract is specially designed to forward the sequence number with every internal transaction to SC. Similarly, such internal transactions cannot be easily aggregated into a metatransaction that is sent directly to SC. We discuss further design considerations for such proxied transactions below. 5.2.2 Transaction Atomicity Our discussion thus far has implicitly assumed that transactions interact with a single on-chain smart contract (e.g., a user sends a buy request to an exchange). Yet, in systems such as Ethereum, a single transaction can consist of multiple internal transactions, e.g., one smart contract calling a function in another contract. Below, we describe two high-level strategies for sequencing “multi-contract” transactions, while preserving the atomicity of the transaction (i.e., the sequence of actions prescribed by the transaction are all executed in the correct order, or not at all).

Strong atomicity: The simplest solution is to apply FSS, as described above, directly to entire “multi-contract” transactions. That is, users send their transactions into the network and FSS monitors, sequences, and posts these transactions to the main chain. This approach is technically simple, but has one potential limitation: If a user transaction interacts with two contracts SC1 and SC2 that both want to leverage fair sequencing services, then the sequencing policy of these two contracts has to be consistent. That is, given two diﬀerent transactions tx1 and tx2 that each interacts with both SC1 and SC2, it must not be the case that the policy of SC1 orders tx1 before tx2 whereas the policy of SC2 prescribes the opposite order. For the vast majority of scenarios of interest, we envision that the sequencing policies adopted by diﬀerent contracts will be consistent. For example, both SC1 and SC2 may want transactions to be ordered by their approximate arrival time in the mempool, and SC1 may further want certain oracle reports to always be delivered ﬁrst. As the latter oracle report transactions do not interact with SC2, the policies are consistent. Weak atomicity: In its full generality, FSS could be applied at the level of individual internal transactions. Consider transactions of the form tx = { ˜txpre, ˜txSC, ˜txpost}, consisting of some initial transaction(s) ˜txpre, which results in an internal transaction ˜txSC to SC, which in turn issues internal transaction(s) ˜txpost. The sequencing policy of SC might determine how the internal transaction ˜txSC has to be ordered with respect to other transactions sent to SC, but leave open the sequencing order for ˜txpre and ˜txpost. Given the intrinsics of transaction processing in systems such as Ethereum, developing a sequencing service that targets speciﬁc internal transactions is not straightforward. With a specially designed contract SC, this may be realizable as follows: 1. The transaction tx is sent into the network and mined (without any sequencing performed by FSS). The initial ˜txpre is executed, and calls ˜txSC. 2. SC does not execute ˜txSC and returns. 3. FSS monitors internal transactions to SC, sequences them, and posts them back to SC (i.e., by sending transactions ˜txSC directly to SC). 4. SC processes the transactions ˜txSC received from FSS, and issues internal transactions ˜txpost that result from ˜txSC. With this approach, transactions are not executed fully atomically (i.e., the original transaction tx gets broken up into multiple on-chain transactions), but the ordering of internal transactions is preserved. This solution entails a number of design constraints. For example, ˜txpre cannot assume that ˜txSC and ˜txpost will be executed. Moreover, SC should be designed so as to execute transactions ˜txSC and ˜txpost on behalf of a certain user, even though they were

sent by FSS. For these reasons, the more coarse-grained “Strong Atomicity” solution above is likely preferable in practice. For respecting more complex dependencies, involving multiple transactions and their respective internal transactions, the transaction scheduler of FSS may contain elaborate functions that resemble those found in transaction managers of relational database managers. 5.3 Fair Transaction Sequencing Here we discuss two notions of fairness for transaction sequencing and the corresponding implementations, which may be realized by FSS: order-fairness based on a policy imposed by FSS and secure causality preservation, which requires additional cryptographic methods in FSS. Order-fairness: Order-fairness is a notion of temporal fairness in consensus protocols that has ﬁrst been introduced formally by Kelkar et al. [144]. Kelkar et al. aim to achieve a form of natural policy in which transactions are ordered based on the time they are ﬁrst received by the DON (or the P2P network, in the case of a mempool-based FSS). In a decentralized system, however, diﬀerent nodes may see transactions arrive in a diﬀerent order. Establishing a total order on all transactions is the very problem solved by the consensus protocol underlying MAINCHAIN. Kelkar et al. [144] therefore introduce a weaker notion that can be achieved with the help of a Decentralized Oracle Network, called “block-order fairness.” It groups the transactions that the DON has received during a time interval into a “block” and inserts all transactions of the block concurrently and at the same position (i.e., height) into MAINCHAIN. They are thus ordered together and must be executable in parallel, without creating any conﬂicts among them. Roughly speaking, orderfairness then states that if a large fraction of nodes see transaction $\tau_1$ before $\tau_2$, then $\tau_1$ will be sequenced before or in the same block as $\tau_2$. By imposing such a coarse granularity on transaction order, the opportunities for front-running and other orderrelated attacks are greatly reduced. Kelkar et al. propose a family of protocols called Aequitas [144], which address diﬀerent deployment models, including synchronous, partially synchronous, and asynchronous network settings. Aequitas protocols impose signiﬁcant communication overhead relative to basic BFT consensus and are therefore not ideal for practical use. We believe, however, that practical variants of Aequitas will emerge that can be used for transaction sequencing in FSS and other applications. Some related schemes have already been proposed that have less accompanying formalism and weaker properties, e.g., [36, 151, 236], but better practical performance. These schemes can be supported in FSS as well. It is also worth noting that the term “fairness” appears elsewhere in the blockchain literature with a diﬀerent meaning, namely fairness in the sense of opportunity for

miners proportional to their committed resources [106, 181] or for validators in terms of equal opportunity [153]. Secure causality preservation: The most widely known approach to prevent frontrunning and other ordering violations in distributed platforms relies on cryptographic techniques. Their common feature is to hide the transaction data itself, waiting until the order at the consensus layer has been established, and to reveal the transaction data later for processing. This preserves the causal order among the transactions that are executed by the blockchain. The relevant security notions and cryptographic protocols have been developed considerably before the advent of blockchains [71, 190]. The security conditions of “input causality” [190] and “secure causality preservation” [71, 97] require formally that no information about a transaction becomes known before the position of this transaction in the global order has been determined. An adversary must not be able to infer any information until that time, in a cryptographically strong sense. One can distinguish four cryptographic techniques to preserve causality: • Commit-reveal protocols [29, 142, 145]: Instead of a transaction being announced in the clear, only a cryptographic commitment to the transaction is broadcast. After all committed but hidden transactions have been ordered (in early blockchain systems on MAINCHAIN itself, but here by FSS), the sender must open the commitment and reveal the transaction data within a predetermined time interval. The network then veriﬁes that the opening satisﬁes the earlier commitment. The origins of this method date prior to the advent of blockchains. Although it is particularly simple, the approach introduces considerable drawbacks and is not easy to employ for two reasons. First, since only the commitment exists at the level of the ordering protocol, the semantics of the transaction cannot be validated during consensus. An additional round-trip to the client is required. More severely, though, weighs the possibility that no opening may ever arrive, which could amount to a denial-of-service attack. Furthermore, it is diﬃcult to determine whether the opening is valid in a consistent, distributed manner because all participants must agree on whether the opening arrived in time. • Commit-reveal protocols with delayed recovery [145]: One challenge with the commit-reveal approach is that a client may commit to a transaction speculatively and reveal it later only if subsequent transactions make it proﬁtable. A recent variant of the commit-reveal approach improves the resilience against this kind of misbehavior. In particular, the TEX protocol [145] addresses this problem using a clever approach in which encrypted transactions include a decryption key obtainable by computing a veriﬁable delay function (VDF) [53, 221]. If a client fails to decrypt her transaction in a timely way, others in the system will decrypt it on her behalf by solving a moderately hard cryptographic puzzle.

• Threshold encryption [71, 190]: This method exploits that the DON may perform threshold-cryptographic operations. Assume FSS maintains an encryption public key pkO and the oracles share the corresponding private key among themselves. Clients then encrypt transactions under pkO and send them to FSS. FSS orders transactions on the DON, then decrypts them, and ﬁnally injects them into MAINCHAIN in the ﬁxed order. Encryption therefore ensures that ordering is not based on the transaction content, but that the data itself is available when needed. This method was originally proposed by Reiter and Birman [190] and later reﬁned by Cachin et al. [71], where it was integrated with a permissioned consensus protocol. More recent work has explored the use of threshold cryptography as a consensus-level mechanism for generic messages [33, 97] and for general computations with shared data [41]. Compared to commit-reveal protocols, threshold encryption prevents simple denialof-service attacks (although care is required given the computational cost of decryption). It lets the DON proceed autonomously, at its own speed and without waiting for further client actions. Transactions may be validated immediately after they have been decrypted. Moreover, clients encrypt all transactions with one key for the DON and the communication pattern remains the same as with other transactions. Managing the threshold key securely and with changing nodes in O, however, may pose additional diﬃculties. • Committed secret sharing [97]: Instead of encrypting the transaction data under a key held by the DON, the client may also secret-share it for the nodes in O. Using a hybrid, computationally secure secret sharing scheme, the transaction is encrypted ﬁrst using a symmetric cipher with a random key. Only the corresponding symmetric key is shared and the ciphertext is submitted to the DON. The client must send one key share to each node in O using a separately encrypted message. The remaining protocol steps are the same as with threshold encryption, except that the transaction data is decrypted with the symmetric algorithm after reconstructing the per-transaction key from its shares. This method does not require setup or management of a public-key cryptosystem associated with the DON. However, the clients must be aware of the nodes in O and communicate in a secure context with each one of them, which places additional burden on the clients. Although the cryptographic methods oﬀer complete protection against information leaking from submitted transactions to the network, they do not conceal metadata. For example, an IP address or an Ethereum address of the sender could still be used by an adversary to perform front-running and other attacks. Various privacy-enhancing techniques deployed at the network layer, e.g., [52, 95, 107], or the transaction layer, e.g., [13, 65], would be needed to accomplish this goal. The impact of a particular piece of metadata, namely to which contract a transaction is sent, can be (partially) concealed

through multiplexing many contracts on the same DON. Cryptographic concealment of transactions per se also doesn’t prevent prioritization of transactions by corrupted DON nodes in collusion with transaction senders. Secure causality as guaranteed by cryptographic protocols complement the orderfairness guarantees for any policy, and we intend to explore a combination of the two methods, where this is possible. If an adversary cannot gain signiﬁcant advantage from observing metadata, the secure causality-preservation protocols could be used alongside a na¨ıve ordering approach as well. For example, oracle nodes can write transactions to L as soon as they receive them, without duplication. Transactions would then be ordered according to their appearance on L and subsequently decrypted. We also plan to consider the use of TEEs as a way to help enforce fair ordering; for example, Tesseract [44] may be viewed as achieving a form of causal ordering, but one strengthened by the ability of the TEE to process transactions in explicit form while retaining their conﬁdentiality. 5.4 Network-Layer Considerations So far, our description of FSS has mainly focused on the problem of enforcing that the ﬁnalized order of transactions matches their observed order in the network. Hereafter, we consider fairness issues that could arise at the network layer itself. High-frequency traders in conventional electronic marketplaces invest considerable resources to obtain superior network speed [64], and traders in cryptocurrency exchanges exhibit similar behavior [90]. Network speed confers an advantage both in observing the transactions of other parties and in submitting competing transactions. One remedy deployed in practice and popularized in the book Flash Boys [155] is the “speed bump” introduced initially in the IEX exchange [128] and later in other exchanges [179] (with mixed results [19]). This mechanism imposes a delay (350 microseconds in IEX) on access to the market, with the aim of neutralizing advantages in speed. Empirical evidence, e.g. [128], supports its eﬃcacy in decreasing certain trading costs for ordinary investors. FSS can be used simply to implement an asymmetrical speed bump—one that delays incoming transactions. Budish, Cramton, and Shim [64] argue that exploitation of advantages in speed is inescapable in continuous-time markets, and argue for a structural remedy in the form of batch-auction-based markets. But this approach has not taken hold broadly in existing trading platforms. Conventional trading systems are centralized, typically receiving transactions through a single network connection. In a decentralized system, by contrast, it is possible to observe transaction propagation from multiple vantage points. Consequently, it is possible to observe behaviors such as network ﬂooding in a P2P network. We intend to explore network-layer approaches to FSS that help developers to specify policies prohibiting such undesirable network behaviors.

5.5 Entity-Level Fairness Policies Order-fairness and secure causality aim at enforcing an ordering on transactions that respects the time when they were created and ﬁrst submitted to the network. A limitation of this notion of fairness is that it does not prevent attacks in which an adversary gains an advantage by ﬂooding a system with many transactions, a strategy observed in the wild as a way to perform eﬀective transaction sniping in token sales [159] and to create congestion resulting in liquidation of collateralized debt positions (CDPs) [48]. In other words, order-fairness enforces fairness with respect to transactions, not players. As shown in the CanDID system [160], it is possible to use oracle tools such as DECO or Town Crier in conjunction with a committee of nodes (such as a DON) to achieve various forms of Sybil-resistance while protecting privacy. Users can register identities and provide evidence of their uniqueness without disclosing the identities themselves. Sybil-resistant credentials oﬀer a possible approach to enriching transaction-ordering policies in a way that would limit opportunities for ﬂooding attacks. For example, a token sale might permit only one transaction per registered user, where registration requires a proof of uniqueness of a national identiﬁer, such as a Social Security Number. Such an approach isn’t foolproof, but may prove a useful policy to mitigate transactionﬂooding attacks.

Serviços de sequenciamento justo

Um serviço importante que esperamos que DONs ofereça e que aproveite seus recursos de rede, computação e armazenamento é chamado de Fair Sequencing Services (FSS). Embora o FSS possa ser visto simplesmente como uma aplicação realizada dentro da estrutura DON, destacamos-o como um serviço que acreditamos que terá alta demanda em todo o mundo. blockchains, e que esperamos que a rede Chainlink suporte ativamente. Quando executados em redes blockchain públicas, muitos dos aplicativos DeFi atuais revelar informações que podem ser exploradas pelos usuários em seu próprio benefício, de forma análoga a o tipo de vazamentos internos e oportunidades de manipulação que são difundidos nos mercados existentes mercados [64, 155]. Em vez disso, o FSS abre caminho para um ecossistema DeFi justo. FSS ajuda os desenvolvedores a construir contratos DeFi protegidos contra manipulação de mercado decorrentes de vazamento de informações. Dados os problemas que destacamos abaixo, o FSS é especialmente atraente para serviços da camada 2 e se enquadra na estrutura para tais serviços que discutimos na Seção 6. O desafio: Nos sistemas sem permissão existentes, as transações são ordenadas inteiramente a critério dos mineiros. Em redes autorizadas, os nós validator podem exercer o mesmo poder. Esta é uma forma de centralização efêmera em grande parte não reconhecida na sistemas de outra forma descentralizados. Um minerador pode (temporariamente) censurar transações para seus benefício próprio [171] ou reordená-los para maximizar seu próprio ganho, uma noção chamada valor minerextraível (MEV) [90]. O termo MEV é ligeiramente enganador: não se refere apenas ao valor que os mineradores podem capturar: Alguns MEV podem ser capturados por usuários comuns. No entanto, como os mineradores têm mais poder do que os usuários comuns, o MEV representa um limite superior na quantidade de valor que qualquer entidade pode obter por meio de reordenamento adversário. e inserção de transação complementar. Mesmo quando os mineradores ordenam transações simplesmente com base em taxas (gás), sem manipulação, os próprios usuários podem manipular os preços do gás para favorecer suas transações em detrimento daquelas de menor sofisticação. Daian et al. [90] documenta e quantifica as maneiras pelas quais os bots (não os mineradores) tomam vantagem da dinâmica dos gases de uma forma que prejudica os usuários dos sistemas DeFi hoje e como MEV até ameaça a estabilidade da camada de consenso subjacente em um blockchain. Outros exemplos de manipulação de ordens de transação surgem regularmente, por exemplo, [50, 154].Novos métodos de processamento de transações, como rollups, são uma abordagem muito promissora aos problemas de dimensionamento de blockchains de alto rendimento. Eles não abordam, no entanto, o problema do MEV. Em vez disso, eles o transferem para a entidade que gera o rollup. Isso entidade, seja o operador de um smart contract ou um usuário fornecendo a (zk-)rollup com uma prova de validade, tem o poder de ordenar e inserir transações. Em outras palavras, rollups trocar MEV por REV: valor extraível de rollup. MEV afeta as próximas transações que foram enviadas ao mempool mas ainda não estão comprometidos em cadeia. As informações sobre essas transações são amplamente disponível na rede. Mineiros, validators e participantes comuns da rede podem portanto, explore esse conhecimento e crie transações dependentes. Além disso, mineradores e validators podem influenciar a ordem das transações que realizam e explorar isso em seu benefício. O problema da influência indevida dos líderes na ordem das transações em consenso protocolos são conhecidos na literatura desde a década de 1990 [71, 190], mas nenhum soluções foram implementadas na prática até agora [97]. A principal razão é que as soluções propostas – pelo menos até muito recentemente – não podem ser facilmente integradas com os serviços públicos. blockchains, pois dependem do conteúdo das transações que permanecem secretas até depois sua ordem foi determinada. Visão geral dos Serviços de Sequenciamento Justo (FSS): DONs fornecerá ferramentas para descentralizar a ordenação de transações e implementá-las de acordo com uma política especificada por um país confiável. criador do contrato, de preferência um que seja justo e não vantajoso para os atores que desejam manipular a ordem das transações. Coletivamente, essas ferramentas constituem o FSS. O FSS inclui três componentes. O primeiro é o monitoramento das transações. No FSS, oracle nós em O monitoram o mempool de MAINCHAIN e (se desejado) permitem submissão off-chain de transações por meio de canal especializado. O segundo é o sequenciamento das transações. Os nós em transações de ordem O para um contrato confiável de acordo com uma política definida para esse contrato. O terceiro é o lançamento de transações. Após as transações serem ordenadas, os nós em O enviam conjuntamente as transações para o cadeia principal. Os benefícios potenciais do FSS incluem: • Equidade nas ordens: o FSS inclui ferramentas para ajudar os desenvolvedores a garantir que as transações contribuições para um determinado contrato sejam ordenadas de uma forma que não dê uma margem injusta vantagem para usuários com bons recursos e/ou tecnicamente experientes. Políticas de pedidos podem ser especificados para esse fim. • Redução ou eliminação de fugas de informação: Ao garantir que os participantes da rede não possam explorar o conhecimento sobre transacções futuras, o FSS pode reduzir ou eliminar ataques como front-running que são baseados em informações disponíveis em rede antes que as transações sejam confirmadas. Prevenir a exploração de tais o vazamento garante que as transações contraditórias que dependem da pendência original as transações não podem entrar no razão antes que as transações originais sejam confirmadas.• Custo de transação reduzido: eliminando a necessidade dos jogadores de velocidade no envio suas transações para smart contract, o FSS pode reduzir bastante o custo do processamento de transações. • Ordenação de prioridade: o FSS pode atribuir automaticamente prioridade especial a transações críticas encomenda. Por exemplo, para evitar ataques frontais contra oracle relatórios, por exemplo, [79], o FSS pode inserir um relatório oracle em um fluxo de transações retroativamente. Um objetivo abrangente do FSS em DONs é capacitar os criadores de DeFi para realizarem sistemas financeiros, isto é, sistemas que não beneficiam usuários específicos (ou mineradores) sobre outros com base na velocidade, conhecimento interno ou capacidade de executar tarefas técnicas manipulação. Embora uma noção clara e geral de justiça seja ilusória, e a justiça perfeita em qualquer sentido razoável é inatingível, o FSS visa fornecer aos desenvolvedores um poderoso conjunto de ferramentas para que possam aplicar políticas que ajudem a cumprir suas metas de design para DeFi. Observamos que embora o principal objetivo do FSS seja atuar como um serviço de sequenciamento justo para o MAINCHAIN que DONs tem como alvo, alguns dos mesmos desejos de justiça que o FSS garantias também podem ser apropriadas para protocolos (descentralizados) executados entre DON festas. Assim, o FSS pode ser visto de forma mais ampla como um serviço prestado por um subconjunto de nós DON para sequenciar de forma justa não apenas transações enviadas por usuários de MAINCHAIN mas também transações (ou seja, mensagens) compartilhadas entre outros nós DON. Nesta seção, focaremos principalmente no objetivo de sequenciar as transações MAINCHAIN. Organização da seção: Na Seção 5.1, descrevemos duas aplicações de alto nível que motivam o design do FSS: impedir a execução antecipada de relatórios oracle e prevenir front-running das transações do usuário. Em seguida, fornecemos mais detalhes sobre o design do FSS na Seção 5.2. A Seção 5.3 descreve exemplos de garantias e meios de pedidos justos para alcançá-los. Finalmente, a Seção 5.4 e a Seção 5.5 discutem ameaças em nível de rede para tais políticas e meios para enfrentá-las, respectivamente para inundação de rede e Sybil ataques. 5.1 O problema inicial Para explicar os objetivos e o design do FSS, descrevemos duas formas gerais de front-running ataques e as limitações das soluções existentes. Front-running exemplifica uma classe de ataques de ordenação de transações: há uma série de ataques relacionados, como backrunning e sanduíche (front-running mais back-running) [237] que não abordamos aqui, mas que o FSS também ajuda a resolver. 5.1.1 Oracle Front Running Em sua função tradicional de fornecer dados fora da cadeia para aplicações blockchain, oracles tornar-se um alvo natural para ataques frontais.Considere o padrão de design comum de usar um oracle para fornecer vários feeds de preços para uma exchange on-chain: periodicamente (digamos, a cada hora), o oracle coleta dados de preços para ativos diferentes e os envia para um contrato de troca. Essas transações de dados de preços apresentam oportunidades óbvias de arbitragem: por exemplo, se o relatório oracle mais recente listar um preço muito mais alto para algum ativo, um adversário poderia antecipar o relatório oracle para comprar ativos e revendê-los imediatamente assim que o relatório de oracle for processado. Redutores de velocidade e preços retroativos: Uma solução natural para o problema de frontrunning de oracle é dar aos relatórios oracle prioridade especial sobre outras transações. Para por exemplo, relatórios oracle poderiam ser enviados com taxas altas para incentivar os mineradores a processar eles primeiro. Mas isto não impedirá a liderança se a oportunidade de arbitragem for elevada, nem pode impedir a arbitragem por parte dos próprios mineiros. Algumas exchanges recorreram, portanto, à implementação de “redutores de velocidade” mais pesados, como enfileirar as transações do usuário por vários blocos antes do processamento. ou ajustando os preços retroativamente quando um novo relatório oracle chegar. As desvantagens destas soluções são que acrescentam complexidade à implementação da troca, aumentam os requisitos de armazenamento e, portanto, os custos de transação, e perturbam a experiência do usuário, pois as trocas de ativos só são confirmadas após um período de tempo significativo. Pegando carona: Antes de passarmos para o FSS, discutiremos o piggybacking, uma forma bastante simples e solução elegante para o problema inicial oracle. Não é aplicável ao endereço no entanto, liderando em outros cenários. Resumindo, em vez de enviar relatórios periodicamente para o contrato on-chain, oracles publicar relatórios assinados que os usuários anexam às suas transações ao comprar ou vender ativos na cadeia. A exchange então simplesmente verifica se o relatório é válido e atualizado (por exemplo, o oracle pode assinar um intervalo de blocos para os quais o relatório é válido) e extrai o feed de preço relevante dele. Esta abordagem simples tem uma série de vantagens sobre o “lombada” acima abordagem: (1) O contrato de câmbio não precisa manter o estado dos preços, o que deve levar a custos de transação mais baixos; (2) Como os relatórios oracle são publicados na rede conforme a necessidade, oracles podem gerar atualizações mais frequentes (por exemplo, a cada minuto), assim minimizar oportunidades de arbitragem na preparação de um relatório9; (3) As transações podem ser validados imediatamente, pois sempre incluem um novo feed de preços. A abordagem não é perfeita, no entanto. Primeiro, esta solução de carona coloca o responsabilidade dos usuários da exchange buscarem relatórios oracle atualizados e anexá-los aos seus transações. Em segundo lugar, embora o piggybacking minimize as oportunidades de arbitragem, não pode evitá-los totalmente sem afetar a vigência do contrato em cadeia. Na verdade, se um oracle o relatório é válido até algum número de bloco n, então uma transação submetida ao bloco n + 1 exigiria um novo relatório válido. Devido a atrasos inerentes na propagação de relatórios de oracles para os usuários, o novo relatório válido para o bloco n + 1 teria 9A arbitragem só vale a pena se a diferença explorável nos preços dos activos exceder a diferença externa taxas exigidas para comprar e vender os ativos, por exemplo, aquelas cobradas pelos mineradores e pela bolsa.a ser divulgado algum período antes do bloco n + 1 ser minerado, digamos, no bloco n −k, assim criando uma sequência de k blocos onde existe uma oportunidade de arbitragem de curta duração. Nós agora descreva como o FSS contorna essas limitações. Priorizando relatórios oracle com FSS: O FSS pode abordar o oracle front-running problema, aproveitando a solução de carona acima, mas empurrando o adicional trabalho de aumento de transações com relatórios oracle para a Rede Oracle Descentralizada. Em um nível alto, os nós oracle coletam transações destinadas a uma troca na cadeia, concordar com um feed de preços em tempo real e publicar o feed de preços junto com as transações coletadas no contrato da cadeia principal. Conceitualmente, pode-se pensar nesta abordagem como uma “lote de transações aumentadas de dados”, onde o oracle garante que um arquivo atualizado o feed de preços é sempre adicionado às transações. As soluções FSS podem ser implementadas de forma transparente para os usuários da bolsa e com mudanças mínimas na lógica do contrato, conforme descrevemos com mais detalhes na Seção 5.2. Garantindo que relatórios oracle recentes são sempre priorizados em relação às transações do usuário é apenas um exemplo de uma política de ordenação que o FSS possa adotar e aplicar. Políticas do FSS para garantir a ordem justiça são descritos de forma mais geral na Seção 5.3. 5.1.2 Transações de usuário iniciais Passamos agora para o front-running em aplicações genéricas, onde o método de defesa acima não funciona. O problema pode ser capturado de forma ampla através do seguinte cenário: Um adversário vê alguma transação do usuário tx1 enviada para a rede P2P e injeta sua própria transação adversária tx2, de modo que tx2 seja processado antes de tx1 (por exemplo, pagando uma taxa de transação mais alta). Por exemplo, este tipo de front-running é comum entre bots que exploram oportunidades de arbitragem em DeFi sistemas [90] e afetaram usuários de vários aplicativos descentralizados [101]. Imposição de uma ordem justa entre as transações processado em blockchain resolve esse problema. Mais fundamentalmente, às vezes nem é necessário ver os detalhes de tx1 e o conhecimento de sua mera existência pode permitir que um adversário avance o tx1 através de seu possuir o tx2 e fraudar o usuário inocente que criou o tx1. Por exemplo, o usuário pode ser conhecido por negociar um ativo específico em horários regulares. Prevenir tais ataques requer mitigações que também evitam o vazamento de metadados [62]. Algumas soluções para este problema existem, mas introduzem atrasos e preocupações de usabilidade. Do pedido de rede ao pedido finalizado com FSS: Oportunidades para liderança surgem porque os sistemas existentes não têm mecanismos para garantir que a ordem em que as transações aparecem em cadeia respeita a ordem dos eventos e o fluxo de informações fora da rede. Isto representa um problema decorrente de deficiências na implementação de aplicações (por exemplo, plataformas de negociação) em um blockchain. Idealmente, alguém garantir que as transações sejam confirmadas em blockchain na mesma ordem em que foram criado e enviado para a rede P2P de blockchain. Mas como a rede blockchain

Fair Sequencing Services general schematic showing transaction flow from users through DON to main chain

é distribuído, tal ordem não pode ser capturada. O FSS introduz, portanto, mecanismos para proteger contra violações da justiça, que surgem apenas por causa da distribuição natureza da rede blockchain. 5.2 Detalhes do FSS Figura 12: Mempool de ordem justa com dois caminhos de transação diferentes: direto e baseado em mempool. A Figura 12 mostra um esquema geral do FSS. Para garantir a justiça, o DON que fornece o FSS deve interferir no fluxo das transações à medida que elas entram na MAINCHAIN. Ajustes nos clientes, nos smart contracts no MAINCHAIN ou em ambos podem ser necessários. A um nível elevado, o processamento de transações pelo FSS pode ser decomposto em três fases, descritas a seguir: (1) Monitoramento das transações; (2) Sequenciamento de transações; e (3) Lançamento de transações. Dependendo do método de ordenação utilizado para sequenciamento de transações, são necessárias etapas adicionais de protocolo, conforme descrito na próxima seção. 5.2.1 Processamento de transações Monitoramento de transações: Prevemos duas abordagens diferentes para o FSS monitorar transações de usuário destinadas a um smart contract específico, diretas e baseadas em mempool: • Direto: A abordagem direta é conceitualmente mais simples, mas requer mudanças clientes usuários para que as transações sejam enviadas diretamente para o Oracle DescentralizadoNós da rede, em vez dos nós da cadeia principal. O DON coleta transações do usuário destinadas a um SC smart contract específico e as ordena com base em alguma política de pedidos. O DON então envia as transações solicitadas para o smart contract na cadeia principal. Alguns mecanismos de ordenação também requerem a abordagem direta porque o usuário que cria uma transação deve criptograficamente proteja-o antes de enviá-lo ao FSS. • Baseado em Mempool: Para facilitar a integração do FSS com clientes legados, o DON pode usar Mempool Services (MS) para monitorar o mempool da cadeia principal e coletar transações. A transmissão direta será provavelmente a implementação preferida para muitos contratos, e acreditamos que deveria ser bastante prático em muitos casos. Discutimos brevemente como os DApps existentes poderiam ser minimamente modificados para suportar transmissão direta, preservando uma boa experiência do usuário. Nós descrevemos abordagens usando Ethereum e MetaMask [6] já que essas são as escolhas mais populares hoje, mas as técnicas mencionadas devem se estender a outras redes e carteiras. Um Ethereum recente Proposta de Melhoria, “EIP-3085: Wallet add Ethereum método RPC de cadeia” [100], facilitará a segmentação de cadeias Ethereum personalizadas (usando um ID de CHAIN diferente do o do MAINCHAIN para evitar ataques de repetição) do MetaMask e outras carteiras baseadas em navegador. Após a implementação desta proposta, um DApp que pretenda utilizar um DON simplesmente adicionariam uma única chamada de método ao seu front-end para poder transmitir diretamente transações para qualquer DON expondo uma API compatível com Ethereum. Enquanto isso, “EIP-712: Ethereum dados estruturados digitados hashing e assinatura” [49] fornece um pouco alternativa mais envolvente, mas já amplamente implantada, onde um usuário DApp pode usar MetaMask para assinar dados estruturados especificando uma transação DON. O DApp pode enviar esses dados estruturados assinados para DON. Finalmente, notamos que abordagens híbridas também são possíveis. Por exemplo, legado os clientes podem continuar a enviar transações para o mempool da cadeia principal, mas transações (por exemplo, relatórios oracle) são enviadas diretamente para nós DON (em particular, o conjunto de nós que fornecem relatórios oracle, como atualizações de feed de preços e o conjunto de nós fornecimento do FSS pode sobrepor-se ou ser idêntico). Sequenciamento de transações: O principal objetivo do FSS é garantir que as transações dos usuários sejam ordenadas de acordo com uma política pré-definida. A natureza desta política irá dependem das necessidades do aplicativo e dos tipos de ordens de transação injustas que ele visa prevenir. Como o FSS no DON é capaz de processar dados e manter o estado local, eles podem impor uma política de sequenciamento arbitrária com base nas informações que são disponível em oracles. As políticas específicas de pedidos e sua implementação são discutidas posteriormente na Seção 5.3.Lançamento de transação: Após coletar e ordenar as transações dos usuários, recebidas diretamente dos usuários ou coletadas do mempool, o DON envia essas transações para a cadeia principal. Como tal, as interações de DON com a cadeia principal permanecem sujeito a ordens de transação (potencialmente injustas) regidas pelos mineradores da cadeia principal. Para aproveitar os benefícios da ordenação de transações descentralizadas, o alvo inteligente o contrato SC, portanto, deve ser projetado para tratar o DON como um cidadão de “primeira classe”. Nós distinguir duas abordagens: • Contratos somente DON: A opção de design mais simples é ter a cadeia principal inteligente o contrato SC aceita apenas transações que foram processadas pelo DON. Isto garante que smart contract processe transações na ordem proposta por o DON, mas de fato restringe o smart contract a operar em um sistema baseado em comitê (ou seja, o comitê DON agora tem poder contínuo para determinar o ordenação e inclusão de transações). • Contratos de classe dupla: um design preferencial e mais granular torna a cadeia principal inteligente contrato SC aceita transações originadas tanto de DON quanto de legado usuários,10 mas coloca “redutores de velocidade” tradicionais em transações que não foram processadas pelo DON. Por exemplo, as transações do DON podem ser processadas imediatamente, enquanto as transações legadas são “armazenadas em buffer” pelo smart contract para um período fixo de tempo. Outros mecanismos padrão para prevenir o front-running como esquemas de confirmação-revelação ou VDFs [53] também podem ser aplicados a legados transações. Isso garante que as transações solicitadas por DON sejam processadas em a ordem acordada, sem dar ao DON o poder indesejado de censurar transações. Como a imposição da ordenação de transações pelo FSS exige que as transações sejam agregadas “off-chain”, esta solução é naturalmente combinada com outras técnicas de agregação que visam reduzir os custos de processamento on-chain. Por exemplo, depois de coletar e ordenando transações, o DON pode enviar essas transações para a cadeia principal como um única “transação em lote” (por exemplo, um rollup), reduzindo assim a transação agregada taxa. Fazendo cumprir a ordem de transação: Seja em um design somente DON ou de classe dupla, a cadeia principal smart contract SC e DON devem ser co-projetadas para garantir que a ordem de transação de DON seja mantida. Aqui também, imaginamos diferentes opções de projeto: • Números de sequência: O DON pode anexar um número de sequência a cada transação e enviar essas transações para o mempool da cadeia principal. O principal 10Se o monitoramento de transações do DON for baseado no mempool, as transações legadas devem ser distinguíveis das transações DON para que não sejam coletadas pelo DON, por exemplo, por meio de uma tag especial incorporado na transação ou especificando um preço específico do gás, por ex. DON transações têm gás preços abaixo de um determinado limite.chain smart contract SC ignora transações que chegam “fora de sequência”. Nós observe que nesta configuração, os mineradores da cadeia principal podem decidir ignorar o DON ordenação de transações, fazendo com que as transações falhem. É possível, mantendo o estado (caro), que o SC imponha a ordem correta das transações, de certa forma de forma análoga a como o TCP armazena pacotes fora de ordem até que os pacotes perdidos sejam recebido. • Transação nonces: Para muitos blockchains, e em particular para Ethereum, o A abordagem de numeração de sequência acima pode aproveitar a transação integrada nonces para impor que o SC da cadeia principal smart contract processe as transações em sequência. Aqui, os nós DON enviam transações para a cadeia principal por meio de uma única conta da cadeia principal, protegida por uma chave compartilhada entre os nós DON. A conta a transação nonce garante que as transações sejam extraídas e processadas na ordem correta. • Transações agregadas: o DON pode agregar múltiplas transações em um rollup (ou em um pacote semelhante a rollup). A cadeia principal smart contract precisa ser projetado para lidar com essas transações agregadas. • Transações agregadas com um proxy da cadeia principal: aqui, o DON agrupa de forma semelhante as transações em uma “metatransação” para a cadeia principal, mas depende de um proxy personalizado smart contract para descompactar as transações e retransmiti-las para o contrato alvo SC. Esta técnica pode ser útil para compatibilidade herdada. As metatransações agem como rollups, mas diferem porque consistem em um arquivo não compactado lista de transações postadas uma vez na cadeia principal. O último design tem a vantagem de suportar perfeitamente as transações do usuário que eles próprios são procurados por meio de um contrato de cadeia principal antes de atingir a meta de DON contrato SC. Por exemplo, considere um usuário que envia uma transação para alguma carteira contrato, que por sua vez envia uma transação interna para SC. Atribuindo uma sequência número para tal transação seria complicado, a menos que o contrato da carteira do usuário seja especialmente projetado para encaminhar o número de sequência com cada transação interna para SC. Da mesma forma, tais transações internas não podem ser facilmente agregadas em uma metatransação enviada diretamente ao SC. Discutimos outras considerações de design para tais transações por procuração abaixo. 5.2.2 Atomicidade da transação Nossa discussão até agora assumiu implicitamente que as transações interagem com um único on-chain smart contract (por exemplo, um usuário envia uma solicitação de compra para uma exchange). Ainda assim, em sistemas como Ethereum, uma única transação pode consistir em múltiplas transações internas, por exemplo, uma smart contract chamando uma função em outro contrato. Abaixo, nós descrevem duas estratégias de alto nível para sequenciar transações “multicontratos”, enquanto preservando a atomicidade da transação (ou seja, a sequência de ações prescritas por as transações são todas executadas na ordem correta ou não são executadas).Atomicidade forte: A solução mais simples é aplicar o FSS, conforme descrito acima, diretamente a transações inteiras de “multicontratos”. Ou seja, os usuários enviam suas transações na rede e o FSS monitora, sequencia e publica essas transações no cadeia principal. Esta abordagem é tecnicamente simples, mas tem uma limitação potencial: se um usuário transação interage com dois contratos SC1 e SC2 que desejam alavancar serviços de sequenciação, então a política de sequenciação destes dois contratos tem de ser consistente. Isto é, dadas duas transações diferentes tx1 e tx2 com as quais cada uma interage tanto SC1 quanto SC2, não deve ser o caso de a política de SC1 ordenar tx1 antes de tx2 enquanto a política do SC2 prescreve a ordem oposta. Para a grande maioria dos cenários de interesse, prevemos que as políticas de sequenciamento adotadas por diferentes contratos serão consistentes. Por exemplo, SC1 e SC2 pode querer que as transações sejam ordenadas pela hora aproximada de chegada no mempool, e SC1 pode ainda querer que certos relatórios oracle sejam sempre entregues primeiro. Como o últimas oracle transações de relatório não interagem com SC2, as políticas são consistentes. Atomicidade fraca: Na sua total generalidade, o FSS poderia ser aplicado ao nível de indivíduos transações internas. Considere transações da forma tx = { ˜txpre, ˜txSC, ˜txpost}, consistindo em algumas transações iniciais transação(ões) ˜txpre, que resulta em uma transação interna ˜txSC para SC, que por sua vez emite transação(ões) interna(s) ˜txpost. A política de sequenciamento do SC pode determinar como a transação interna ˜txSC deve ser ordenada em relação a outras transações enviadas para SC, mas deixe em aberto a ordem de sequenciamento para ˜txpre e ˜txpost. Dadas as características intrínsecas do processamento de transações em sistemas como Ethereum, desenvolver um serviço de sequenciamento que vise transações internas específicas não é simples. Com um SC de contrato especialmente concebido, isto pode ser realizado da seguinte forma: 1. A transação tx é enviada para a rede e extraída (sem qualquer sequenciamento realizado pelo FSS). O ˜txpre inicial é executado e chama ˜txSC. 2. SC não executa ˜txSC e retorna. 3. O FSS monitora as transações internas do SC, sequencia-as e publica-as de volta para SC (ou seja, enviando transações ˜txSC diretamente para SC). 4. O SC processa as transações ˜txSC recebidas do FSS e emite as transações internas ˜txpost resultantes de ˜txSC. Com esta abordagem, as transações não são executadas totalmente atomicamente (ou seja, o original transação tx é dividida em várias transações na cadeia), mas a ordem de as transações internas são preservadas. Esta solução implica uma série de restrições de design. Por exemplo, ˜txpre não pode suponha que ˜txSC e ˜txpost serão executados. Além disso, o SC deve ser concebido de modo a executar transações ˜txSC e ˜txpost em nome de um determinado usuário, mesmo que tenham sidoenviado pelo FSS. Por estas razões, a solução de “Atomicidade Forte” de granulação mais grossa acima é provavelmente preferível na prática. Por respeitar dependências mais complexas, envolvendo múltiplas transações e suas respectivas transações internas, o escalonador de transações do FSS poderá conter funções elaboradas que se assemelham àquelas encontradas em gerenciadores de transações de relacionamentos gerenciadores de banco de dados. 5.3 Sequenciamento justo de transações Aqui discutimos duas noções de justiça para o sequenciamento de transações e as implementações correspondentes, que podem ser realizadas pelo FSS: justiça de ordem baseada em uma política imposto pelo FSS e preservação segura da causalidade, o que requer métodos criptográficos adicionais no FSS. Justiça da ordem: A justiça da ordem é uma noção de justiça temporal em protocolos de consenso que foi introduzido formalmente pela primeira vez por Kelkar et al. [144]. Kelkar et al. visam alcançar uma forma de política natural em que as transações sejam ordenados com base na hora em que foram recebidos pela primeira vez pelo DON (ou pela rede P2P, no caso de um FSS baseado em mempool). Num sistema descentralizado, no entanto, diferentes os nós podem ver as transações chegarem em uma ordem diferente. Estabelecendo uma ordem total em todas as transações é o próprio problema resolvido pelo protocolo de consenso subjacente MAINCHAIN. Kelkar et al. [144] introduz, portanto, uma noção mais fraca que pode ser alcançado com a ajuda de uma rede Oracle descentralizada, chamada “justiça de pedido em bloco”. Ele agrupa as transações que DON recebeu durante um intervalo de tempo em um “bloco” e insere todas as transações do bloco simultaneamente e na mesma posição (ou seja, altura) em MAINCHAIN. Eles são, portanto, ordenados juntos e devem ser executáveis paralelamente, sem criar conflitos entre eles. Grosso modo, orderfairness afirma que se uma grande fração de nós vê a transação τ1 antes de τ2, então τ1 será sequenciado antes ou no mesmo bloco que τ2. Ao impor uma atitude tão grosseira granularidade na ordem de transação, as oportunidades de ataques front-running e outros ataques relacionados a ordens são bastante reduzidas. Kelkar et al. propor uma família de protocolos chamada Aequitas [144], que aborda diferentes modelos de implantação, incluindo configurações de rede síncronas, parcialmente síncronas e assíncronas. Os protocolos Aequitas impõem uma sobrecarga de comunicação significativa em relação ao consenso BFT básico e, portanto, não são ideais para uso prático. Acreditamos, no entanto, que surgirão variantes práticas de Aequitas que poderão ser usadas para sequenciamento de transações no FSS e outras aplicações. Alguns esquemas relacionados já foram propostos que têm menos formalismo de acompanhamento e propriedades mais fracas, por exemplo, [36, 151, 236], mas melhor desempenho prático. Esses esquemas podem ser apoiados também no FSS. Também é importante notar que o termo “justiça” aparece em outras partes do blockchain literatura com um significado diferente, nomeadamente justiça no sentido de oportunidade paramineradores proporcionais aos seus recursos comprometidos [106, 181] ou para validators em termos de oportunidades iguais [153]. Preservação segura da causalidade: A abordagem mais conhecida para evitar frontrunning e outras violações de ordenação em plataformas distribuídas depende de criptografia. técnicas. Sua característica comum é ocultar os próprios dados da transação, aguardando até a ordem na camada de consenso foi estabelecida e para revelar os dados da transação posteriormente para processamento. Isso preserva a ordem causal entre as transações que são executado pelo blockchain. As noções de segurança relevantes e protocolos criptográficos foram desenvolvidos consideravelmente antes do advento de blockchains [71, 190]. As condições de segurança de “causalidade de entrada” [190] e “preservação segura da causalidade” [71, 97] exigem formalmente que nenhuma informação sobre uma transação se torne conhecida antes que a posição desta transação na ordem global tenha sido determinada. Um adversário não deve ser capaz de inferir qualquer informação até esse momento, de forma criptografada. sentido forte. Podem-se distinguir quatro técnicas criptográficas para preservar a causalidade: • Protocolos commit-reveal [29, 142, 145]: Em vez de uma transação ser anunciada claramente, apenas um compromisso criptográfico com a transação é transmitido. Depois que todas as transações confirmadas, mas ocultas, forem solicitadas (no início de blockchain sistemas no próprio MAINCHAIN, mas aqui pelo FSS), o remetente deve abrir o compromisso e revelar os dados da transação dentro de um intervalo de tempo pré-determinado. A rede então verifica se a abertura satisfaz o compromisso anterior. O as origens deste método datam de antes do advento de blockchains. Embora seja particularmente simples, a abordagem apresenta desvantagens consideráveis e não é fácil de utilizar por duas razões. Primeiro, como apenas o compromisso existe no nível do protocolo de pedido, a semântica da transação não pode ser validado durante o consenso. Uma viagem adicional de ida e volta ao cliente é necessário. Mais severamente, porém, pondera a possibilidade de que nenhuma abertura possa chegar, o que pode equivaler a um ataque de negação de serviço. Além disso, é difícil determinar se a abertura é válida de uma forma consistente e distribuída. maneira porque todos os participantes devem concordar se a abertura chegou em tempo. • Protocolos de confirmação-revelação com recuperação atrasada [145]: um desafio com o abordagem commit-reveal é que um cliente pode se comprometer com uma transação especulativamente e revelá-la mais tarde somente se as transações subsequentes a tornarem lucrativa. Um variante recente da abordagem de compromisso-revelação melhora a resiliência contra esta tipo de mau comportamento. Em particular, o protocolo TEX [145] aborda este problema usando uma abordagem inteligente em que as transações criptografadas incluem uma chave de descriptografia obtido calculando uma função de atraso verificável (VDF) [53, 221]. Se um cliente não conseguir descriptografar sua transação em tempo hábil, outras pessoas no sistema irão descriptografar em seu nome, resolvendo um quebra-cabeça criptográfico moderadamente difícil.• Criptografia de limite [71, 190]: Este método explora que o DON pode executar operações criptográficas de limite. Suponha que o FSS mantenha uma criptografia pública key pkO e os oracles compartilham a chave privada correspondente entre si. Os clientes então criptografam as transações sob pkO e as enviam para o FSS. Pedidos FSS transações no DON, então as descriptografa e finalmente as injeta em MAINCHAIN na ordem fixa. A criptografia, portanto, garante que o pedido seja não com base no conteúdo da transação, mas que os próprios dados estão disponíveis quando necessário. Este método foi originalmente proposto por Reiter e Birman [190] e posteriormente refinado por Cachin et al. [71], onde foi integrado com um consenso permitido protocolo. Trabalhos mais recentes exploraram o uso da criptografia de limite como mecanismo de nível de consenso para mensagens genéricas [33, 97] e para cálculos gerais com dados compartilhados [41]. Comparada aos protocolos de confirmação e revelação, a criptografia de limite evita ataques simples de negação de serviço (embora seja necessário cuidado, dado o custo computacional da descriptografia). Permite que o DON prossiga de forma autônoma, em sua própria velocidade e sem aguardando novas ações do cliente. As transações podem ser validadas imediatamente após terem sido descriptografadas. Além disso, os clientes criptografam todas as transações com um chave para DON e o padrão de comunicação permanece o mesmo que com outros transações. Gerenciando a chave de limite com segurança e com alteração de nós em O, no entanto, pode apresentar dificuldades adicionais. • Compartilhamento secreto confirmado [97]: em vez de criptografar os dados da transação em uma chave mantida por DON, o cliente também pode compartilhá-la secretamente para os nós em O. Usando um esquema de compartilhamento de segredos híbrido e computacionalmente seguro, a transação é criptografado primeiro usando uma cifra simétrica com uma chave aleatória. Apenas a chave simétrica correspondente é compartilhada e o texto cifrado é enviado para DON. O cliente deve enviar um compartilhamento de chave para cada nó em O usando uma mensagem criptografada separadamente. As etapas restantes do protocolo são as mesmas do limite criptografia, exceto que os dados da transação são descriptografados com o simétrico algoritmo após reconstruir a chave por transação a partir de seus compartilhamentos. Este método não requer configuração ou gerenciamento de um sistema criptográfico de chave pública associado ao DON. No entanto, os clientes devem estar cientes dos nós em O e comunicar num contexto seguro com cada um deles, o que coloca encargos adicionais para os clientes. Embora os métodos criptográficos ofereçam proteção completa contra informações vazando das transações enviadas para a rede, eles não ocultam metadados. Para por exemplo, um endereço IP ou um endereço Ethereum do remetente ainda pode ser usado por um adversário para realizar ataques frontais e outros. Vários recursos para melhorar a privacidade técnicas implantadas na camada de rede, por exemplo, [52, 95, 107], ou na camada de transação, por exemplo, [13, 65], seria necessário para atingir esse objetivo. O impacto de uma determinada peça de metadados, nomeadamente para qual contrato uma transação é enviada, podem ser (parcialmente) ocultadosatravés da multiplexação de muitos contratos no mesmo DON. Ocultação criptográfica de transações por si só também não impede a priorização de transações por DON nós em conluio com remetentes de transações. A causalidade segura garantida por protocolos criptográficos complementa as garantias de justiça da ordem para qualquer política, e pretendemos explorar uma combinação das duas métodos, onde isso for possível. Se um adversário não puder obter vantagem significativa observando metadados, os protocolos seguros de preservação de causalidade poderiam ser usados juntamente com uma abordagem de pedido ingênua também. Por exemplo, nós oracle podem gravar transações para L assim que os receberem, sem duplicação. As transações seriam então ordenados de acordo com sua aparência em L e posteriormente descriptografados. Também planejamos considerar o uso de TEEs como uma forma de ajudar a impor uma ordem justa; para Por exemplo, Tesseract [44] pode ser visto como alcançando uma forma de ordenação causal, mas um fortalecido pela capacidade do TEE de processar transações de forma explícita enquanto mantendo sua confidencialidade. 5.4 Considerações sobre a camada de rede Até agora, a nossa descrição do FSS centrou-se principalmente no problema de garantir que o a ordem finalizada das transações corresponde à ordem observada na rede. Doravante, consideramos questões de justiça que poderiam surgir na própria camada de rede. Os comerciantes de alta frequência em mercados eletrônicos convencionais investem consideráveis recursos para obter velocidade de rede superior [64], e os comerciantes em bolsas de criptomoedas exibem comportamento semelhante [90]. A velocidade da rede confere uma vantagem tanto em observar as transações de outras partes e na apresentação de transações concorrentes. Um remédio implantado na prática e popularizado no livro Flash Boys [155] é o “redutor de velocidade” introduzido inicialmente na bolsa IEX [128] e posteriormente em outras trocas [179] (com resultados mistos [19]). Este mecanismo impõe um atraso (350 microssegundos em IEX) no acesso ao mercado, com o objectivo de neutralizar vantagens no velocidade. Evidência empírica, por ex. [128], apoia sua eficácia na diminuição de certas negociações custos para investidores comuns. O FSS pode ser usado simplesmente para implementar um sistema assimétrico aumento de velocidade – aquele que atrasa as transações recebidas. Budish, Cramton e Shim [64] argumentam que a exploração das vantagens da velocidade é inevitável em mercados de tempo contínuo e defendem uma solução estrutural no forma de mercados baseados em leilões em lote. Mas esta abordagem não se consolidou amplamente em plataformas de negociação existentes. Os sistemas de negociação convencionais são centralizados, normalmente recebendo transações através de uma única conexão de rede. Num sistema descentralizado, pelo contrário, é possível observe a propagação da transação a partir de vários pontos de vista. Consequentemente, é possível observar comportamentos como inundação de rede em uma rede P2P. Nós pretendemos explorar abordagens de camada de rede para FSS que ajudem os desenvolvedores a especificar políticas proibindo tais comportamentos de rede indesejáveis.5.5 Políticas de justiça em nível de entidade A justiça da ordem e a causalidade segura visam impor uma ordem em transações que respeita o momento em que foram criados e submetidos pela primeira vez à rede. Uma limitação desta noção de justiça é que ela não impede ataques em que um adversário ganha vantagem ao inundar um sistema com muitas transações, uma estratégia observada em estado selvagem como uma forma de realizar sniping de transações eficaz em token vendas [159] e para criar congestionamento resultando na liquidação de posições de dívida colateralizada (CDPs) [48]. Em outras palavras, a justiça da ordem impõe justiça em relação às transações, não aos jogadores. Conforme mostrado no sistema CanDID [160], é possível usar ferramentas oracle como DECO ou Town Crier em conjunto com um comitê de nós (como um DON) para alcançar várias formas de resistência a Sybil, protegendo ao mesmo tempo a privacidade. Os usuários podem registrar identidades e fornecer evidências de sua singularidade sem revelar as próprias identidades. Credenciais resistentes a Sybil oferecem uma abordagem possível para enriquecer a ordem de transação políticas de uma forma que limitaria as oportunidades para ataques de inundação. Por exemplo, um A venda de token pode permitir apenas uma transação por usuário registrado, onde o registro exige uma prova da exclusividade de um identificador nacional, como um número de segurança social. Tal abordagem não é infalível, mas pode revelar-se uma política útil para mitigar ataques de inundação de transações.

The DON Transaction-Execution Framework

(DON-TEF) DONs will provide oracle and decentralized-resource support for layer-2 solutions within what we call the Decentralized Oracle Network Transaction-Execution Framework (DONTEF) or TEF for short. Today, the frequency of updates to DeFi contracts is limited by main chain latencies, e.g., the 10-15 second average block interval in Ethereum [104]—as well as the cost of pushing large amounts of data on chain and limited computational/tx throughput— motivating scaling approaches such as sharding [148, 158, 232] and layer-2 execution [5, 12, 121, 141, 169, 186, 187]. Even blockchains with much faster transaction times, e.g., [120], have proposed scaling strategies that involve oﬀ-chain computation [168]. TEF is meant to act as a layer-2 resource for any such layer-1 / MAINCHAIN systems. Using TEF, DONs can support faster updates in a MAINCHAIN contract while retaining the key trust assurances provided by the main chain. TEF can support any of a number of layer-2 execution techniques and paradigms, including rollups,11 optimistic rollups, Validium, etc., as well as a threshold trust model in which DON nodes execute transactions. The TEF is complementary to FSS and intended to support it. In other words, any application running in the TEF can use FSS. 11Often called “zk-rollups,” a misnomer, as they do not necessarily need zero-knowledge proofs.

6.1 TEF Overview The TEF is a design pattern for the construction and execution of a performant hybrid smart contract SC. In accordance with the main idea behind hybrid smart contracts, TEF involves a decomposition of SC into two pieces: (1) What we call in the TEF context an anchor contract SCa on MAINCHAIN and (2) DON logic exect that we call the TEF executable. We use SC here to denote the logical contract implemented by the combination of SCa and exect. (As noted above, we expect to develop compiler tools to decompose a contract SC automatically into these components.) The TEF executable exect is the engine that processes users’ transactions in SC. It can execute in a performant way, as it runs on the DON. It has several functions: • Transaction ingestion: exect receives or fetches users’ transactions. It can do so directly, i.e., through transaction submission on the DON, or via the MAINCHAIN mempool using MS. • Fast transaction execution: exect processes transactions involving assets within SC. It does so locally, i.e., on the DON. • Fast and low-cost oracle / adapter access: exect has native access to oracle reports and other adapter data leading to, e.g., faster, cheaper, and more accurate asset pricing than MAINCHAIN execution. Moreover, oﬀ-chain oracle access reduces the oracle’s operational cost, hence the cost of using the system, by avoiding expensive on-chain storage. • Syncing: exect periodically pushes updates from DON onto MAINCHAIN, updating SCa. The anchor contract is the MAINCHAIN front end of SC. As the higher-trust component of SC, it serves several purposes: • Asset custody: Users’ funds are deposited into, held in, and withdrawn from SCa. • Syncing veriﬁcation: SCa may verify the correctness of state updates when exect syncs, e.g., SNARKs attached to rollups. • Guard rails: SCa may include provisions to protect against corruption or failures in exect. (See Section 7 for more details.) In TEF, users’ funds are custodied on MAINCHAIN, meaning the DON is itself noncustodial. Depending on the choice of syncing mechanism (see below), users may need to trust the DON only for accurate oracle reports and timely syncing with MAINCHAIN. The resulting trust model is very similar to that for order-book-based DEXes, e.g., [2], which today generally include an oﬀ-chain component for order matching and an onchain component for clearing and settlement.

Transaction Execution Framework schematic showing mempool, clearing, and settlement flow

To use the vocabulary of payment systems, one may think of exect as the component of SC responsible for clearing, while SCa handles settlement. See Fig. 13 for a schematic depiction of TEF. Figure 13: TEF schematic. In this example, transactions pass through the mempool of MAINCHAIN via MS to the DON. TEF beneﬁts: TEF carries three main beneﬁts: • High performance: SC inherits the DON’s much higher throughput than MAINCHAIN for both transactions and oracle reports. Additionally, exect can process transactions faster and respond to oracle reports in a more timely way than an implementation on MAINCHAIN alone. • Lower fees: The process of syncing is less time-sensitive than transaction processing, and transactions can be sent from the DON to MAINCHAIN in batches. Consequently, the per-transaction on-chain fees (e.g., gas costs) with this approach are much lower than for a contract that runs only on MAINCHAIN. • Conﬁdentiality: The conﬁdentiality mechanisms of the DON can be brought to bear on SC.

TEF limitations: One limitation of TEF is that it does not support instantaneous withdrawals, as they occur only on MAINCHAIN: Upon sending a withdrawal request to SCa, a user may need to wait for exect to perform a state update that includes the withdrawal transaction before it can be approved. We discuss some partial remedies, however, in Section 6.2. Another limitation of TEF is that it does not support atomic composition of DeFi contracts on MAINCHAIN, speciﬁcally the ability to route assets through multiple DeFi contracts in a single transaction. TEF can, however, support such atomicity among DeFi contracts running on the same DON. We also discuss some ways to address this problem in Section 6.2. 6.2 Transaction Routing Transactions for SC can be sent by users directly to the DON or can be routed through the mempool in MAINCHAIN (via FSS). There are four distinct transaction types, each of which requires diﬀerent handling: Within-contract transactions: Because it sidesteps the complications of gas dynamics, TEF provides SC more ﬂexibility in its handling of transactions than would be available in a layer-1 contract. For example, while a mempool transaction in Ethereum can be overwritten by a fresh transaction with a higher gas price, SC can treat a transaction that operates on assets within SC as authoritative as soon as it becomes visible in the mempool. Consequently, SC need not wait for a transaction to be conﬁrmed within a block, resulting in considerably reduced latency. Proxying: A user may wish to send a transaction $\tau$ to SC via a wallet contract or other contract on MAINCHAIN. It is possible for the DON to simulate execution of $\tau$ on MAINCHAIN to determine whether it results in a follow-on transaction to SC. If so, $\tau$ can be sequenced with other transactions for SC that do. There are a few possibilities for how the DON identiﬁes such transactions: (1) The DON can simulate all transactions in the mempool (an expensive approach); (2) Certain contracts or contract types, e.g., wallets, can be listed for monitoring by the DON; or (3) Users can annotate transactions for DON inspection. Matters become more complicated when a single transaction interacts with two contracts, SC1 and SC2, both of which use Fair Sequencing Services and have incompatible ordering policies. The DON might, for example, sequence $\tau$ at the latest time that is compatible with both. Deposits: A transaction depositing a MAINCHAIN asset into SC needs to be conﬁrmed in a block before SC can treat it as valid. When it detects the mining of a transaction that sends assets (e.g., Ether) into SCa, exect can instantly conﬁrm the

deposit. For example, it can apply a current oracle-reported price on the DON to the asset. Withdrawals: As noted above, a limitation of TEF is that withdrawals cannot always be executed instantaneously. In a rollup-type execution model, the withdrawal request must be sequenced with other transactions, i.e., rolled up, in order to be safely processed. There are, however, some partial remedies to this limitation. If the DON can quickly compute a rollup validity proof up to the withdrawal transaction, then observing a user's transaction $\tau$ in the mempool exect can send a stateupdate transaction $\tau'$ for $\tau$ at a higher gas price, a kind of beneﬁcial front-running. Provided that $\tau$ isn't mined before $\tau'$ reaches the mempool, $\tau'$ will precede $\tau$, and $\tau$ will eﬀect an approved withdrawal. In a TEF variant where the DON is relied upon to compute state updates (see the threshold signing variant below), the DON can alternatively determine oﬀ-chain whether $\tau$ ought to be approved given the state of SC upon its execution. The DON can then send a transaction $\tau'$ that approves withdrawal $\tau$—without eﬀecting a full state update. If this approach isn’t possible, or in cases where it doesn’t succeed, a DON-initiated transaction $\tau'$ can send funds to the user in response to $\tau$ so that the user need not initiate an additional transaction. 6.3 Syncing The TEF executable exect periodically pushes updates from DON to MAINCHAIN, updating the state of SCa in a process we refer to as syncing. Syncing may be thought of as propagation of layer-2 transactions to layer-1, so TEF can draw on any of a number of existing techniques for this purpose, including rollups [5, 12, 16, 69], optimistic rollups [10, 11, 141], Validium [201], or basic threshold signing, e.g., threshold BLS, Schnorr, or ECDSA [24, 54, 116, 202]. In principle, trusted execution environments can also attest to the correctness of state changes, oﬀering a much more performant alternative to rollups, but with a hardware-dependent trust model. (See, e.g., [80].) Below we compare these syncing options with respect to three key properties in TEF: • Data availability: Where is the state of SC stored? At least three options are available in TEF: on the MAINCHAIN, on a DON, or by some third-party storage providers such as IPFS. They achieve diﬀerent security guarantees, availability levels, and performance proﬁles. Brieﬂy, storing state on the MAINCHAIN enables on-chain auditability and eliminates reliance on any party for state availability; on the other hand, storing state oﬀ-chain can reduce storage cost and improve throughput, at the cost of trusting storage providers (DON or third parties) for data availability. Of course, ﬂexible models that combine these options are also possible. We indicate the required form of data availability in Table 1.

• Correctness guarantees: How does SCa ascertain the correctness of the updates pushed by exect? This aﬀects the computational load on exect and SCa and the syncing latency (see below). • Latency: Syncing latency has three contributing factors: (1) The time taken for exect to generate a syncing transaction $\tau_{\text{sync}}$; (2) The time taken for $\tau_{\text{sync}}$ to be conﬁrmed on MAINCHAIN; and (3) The time for $\tau_{\text{sync}}$ to take eﬀect on SCa. In TEF, latency is particularly important for withdrawals (but less so for within-contract transactions) because withdrawals necessarily require an (at least partial) state sync. Syncing options Data availability Correctness guarantees Latency Rollup [5, 12, 16, 69] On-chain Validity proofs Time taken to generate validity proofs (e.g., minutes in current systems) Validium [201] Oﬀ-chain Validity proofs Same as above Optimistic rollup [10, 11, 141] On-chain Fraud proofs Length of the challenge period (e.g., days or weeks) Threshold signing [24, 54, 116, 202] Flexible Threshold signatures by DON Instantaneous Trusted execution environments [80] Flexible Hardware-based attestations Instantaneous Table 1: Various syncing options in TEF and their properties. Table 1 summarizes these properties in the ﬁve main syncing options in TEF. (Note that we do not intend to compare these technologies as standalone layer-2 scaling solutions. For that we refer readers to e.g., [121].) Now we discuss each syncing option. Rollups: A rollup [69] is a protocol in which the state transition eﬀected by a batch of transactions is computed oﬀ-chain. The state change is then propagated onto MAINCHAIN. To implement rollups, the anchor smart contract SCa stores a compact representation Rstate (e.g., a Merkle root) of the actual state. To sync, exect sends $\tau_{\text{sync}}$ = (T, R′ state) to SCa where T is the set of the transactions it processed since the last

sync and R′ state is the compact representation of the new state calculated by applying transactions in T to the previous state Rstate. There are two popular variants that diﬀer in how SCa veriﬁes state updates in $\tau_{\text{sync}}$. The ﬁrst, (zk-)rollups, attach a succinct argument of correctness, sometimes called a validity proof, for the transition Rstate →R′ state. To implement this variant, exect computes and submits the validity proof (e.g., a zk-SNARK proof) along with $\tau_{\text{sync}}$, proving that R′ state is the result of applying T to the current state of SCa. The anchor contract accepts the state update only after it has veriﬁed the proof. Optimistic rollups do not include arguments of correctness, but have staking and challenge procedures that facilitate distributed veriﬁcation of state transitions. For this rollup variant, SCa tentatively accepts $\tau_{\text{sync}}$ assuming it is correct (hence the optimism) but $\tau_{\text{sync}}$ does not take eﬀect until after a challenge period, during which any party monitoring MAINCHAIN can identify erroneous state updates and inform SCa to take necessary actions (e.g., to rollback the state and inﬂict a penalty on exect.) Both rollup variants achieve on-chain data availability, as transactions are posted on-chain, from which the full state can be constructed. The latency of zk-rollups is dominated by the time needed to generate validity proofs, which typically is on the order of minutes in existing systems [16] and will likely see improvements over time. Optimistic rollups, on the other hand, have a higher latency (e.g., days or weeks) because the challenge period needs to be long enough for fraud proofs to work. The implication of slow conﬁrmation is subtle and sometimes speciﬁc to the scheme, so that a thorough analysis is out of scope. For instance, certain schemes consider payment transactions as “trustless ﬁnal” [109] before the state update is conﬁrmed, since a regular user could verify a rollup much more quickly than the MAINCHAIN. Validium: Validium is a form of (zk-)rollup that makes data available oﬀ-chain only and does not maintain all data on MAINCHAIN. Speciﬁcally, exect sends only the new state and the proof but not transactions to SCa. With Validium-style syncing, exect and the DON that executes it are the only parties that store the complete state and that execute transactions. As with zk-rollups, syncing latency is dominated by validity proof generation time. Unlike zk-rollups, however, Validium style syncing reduces the storage cost and increases the throughput. Threshold signing by DON: Assuming a threshold of DON nodes is honest, a simple and fast syncing option is to have DON nodes collectively sign the new state. This approach can support both on-chain and oﬀ-chain data availability. Note that if users trust DON for oracle updates, they do not need to trust it more for accepting state updates, as they are already in a threshold trust model. Another beneﬁt of threshold signing is low latency. Support for new transaction signature formats as proposed in EIP-2938 [70] and known as account abstraction would make threshold signing considerably easier to implement, as it would eliminate the need for threshold ECDSA, which involves considerably more complex protocols (e.g., [116, 117, 118])

than alternatives such as threshold Schnorr [202] or BLS [55] signatures. Trusted Execution Environments (TEEs): TEEs are isolated execution environments (usually realized by hardware) that aim to provide strong security protections for programs running inside. Some TEEs (e.g., Intel SGX [84]) can produce proofs, known as attestations, that an output is correctly computed by a speciﬁc program for a particular input12. A TEE-based variant of TEF syncing can be implemented by replacing proofs in (zk-)rollups or Validium with TEE attestations using techniques from [80]. Compared to zero-knowledge proofs used in rollups and Validium, TEEs are much more performant. Compared to threshold signing, TEEs remove the complexity of generating threshold ECDSA signatures as there need in principle be only one TEE involved. Using TEEs does, however, introduce extra hardware-dependent trust assumptions. One can also combine TEEs with threshold signing to create resilience against compromise of a fraction of TEE instances, although this protective measure reintroduces the complexity of generating threshold ECDSA signatures. Additional ﬂexibility: These syncing options can be reﬁned to provide more ﬂexibility in the following ways. • Flexible triggering: TEF application can determine the conditions under which syncing is triggered. For example, syncing can be batch-based, e.g., occur after every N transactions, time-based, e.g., every 10 blocks, or event-based, e.g., occur whenever target asset prices move signiﬁcantly. • Partial syncing: It is possible and in some cases desirable (e.g., with rollups, partial syncing can reduce latency) for exect to provide fast syncing of small amounts of state, performing full syncing perhaps only periodically. For example, exect can approve a withdrawal request by updating a user’s balance in SCa without otherwise updating MAINCHAIN state. 6.4 Reorgs Blockchain reorganizations resulting from network instability or even from 51%-attacks can pose a threat to the integrity of a main chain. In practice, adversaries have used them to mount double-spending attacks [34]. While such attacks on major chains are challenging to mount, they remain feasible for some chains [88]. Because it operates independently of MAINCHAIN, a DON oﬀers the interesting possibility of observing and providing some protections against reorgs associated with attacks. For example, a DON can report to a relying contract SC on MAINCHAIN the existence of a competing fork of some threshold length $\tau$. The DON can additionally 12Supplementary details can be found in Appendix B.2.1. They are not required for understanding.

provide proof—in either a PoW or PoS setting—of the existence of such a fork. The contract SC can implement suitable defensive actions, such as suspending further transaction execution for a period of time (e.g., to allow exchanges to blacklist double-spent assets). Note that although an adversary mounting a 51%-attack can seek to censor reports from a DON, a countermeasure in SC is to require periodic reports from the DON in order to process transactions (i.e., a heartbeat) or to require a fresh report to validate a high-value transaction. While such forking alerts are in principle a general service the DON can provide for any of a number of purposes, our plan is to incorporate them with the TEF.

A estrutura de execução de transações DON

(DON-TEF) DONs fornecerão oracle e suporte de recursos descentralizados para soluções de camada 2 dentro o que chamamos de Estrutura Descentralizada de Execução de Transações da Oracle Network (DONTEF) ou TEF, para abreviar. Hoje, a frequência de atualizações dos contratos DeFi é limitada pelas latências da cadeia principal, por exemplo, o intervalo médio de bloqueio de 10 a 15 segundos em Ethereum [104] - bem como o custo de enviar grandes quantidades de dados em cadeia e taxa de transferência computacional/tx limitada - motivando abordagens de escalonamento, como fragmentação [148, 158, 232] e execução da camada 2 [5, 12, 121, 141, 169, 186, 187]. Mesmo blockchains com tempos de transação muito mais rápidos, por exemplo, [120], propuseram estratégias de escalonamento que envolvem computação fora da cadeia [168]. O TEF destina-se a atuar como um recurso de camada 2 para qualquer sistema de camada 1/MAINCHAIN. Usando TEF, DONs podem suportar atualizações mais rápidas em um contrato MAINCHAIN enquanto mantendo as principais garantias de confiança fornecidas pela cadeia principal. TEF pode apoiar qualquer uma de uma série de técnicas e paradigmas de execução da camada 2, incluindo rollups,11 rollups otimistas, Validium, etc., bem como um modelo de confiança de limite no qual DON nós executam transações. O TEF é complementar ao FSS e destina-se a apoiá-lo. Em outras palavras, qualquer aplicação em execução no TEF pode usar FSS. 11Frequentemente chamados de “zk-rollups”, um nome impróprio, pois não precisam necessariamente de provas de conhecimento zero.

Transaction Execution Framework schematic showing mempool, clearing, and settlement flow

6.1 Visão geral do TEF O TEF é um padrão de projeto para a construção e execução de um híbrido de alto desempenho smart contractSC. De acordo com a ideia principal por trás dos smart contracts híbridos, o TEF envolve um decomposição de SC em duas partes: (1) O que chamamos no contexto TEF de âncora contrato SCa em MAINCHAIN e (2) lógica DON executada que chamamos de executável TEF. Usamos SC aqui para denotar o contrato lógico implementado pela combinação de SCa e executar. (Como observado acima, esperamos desenvolver ferramentas de compilação para decompor um contrate SC automaticamente nesses componentes.) O executável TEF exec é o mecanismo que processa as transações dos usuários no SC. Isso pode ser executado com bom desempenho, pois é executado no DON. Possui diversas funções: • Ingestão de transações: exec recebe ou busca as transações dos usuários. Isso pode acontecer diretamente, ou seja, através do envio da transação no DON, ou através do MAINCHAIN mempool usando MS. • Execução rápida de transações: o exec processa transações envolvendo ativos dentro SC. Isso é feito localmente, ou seja, no DON. • Acesso rápido e de baixo custo oracle / adaptador: exec tem acesso nativo a relatórios oracle e outros dados do adaptador que levam, por exemplo, a dados de ativos mais rápidos, mais baratos e mais precisos preços do que a execução MAINCHAIN. Além disso, o acesso oracle fora da cadeia reduz o custo operacional do oracle, daí o custo de utilização do sistema, evitando armazenamento caro na cadeia. • Sincronização: exec envia periodicamente atualizações de DON para MAINCHAIN, atualizando SCa. O contrato âncora é o front end MAINCHAIN do SC. Como componente de maior confiança do SC, ele serve a vários propósitos: • Custódia de ativos: os fundos dos usuários são depositados, mantidos e retirados da SCa. • Verificação de sincronização: o SCa pode verificar a exatidão das atualizações de estado quando executado sincroniza, por exemplo, SNARKs anexados a rollups. • Guarda-corpos: SCa pode incluir disposições para proteção contra corrupção ou falhas na verdade. (Veja a Seção 7 para mais detalhes.) No TEF, os fundos dos usuários são custodiados na MAINCHAIN, o que significa que o próprio DON não tem custódia. Dependendo da escolha do mecanismo de sincronização (veja abaixo), os usuários podem precisar confiar em DON apenas para relatórios oracle precisos e sincronização oportuna com MAINCHAIN. O modelo de confiança resultante é muito semelhante àquele para DEXes baseados em carteira de pedidos, por exemplo, [2], que hoje geralmente incluem um componente fora da cadeia para correspondência de pedidos e um componente onchain para compensação e liquidação.Para usar o vocabulário dos sistemas de pagamento, pode-se pensar em exec como o componente do SC responsável pela compensação, enquanto o SCa trata da liquidação. Veja a Fig. 13 para um esquema representação do TEF. Figura 13: Esquema TEF. Neste exemplo, as transações passam pelo mempool de MAINCHAIN via MS para DON. Benefícios do TEF: O TEF traz três benefícios principais: • Alto desempenho: SC herda o rendimento muito maior do DON do que o MAINCHAIN para transações e relatórios oracle. Além disso, o exec pode processar transações mais rapidamente e responder aos relatórios oracle em tempo hábil do que uma implementação apenas no MAINCHAIN. • Taxas mais baixas: O processo de sincronização é menos urgente do que o processamento de transações, e as transações podem ser enviadas de DON para MAINCHAIN em lotes. Consequentemente, as taxas por transação na cadeia (por exemplo, custos de gás) com esta abordagem são muito mais baixas do que para um contrato executado apenas em MAINCHAIN. • Confidencialidade: Os mecanismos de confidencialidade do DON podem ser trazidos para aguenta SC.

Limitações do TEF: Uma limitação do TEF é que ele não suporta saques, pois ocorrem apenas na MAINCHAIN: Ao enviar uma solicitação de saque para SCa, um usuário pode precisar esperar que exec execute uma atualização de estado que inclua o transação de retirada antes que ela possa ser aprovada. Discutimos algumas soluções parciais, no entanto, na Seção 6.2. Outra limitação do TEF é que ele não suporta composição atômica de DeFi contratos no MAINCHAIN, especificamente a capacidade de rotear ativos através de múltiplos DeFi contratos em uma única transação. O TEF pode, no entanto, apoiar tal atomicidade entre DeFi contratos em execução no mesmo DON. Também discutimos algumas maneiras de resolver isso problema na Seção 6.2. 6.2 Roteamento de transações As transações para SC podem ser enviadas pelos usuários diretamente para DON ou podem ser roteadas através o mempool em MAINCHAIN (via FSS). Existem quatro tipos de transação distintos, cada um dos quais requer tratamento diferente: Transações dentro do contrato: Por evitar as complicações da dinâmica dos gases, o TEF proporciona ao SC mais flexibilidade no tratamento das transações do que seria disponível em um contrato de camada 1. Por exemplo, enquanto uma transação mempool em Ethereum pode ser substituída por uma nova transação com um preço de gás mais alto, o SC pode tratar uma transação que opere em ativos dentro do SC como oficial assim que se tornar visível no pool de membros. Consequentemente, o SC não precisa esperar que uma transação seja confirmada dentro de um bloco, resultando em latência consideravelmente reduzida. Proxy: Um usuário pode desejar enviar uma transação τ para SC através de um contrato de carteira ou outro contrato em MAINCHAIN. É possível que o DON simule a execução de τ em MAINCHAIN para determinar se isso resulta em uma transação subsequente para SC. Nesse caso, τ pode ser sequenciado com outras transações para SC que o façam. Existem alguns possibilidades de como o DON identifica tais transações: (1) O DON pode simular todas as transações no mempool (uma abordagem cara); (2) Certos contratos ou tipos de contratos, por exemplo, carteiras, podem ser listados para monitoramento pelo DON; ou (3) os usuários podem anote transações para inspeção DON. As coisas ficam mais complicadas quando uma única transação interage com duas contratos, SC1 e SC2, ambos os quais usam serviços de sequenciamento justo e têm políticas de pedidos incompatíveis. O DON pode, por exemplo, sequenciar τ no último momento que é compatível com ambos. Depósitos: Uma transação que deposita um ativo MAINCHAIN em SC precisa ser confirmada em um bloco antes que SC possa tratá-la como válida. Quando detecta a mineração de um transação que envia ativos (por exemplo, Ether) para SCa, o executivo pode confirmar instantaneamente adepósito. Por exemplo, ele pode aplicar um preço atual relatado por oracle no DON ao ativo. Retiradas: Conforme observado acima, uma limitação do TEF é que os saques nem sempre podem ser executados instantaneamente. Em um modelo de execução do tipo rollup, a retirada a solicitação deve ser sequenciada com outras transações, ou seja, acumulada, para ser segura processado. Existem, no entanto, algumas soluções parciais para esta limitação. Se DON puder calcular rapidamente uma prova de validade de rollup até a transação de retirada, então observar a transação de um usuário τ no mempool exec pode enviar uma transação de atualização de estado τ ′ para τ a um preço de gás mais alto, uma espécie de front-running benéfico. Desde que τ não seja extraído antes de τ ′ atingir o mempool, τ ′ precederá τ e τ efetuará uma retirada aprovada. Em uma variante TEF onde o DON é utilizado para calcular atualizações de estado (consulte a variante de assinatura de limite abaixo), o DON pode alternativamente determinar fora da cadeia se τ deve ser aprovado dado o estado de SC no momento de sua execução. O DON pode então enviar uma transação τ ′ que aprova a retirada τ - sem efetuar uma transação completa atualização do estado. Se esta abordagem não for possível, ou nos casos em que não for bem-sucedida, um procedimento iniciado por DON a transação τ ′ pode enviar fundos ao usuário em resposta a τ para que o usuário não precise iniciar uma transação adicional. 6.3 Sincronizando O executável TEF exec envia periodicamente atualizações de DON para MAINCHAIN, atualizar o estado do SCa em um processo que chamamos de sincronização. A sincronização pode ser pensada como propagação de transações da camada 2 para a camada 1, então o TEF pode recorrer a qualquer número de técnicas existentes para este fim, incluindo rollups [5, 12, 16, 69], otimista rollups [10, 11, 141], Validium [201] ou assinatura de limite básico, por exemplo, limite BLS, Schnorr ou ECDSA [24, 54, 116, 202]. Em princípio, ambientes de execução confiáveis também pode atestar a correção das mudanças de estado, oferecendo um desempenho muito melhor alternativa a rollups, mas com um modelo de confiança dependente de hardware. (Veja, por exemplo, [80].) Abaixo comparamos essas opções de sincronização em relação a três propriedades principais em TEF: • Disponibilidade de dados: Onde é armazenado o estado de SC? Pelo menos três opções são disponível em TEF: no MAINCHAIN, em DON ou por algum armazenamento de terceiros provedores como IPFS. Eles alcançam diferentes garantias de segurança, disponibilidade níveis e perfis de desempenho. Resumidamente, armazenar o estado no MAINCHAIN permite auditabilidade na cadeia e elimina a dependência de qualquer parte para disponibilidade do estado; por outro lado, armazenar o estado off-chain pode reduzir o custo de armazenamento e melhorar taxa de transferência, ao custo de provedores de armazenamento confiáveis (DON ou terceiros) para disponibilidade de dados. É claro que modelos flexíveis que combinam estas opções também são possível. Indicamos a forma necessária de disponibilização dos dados na Tabela 1.• Garantias de correção: como a SCa verifica a exatidão das atualizações empurrado por exec? Isso afeta a carga computacional em exec e SCa e o latência de sincronização (veja abaixo). • Latência: a latência de sincronização tem três fatores contribuintes: (1) O tempo necessário para esperar gerar uma transação de sincronização τsync; (2) O tempo necessário para τsync a ser confirmado no MAINCHAIN; e (3) O tempo para τsync entrar em vigor SCa. No TEF, a latência é particularmente importante para retiradas (mas menos importante para transações dentro do contrato) porque as retiradas exigem necessariamente um (pelo menos parcial) sincronização de estado. Sincronizando opções Dados disponibilidade Correção garantias Latência Acúmulo [5, 12, 16, 69] Na rede Provas de validade Tempo necessário para gerar provas de validade (por exemplo, minutos nos sistemas atuais) Válido [201] Fora da cadeia Provas de validade Igual ao acima Otimista rollup [10, 11, 141] Na rede Provas de fraude Duração do desafio período (por exemplo, dias ou semanas) Assinatura de limite [24, 54, 116, 202] Flexível Limite de assinaturas por DON Instantâneo Ambientes de execução confiáveis [80] Flexível Baseado em hardware atestados Instantâneo Tabela 1: Várias opções de sincronização no TEF e suas propriedades. A Tabela 1 resume essas propriedades nas cinco principais opções de sincronização no TEF. (Nota que não pretendemos comparar essas tecnologias como escalonamento de camada 2 independente soluções. Para isso, recomendamos aos leitores, por exemplo, [121].) Agora discutimos cada opção de sincronização. Acumulações: Um rollup [69] é um protocolo no qual a transição de estado efetuada por um lote de transações é computado fora da cadeia. A mudança de estado é então propagada para MAINCHAIN. Para implementar rollups, a âncora smart contract SCa armazena uma representação compacta Rstate (por exemplo, uma raiz Merkle) do estado real. Para sincronizar, exec envia τsync = (T, R′ estado) para SCa onde T é o conjunto de transações processadas desde o últimosincronizar e R′ estado é a representação compacta do novo estado calculado aplicando transações em T para o estado anterior Rstate. Existem duas variantes populares que diferem na forma como o SCa verifica as atualizações de estado no τsync. Os primeiros, (zk-)rollups, anexam um argumento sucinto de correção, às vezes chamado uma prova de validade, para a transição Rstate →R′ estado. Para implementar esta variante, execute calcula e envia a prova de validade (por exemplo, uma prova zk-SNARK) junto com τsync, provando que R' state é o resultado da aplicação de T ao estado atual de SCa. A âncora contrato aceita a atualização do estado somente após ter verificado a comprovação. rollups otimistas não incluem argumentos de correção, mas têm staking e desafiar procedimentos que facilitam a verificação distribuída de transições de estado. Para isso Variante rollup, SCa aceita provisoriamente τsync assumindo que está correto (daí o otimismo) mas τsync não entra em vigor até depois de um período de desafio, durante o qual qualquer parte monitorar MAINCHAIN pode identificar atualizações de estado errôneas e informar a SCa para tomar ações necessárias (por exemplo, reverter o estado e infligir uma penalidade na execução). Ambas as variantes rollup alcançam disponibilidade de dados na cadeia, à medida que as transações são publicadas on-chain, a partir do qual o estado completo pode ser construído. A latência de zk-rollups é dominado pelo tempo necessário para gerar provas de validade, que normalmente está no ordem de minutos em sistemas existentes [16] e provavelmente verá melhorias ao longo do tempo. rollups otimistas, por outro lado, têm uma latência maior (por exemplo, dias ou semanas) porque o período de desafio precisa ser longo o suficiente para que as provas de fraude funcionem. O A implicação da confirmação lenta é sutil e às vezes específica do esquema, de modo que uma análise completa está fora do escopo. Por exemplo, certos regimes consideram o pagamento transações como “trustless final” [109] antes da atualização do estado ser confirmada, uma vez que um um usuário comum poderia verificar um rollup muito mais rapidamente do que o MAINCHAIN. Valídio: Validium é uma forma de (zk-)rollup que disponibiliza dados apenas fora da cadeia e não mantém todos os dados no MAINCHAIN. Especificamente, exec envia apenas o novo estado e a prova, mas não transações para SCa. Com sincronização estilo Validium, exceto e o DON que o executa são as únicas partes que armazenam o estado completo e que executam transações. Tal como acontece com zk-rollups, a latência de sincronização é dominada pela validade tempo de geração da prova. Ao contrário de zk-rollups, no entanto, a sincronização no estilo Validium reduz o custo de armazenamento e aumenta o rendimento. Assinatura de limite por DON: Supondo que um limite de nós DON seja honesto, um A opção de sincronização simples e rápida é fazer com que os nós DON assinem coletivamente o novo estado. Esta abordagem pode apoiar a disponibilidade de dados dentro e fora da cadeia. Observe que se os usuários confiam em DON para atualizações de oracle, eles não precisam confiar mais nele para aceitar atualizações de estado, pois já estão em um modelo de confiança de limite. Outro benefício a assinatura de limite é de baixa latência. Suporte para novos formatos de assinatura de transação como proposto em EIP-2938 [70] e conhecido como abstração de conta tornaria o limite assinatura consideravelmente mais fácil de implementar, pois eliminaria a necessidade de limites ECDSA, que envolve protocolos consideravelmente mais complexos (por exemplo, [116, 117, 118])do que alternativas como assinaturas de limite Schnorr [202] ou BLS [55]. Ambientes de execução confiáveis (TEEs): TEEs são ambientes de execução isolados (geralmente realizados por hardware) que visam fornecer fortes proteções de segurança para programas executados internamente. Alguns TEEs (por exemplo, Intel SGX [84]) podem produzir provas, conhecidos como atestados, que uma saída é calculada corretamente por um programa específico para uma determinada entrada12. Uma variante de sincronização TEF baseada em TEE pode ser implementada por substituindo provas em (zk-)rollups ou Validium por atestados TEE usando técnicas de [80]. Comparados às provas de conhecimento zero usadas em rollups e Validium, os TEEs são muito mais desempenho. Em comparação com a assinatura de limite, os TEEs eliminam a complexidade de gerar assinaturas ECDSA de limite, pois, em princípio, é necessário haver apenas um TEE envolvido. O uso de TEEs, entretanto, introduz suposições extras de confiança dependentes de hardware. Também é possível combinar TEEs com sinalização de limite para criar resiliência contra o comprometimento de uma fração das instâncias de TEE, embora esta medida de proteção reintroduz a complexidade de geração de assinaturas ECDSA de limite. Flexibilidade adicional: Essas opções de sincronização podem ser refinadas para fornecer mais flexibilidade das seguintes maneiras. • Acionamento flexível: a aplicação TEF pode determinar as condições sob as quais a sincronização é acionada. Por exemplo, a sincronização pode ser baseada em lote, por exemplo, ocorrer após a cada N transações, baseadas no tempo, por exemplo, a cada 10 blocos, ou baseadas em eventos, por exemplo, ocorrem sempre que os preços-alvo dos activos se movem significativamente. • Sincronização parcial: é possível e em alguns casos desejável (por exemplo, com rollups, a sincronização parcial pode reduzir a latência) para fornecer sincronização rápida de pequenos quantidades de estado, realizando sincronização completa talvez apenas periodicamente. Por exemplo, exec pode aprovar uma solicitação de saque atualizando o saldo de um usuário no SCa sem atualizar o estado MAINCHAIN. 6.4 Reorganizações Reorganizações de blockchain resultantes de instabilidade de rede ou mesmo de ataques de 51% pode representar uma ameaça à integridade de uma cadeia principal. Na prática, os adversários têm usado para que eles montem ataques de gastos duplos [34]. Embora tais ataques às principais cadeias sejam difíceis de montar, eles permanecem viáveis para algumas cadeias [88]. Por operar independentemente do MAINCHAIN, um DON oferece a interessante possibilidade de observar e fornecer algumas proteções contra reorganizações associadas a ataques. Por exemplo, um DON pode reportar a um contrato SC confiável em MAINCHAIN a existência de uma bifurcação concorrente de algum comprimento limite τ. O DON pode adicionalmente 12Detalhes complementares podem ser encontrados no Apêndice B.2.1. Eles não são necessários para a compreensão.

fornecer prova – em uma configuração PoW ou PoS – da existência de tal bifurcação. O O contrato SC pode implementar ações defensivas adequadas, como suspender a execução de transações adicionais por um período de tempo (por exemplo, para permitir que as exchanges coloquem na lista negra os gastos duplos ativos). Observe que embora um adversário que realize um ataque de 51% possa tentar censurar relatórios de um DON, uma contramedida em SC é exigir relatórios periódicos do DON para processar transações (ou seja, uma pulsação) ou para exigir um novo relatório para validar uma transação de alto valor. Embora esses alertas de bifurcação sejam, em princípio, um serviço geral, o DON pode fornecer para uma série de finalidades, nosso plano é incorporá-las ao TEF.

Trust Minimization

As a decentralized system with participation from a heterogeneous set of entities, the Chainlink network provides strong protection against failures in both liveness (availability) and safety (report integrity). Most decentralized systems, however, vary in the degree to which their constituent components are themselves decentralized. This is true even of large systems, where limited decentralization among miners [32] and intermediaries [51] has long been present. The goal of any decentralization eﬀort is trust minimization: We seek to reduce the adverse eﬀects of systemic corruption or failure within the Chainlink network, even that due to a malicious DON. Our guiding principle is the Principle of Least Privilege [197]. System components and actors within the system should have privileges strictly scoped to allow only for the successful completion of their assigned roles. Here we lay out several concrete mechanisms for Chainlink to adopt in its drive toward ever-greater trust minimization. We characterize these mechanisms in terms of the loci, i.e., system components, in which they are rooted, shown in Fig. 14. We address each locus in a respective subsection. 7.1 Data-Source Authentication Current operating models for oracles are constrained by the fact that few data sources digitally sign the data they omit, in large part because TLS does not natively sign data. TLS does make use of digital signatures in its “handshake” protocol (to establish a shared key between a server and client). HTTPS-enabled servers thus have certiﬁcates on public keys that can in principle serve to sign data, but they do not generally use these certiﬁcates to support data signing. Consequently, the security of a DON, as in today’s oracle networks, relies on oracle nodes faithfully relaying data from a data source to a contract. An important long-term component of our vision for trust minimization in Chainlink involves stronger data-source authentication through support of tools and standards for data signing. Data signing can help enforce end-to-end integrity guarantees. In principle, if a contract accepts as input a piece of data D signed directly by a data

Loci of trust-minimizing mechanisms in the Chainlink network showing data quality, node selection, and oracle report verification

Figure 14: Loci of trust-minimizing mechanisms discussed in this section. 1⃝Data sources provide data to the 2⃝DON, which relays a function of the data to a dependent 3⃝smart contract. Additionally, the DON or the oracle network includes 4⃝node management smart contracts on MAINCHAIN for, e.g., compensating nodes, guard rails, and so forth. source, then the oracle network cannot feasibly tamper with D. Various encouraging eﬀorts to enable such signing of data have emerged, including OpenID Connect, which is designed primarily for user authentication [9], TLS-N, an academic project aiming to extend TLS [191] by repurposing TLS certiﬁcates, and TLS Evidence Extensions [63]. While OpenID Connect has seen some adoption, however, TLS Evidence Extensions and TLS-N have yet to see adoption. Another potential avenue of data-source authentication is to use publishers’ own Signed HTTP Exchanges (SXG) [230], which they can cache on content-delivery networks as part of the Accelerated Mobile Pages (AMP) protocol [225]. The Chrome mobile browser displays the content from AMP-cached SXGs as if they were served from their publishers’ own network domains instead of the cache-server domain. This branding incentive, coupled with the relative ease of enabling it using services like CloudFlare’s Real URL [83] and Google’s amppackager [124], may lead to widespread adoption of SXGs in cached news content, which would enable a simple, tamper-resistant way for Chainlink oracles to trigger on newsworthy events reported in valid SXGs. While AMP-cached SXGs from news publishers would not be useful for high-tempo applications like reports on trading data, they could be a secure source for custom contracts pertaining to real-world events like extreme weather or election outcomes. We believe that simple deployment, mature tools, and ﬂexibility will be vital to accelerating data-source signing. Enabling data providers to use Chainlink nodes as an authenticated API front end seems a promising approach. We intend to create an

option for nodes to function in this mode, with or without participation in the network as a full-blown oracle. We refer to this capability as authenticated data origination (ADO). By using Chainlink nodes with ADO, data sources will be able to beneﬁt from the experience and tools developed by the Chainlink community in adding digital signing capabilities to their existing suite of oﬀ-chain APIs. Should they choose to run their nodes as oracles, they can additionally open up potential new revenue streams under the same model as existing data providers, e.g., Kraken [28], Kaiko [140], and others, that run Chainlink nodes to sell API data on chain. 7.1.1 The Limitations of Authenticated Data Origination Digital signing by data sources, while it can help strengthen authentication, isn’t sufﬁcient per se to accomplish all of the natural security or operational goals of an oracle network. To begin with, a given piece of data D must still be relayed in a robust and timely way from a data source to smart contract or other data consumer. That is, even in an ideal setting in which all data is signed using keys pre-programmed into dependent contracts, a DON would still be needed to communicate the data reliably from sources to contracts. Additionally, there are a number of cases in which contracts or other oracle-data consumers want access to authenticated output of various functions computed over source data for two main reasons: • Conﬁdentiality: A data source API may provide sensitive or proprietary data that needs to be redacted or sanitized before it is made publicly visible on chain. Any modiﬁcation to signed data, however, invalidated the signature. Put another way, na¨ıve ADO and data sanitization are incompatible. We show in Example 3 how the two can be reconciled through an enhanced form of ADO. • Data source faults: Both errors and failures can aﬀect data sources, and digital signatures address neither problem. From its inception [98], Chainlink has already included a mechanism to remediate such faults: redundancy. The reports issued by oracle networks typically represent the combined data of multiple sources. We now discuss schemes we are exploring in the ADO setting to enhance the conﬁdentiality of source data and to combine data from multiple sources securely. 7.1.2 Conﬁdentiality Data sources may not anticipate and make available the full gamut of APIs desired by users. Speciﬁcally, users may wish to access pre-processed data to help ensure conﬁdentiality. The following example illustrates the problem.

Example 3. Alice wishes to obtain a decentralized identity (DID) credential stating that she is over 18 years of age (and thus can, for instance, take out a loan). To do so, she needs to prove this fact about her age to a DID credential issuer. Alice hopes to use data from her state’s Department of Motor Vehicles (DMV) website for the purpose. The DMV has a record of her birthdate and will emit a digitally signed attestation A on it of the following form: A = {Name: Alice, DoB: 02/16/1999}. In this example, the attestation A may be suﬃcient for Alice to prove to the DID credential issuer that she’s over 18. But it needlessly leaks sensitive information: Alice’s exact DoB. Ideally, what Alice would like from the DMV instead is a signature on a simple statement A′ that “Alice is over 18 years of age.” In other words, she wants the output of a function G on her birthdate X, where (informally), A′ = G(X) = True if CurrentDate −X ≥18 years; otherwise, G(X) = False. To generalize, Alice would like to be able to request from the data source a signed attestation A′ of the form: A′ = {Name: Alice, Func:G(X), Result: True}, where G(X) denotes a speciﬁcation of a function G and its input(s) X. We envision that a user should be able to provide a desired G(X) as input with her request for a corresponding attestation A′. Note that the data source’s attestation A′ must include the speciﬁcation G(X) to ensure that A′ is correctly interpreted. In the above example, G(X) deﬁnes the meaning of the Boolean value in A′ and thus that True signiﬁes the subject of the attestation is over 18 years of age. We refer to ﬂexible queries in which a user can specify G(X) as functional queries. In order to support use cases like that in Example 3, as well as those involving queries directly from contracts, we intend to include support for functional queries involving simple functions G as part of ADO. 7.1.3 Combining Source Data To reduce on-chain costs, contracts are generally designed to consume combined data from multiple sources, as illustrated in the following example. Example 4 (Medianizing price data). To provide a price feed, i.e., the value of one asset (e.g., ETH) with respect to another (e.g., USD), an oracle network will generally obtain current prices from a number of sources, such as exchanges. The oracle network typically sends to a dependent contract SC the median of these values. In an environment with data signing, a correctly functioning oracle network obtains from data sources $S = \{S_1, \ldots, S_{n_S}\}$ a sequence of values $V = \{v_1, v_2, \ldots, v_{n_S}\}$ from $n_S$ sources with accompanying source-speciﬁc signatures $\Sigma = \{\sigma_1, \sigma_2, \ldots, \sigma_{n_S}\}$. Upon verifying the signatures, it transmits the price $v = \text{median}(V)$ to SC.

Unfortunately, there is no simple way for an oracle network to transmit the median value $v$ in Example 4 to SC along with a succinct proof $\sigma^*$ that $v$ was correctly computed over signed inputs. A na¨ıve approach would be to encode in SC the public keys of all $n_S$ data sources. The oracle network would then relay $(V, \Sigma)$ and allow SC to compute the median of $V$. This, however, would result in a proof $\sigma$ of size $O(n_S)$—i.e., $\sigma^*$ would not be succinct. It would also incur high gas costs for SC, which would need to verify all signatures in $\Sigma$. Use of SNARKs, in contrast, enables a succinct proof of correctly combined authenticated source values. It may be workable in practice, but imposes fairly high computational costs on the prover, and somewhat high gas costs on chain. Use of Town Crier is also a possibility, but requires the use of TEEs, which does not suit all users’ trust models. A helpful concept in which to frame solutions to the general problem of signing combined data from sources is a cryptographic tool known as functional signatures [59, 132]. Brieﬂy, functional signatures allow a signer to delegate signing capability, such that the delegatee can only sign messages in the range of a function F chosen by the signer. We show in Appendix D how this functional constraint can serve to bound the range of report values emitted by a DON as a function of the values signed by data sources. We also introduce a new primitive, called a discretized functional signature, that includes a relaxed requirement for accuracy, but is potentially much more performant than approaches such as SNARKs. The problem of combining data sources in a way that includes source authentication of outputs also applies to data aggregators, e.g., CoinCap, CoinMarketCap, CoinGecko, CryptoCompare, etc., which obtain data from a multiplicity of exchanges, which they weight based on volumes, using methodologies that they in some cases make public and are in other cases proprietary. An aggregator that wishes to publish a value with source authentication faces the same challenge as a collection of nodes aggregating source data. 7.1.4 Processing Source Data Sophisticated smart contracts are likely to depend on custom aggregate statistics over primary data sources, such as volatility in recent price history over many assets, or text and photographs from news about pertinent events. Because computation and bandwidth are relatively cheap in a DON, these statistics— even complex machine-learning models with many inputs—can be processed economically, as long as any output value destined for a blockchain is suﬃciently concise. For computationally intensive jobs where DON participants may have diﬀering views on complex inputs, extra rounds of communication between the DON participants may be required to establish consensus on the inputs before computing the result. As long as the ﬁnal value is fully determined by the inputs, once input consensus is established each participant can simply compute the value and broadcast it to the other

participants with their partial signature, or send it to an aggregator. 7.2 DON Trust Minimization We envision two main ways of minimizing the trust placed in components of the DON: failover clients and minority reports. 7.2.1 Failover Clients Adversarial models in the cryptography and distributed systems literature typically consider an adversary capable of corrupting (i.e., compromising) a subset of nodes, e.g., fewer than one-third for many BFT protocols. It is commonly observed, however, that if all nodes run identical software, an adversary that identiﬁes a fatal exploit could in principle compromise all nodes more or less simultaneously. This setting is often referred to as a software monoculture [47]. Various proposals for automatically diversifying software and software conﬁgurations have been put forth to address the problem, e.g., [47, 113]. As noted in [47], however, software diversity is a complex issue and requires careful consideration. Software diversiﬁcation, for example, can result in worse security than a monoculture if it increases a system’s attack surface and thus its possible vectors of attack in excess of the security beneﬁts it oﬀers. We believe that support for robust failover clients—i.e., clients to which nodes can switch in the face of a catastrophic event—is an especially attractive form of software diversiﬁcation. Failover clients do not increase the number of potential vectors of attack, as they are not deployed as mainline software. They oﬀer clear beneﬁts, however, as a second line of defense. We intend to support failover clients in DONs as a key means of reducing their dependence for security on a single client. Chainlink already has in place a robust system of failover clients. Our approach involves maintaining previous, battle-tested client versions. Today, for example, Chainlink nodes with Oﬀ-Chain Reporting (OCR) as their primary client include support for Chainlink’s previous FluxMonitor system if needed. Having been in use for some time, FluxMonitor has received security audits and ﬁeld testing. It provides the same functionality as OCR, just at higher cost—a cost only incurred on an as-needed basis. 7.2.2 Minority Reports Given a suﬃciently large minority set $O_{\text{minority}}$—a fraction of honest nodes that observe malfeasance by the majority—it can be helpful for them to generate a minority report. This is a parallel report or ﬂag, relayed to a dependent contract SC on-chain by $O_{\text{minority}}$. SC can make use of this ﬂag according to its own contract-speciﬁc policy. For example, for a contract in which safety is more important than liveness or responsiveness, a minority report might cause the contract to request supplementary reports from another DON, or trigger a circuit breaker (see the next section).

Minority reports can play an important role even when the majority is honest, because any report-aggregation scheme, even if it uses functional signatures, must operate in a threshold manner, to ensure resilience against oracle or data failure. In other words, it must be possible to produce a valid report based on the inputs of $k_S < n_S$ oracles, for some threshold $k_S$. This means a corrupted DON has some latitude in manipulating report values by selecting its preferred $k_S$ values among the $n_S$ reported in $V$ by the full set of oracles, even if all sources are honest. For example, suppose that nS = 10 and kS = 7 in a system that uses a functional signature to authenticate computation of median over V for the USD price of ETH. Suppose that ﬁve sources report a price of $500, while the other ﬁve report $1000. Then by medianizing the lowest 7 reports, the DON can output a valid value v = $500, and by medianizing the highest, it can output v = $1000. By enhancing the DON protocol so that all nodes are aware of which data was available, and which data was used to construct a report, nodes could detect and ﬂag statistically signiﬁcant tendencies to favor one set of reports over another, and produce a minority report as a result. 7.3 Guard Rails Our trust model for DONs treats MAINCHAIN as a higher-security, higher-privilege system than DONs. (While this trust model may not always hold true, it is easier to adapt the resulting mechanism to situations where the DON is the higher security platform than vice versa.) A natural trust minimization strategy thus involves the implementation of monitoring and failsafe mechanisms in smart contracts—either in a MAINCHAIN front end for a DON or directly in a dependent contract SC. We refer to these mechanisms as guard rails, and enumerate some of the most important here: • Circuit breakers: SC may pause or halt state updates as a function either of characteristics of the state updates themselves (e.g., large variance across sequential reports) or based on other inputs. For example, a circuit breaker might trip in cases where oracle reports vary implausibly over time. A circuit breaker might also be tripped by a minority report. Thus, circuit breakers can prevent DONs from making grossly erroneous reports. Circuit breakers can provide time for additional interventions to be considered or exercised. One such intervention is escape hatches. • Escape hatches: Under adverse circumstances, as identiﬁed by a set of custodians, community token holders, or other bodies of trustees, a contract may invoke an emergency facility sometimes called an escape hatch [163]. An escape hatch causes SC to shut down in some manner and/or terminates pending and possibly future transactions. For example, it may return custodied funds to users [17]),

may terminate contract terms [162], or may cancel pending and/or future transactions [173]. Escape hatches can be deployed in any type of contract, not just one that relies on a DON, but they are of interest as a potential buﬀer against DON malfeasance. • Failover: In systems where SC relies on the DON for essential services, it is possible for SC to provide failover mechanisms that ensure service continuation even in the case of DON failure or misbehavior. For example, in the TEF (Section 6), the anchor contract SCa may provide dual interfaces where both on-chain and oﬀ-chain execution interfaces are supported for certain critical operations (e.g., withdrawal), or for ordinary transactions, with a suitable delay to prevent frontrunning of DON transactions. In cases where data sources sign data, users could also furnish reports to SCa when the DON fails to do so. Fraud proofs, as proposed for various forms of optimistic rollup (see Section 6.3), are similar in ﬂavor and complementary to the mechanisms we enumerate above. They too provide a form of on-chain monitoring and protection against potential failures in oﬀ-chain system components. 7.4 Trust-Minimized Governance Like all decentralized systems, the Chainlink network requires governance mechanisms to adjust parameters over time, respond to emergencies, and guide its evolution. Some of these mechanisms currently reside on MAINCHAIN, and may continue to do so even with the deployment of DONs. One example is the payment mechanism for oracle node providers (DON nodes). DON front end contracts on MAINCHAIN contain additional mechanisms, such as guard rails, that may be subject to periodic modiﬁcation. We foresee two classes of governance mechanisms: evolutionary and emergency. Evolutionary governance: Many modiﬁcations to the Chainlink ecosystem are such that their implementation is not a matter of urgency: Performance improvements, feature enhancements, (non-urgent) security upgrades, and so forth. As Chainlink progressively moves toward even more participants in its governance, we expect many or most such changes to be ratiﬁed by the community of a speciﬁc DON aﬀected by those changes. In the interim, and perhaps ultimately as a parallel mechanism, we believe that a notion of temporal least privilege can be a useful means of implementing evolutionary governance. Very simply, the idea is for changes to deploy gradually, ensuring the community an opportunity to respond to them. For example, migration to a new MAINCHAIN contract can be constrained so that the new contract must be deployed at least thirty days before activation.

Emergency governance: Exploitable or exploited vulnerabilities in MAINCHAIN contracts or other forms of liveness or safety failures may require immediate intervention to ensure against catastrophic outcomes. Our intention is to support a multisig intervention mechanism in which, to ensure against malfeasance by any organization, signers will be dispersed across organizations. Ensuring consistent availability of signers and timely access to appropriate chains of command for authorization of emergency changes will clearly require careful operational planning and regular review. These challenges are similar to those involved in testing other cybersecurity incident-response capabilities [134], with a similar need to combat common problems like vigilance decrement [223]. The governance of DONs diﬀers from that of many decentralized systems in its potential degree of heterogeneity. Each DON may have distinct data sources, executables, service-level requirements such as uptime, and users. The Chainlink network’s governance mechanisms must be ﬂexible enough to accommodate such variations in operational goals and parameters. We are actively exploring design ideas and plan to publish research on this topic in the future. 7.5 Public-Key Infrastructure With progressive decentralization will come the need for a robust identiﬁcation of network participants, including DON nodes. In particular, Chainlink requires a strong Public-Key Infrastructure (PKI). A PKI is a system that binds keys to identities. For example, a PKI undergirds the Internet’s system of secure connections (TLS): When you connect to a website via HTTPS (e.g., https://www.chainlinklabs.com) and a lock appears in your browser, that means that the public key of the domain owner has been bound to that owner by an authority—speciﬁcally, through a digital signature in a so-called certiﬁcate. A hierarchical system of certiﬁcate authorities (CAs), whose toplevel root authorities are hardwired into popular browsers, helps ensure that certiﬁcates are issued only to the legitimate owners of domains. We expect that Chainlink will eventually make use of decentralized name services, initially the Ethereum Name Service (ENS) [22], as the foundation for our PKI. As its name suggests, ENS is analogous to DNS, the Domain Name System that maps (human-readable) domain names to IP addresses on the internet. ENS, however, instead maps human-readable Ethereum names to blockchain addresses. Because ENS operates on the Ethereum blockchain, barring key compromise, tampering with its namespace is in principle as diﬃcult as tampering with the contract administering it and/or the underlying blockchain. (DNS, in contrast, has historically been vulnerable to spooﬁng, hijacking, and other attacks.) We have registered data.eth with ENS on the Ethereum mainnet, and intend to establish it as a root namespace under which the identities of oracle data services and other Chainlink network entities reside. Domains in ENS are hierarchical, meaning that each domain may contain references to other names under it. Subdomains in ENS can serve as a way to organize and

delegate trust. The main role of data.eth will be to serve as an on-chain directory service for data feeds. Traditionally, developers and users of oracles have used oﬀ-chain sources (e.g., websites like docs.chain.link or data.chain.link, or social networks such as Twitter) to publish and obtain oracle data feed addresses (such as the ETH-USD price feed). With a highly trustworthy root namespace such as data.eth, it is possible instead to establish a mapping of eth-usd.data.eth to, e.g., the smart contract address of an on-chain oracle network aggregator for the ETH-USD price feed. This would create a secure path for anyone to refer to the blockchain as the source of truth for that data feed of that price/name pair (ETH-USD). Consequently, such use of ENS realizes two beneﬁts unavailable in oﬀ-chain data sources: • Strong security: All changes and updates to the domain are recorded immutably and secured cryptographically, as opposed to text addresses on a website, which enjoy neither of these two security properties. • Automated on-chain propagation: Updates to the underlying address of a datafeed’s smart contract can trigger notiﬁcations that propagate to dependent smart contracts and can, for example, automatically update dependent contracts with the new addresses.13 Namespaces like ENS, however, do not automatically validate legitimate ownership of asserted names. Thus, for example, if the namespace includes the entry ⟨“Acme Oracle Node Co.”, addr⟩, then a user obtains the assurance that addr belongs to the claimant of the name Acme Oracle Node Co. Without additional mechanisms around namespace administration, however, she does not obtain assurance that the name belongs to an entity legitimately called Acme Oracle Node Co. in a meaningful real world sense. Our approach to validation of names, i.e., ensuring their ownership by corresponding, legitimate real-world entities, relies on several components. Today, Chainlink Labs eﬀectively acts as a CA for the Chainlink network. While Chainlink Labs will continue to validate names, our PKI will evolve into a more decentralized model in two ways: • Web-of-trust model: The decentralized counterpart of a hierarchical PKI is often referred to as a web-of-trust.14 Variants have been proposed since the 1990s, e.g., [98], and a number of researchers have observed that blockchains can facilitate use of the idea, e.g., [227] by recording certiﬁcates in a globally consistent ledger. We are exploring variants of this model to validate the identities of entities in the Chainlink network in a more decentralized way. 13A dependent contract can optionally include a predetermined delay to allow for manual inspection and intervention by dependent-contract administrators. 14A term coined by Phil Zimmermann for PGP [238].

• Linkage to validating data: Today, a substantial amount of oracle node performance data is visible on-chain, and thus archivally bound to node addresses. Such data may be viewed as enriching an identity in the PKI by providing historical evidence of its (reliable) participation in the network. Additionally, tools for decentralized identity based on DECO and Town Crier [160] enable nodes to accumulate credentials derived from real-world data. As just one example, a node operator can attach a credential to its PKI identity that proves possession of a Dun and Bradstreet rating. These supplementary forms of validation can supplement staking in creating assurance of the security of the network. An oracle node with an established real-world identity may be viewed as having stake in a system deriving from its reputation. (See Section 4.3 and Section 9.6.3.) A ﬁnal requirement for the Chainlink PKI is secure bootstrapping, i.e., securely publishing the root name for the Chainlink network, currently data.eth (analogously to hardwiring of top-level domains in browsers). In other words, how do Chainlink users determine that data.eth is indeed the top-level domain associated with the Chainlink project? The solution to this problem for the Chainlink network is multi-pronged and may involve: • Adding a TXT record [224] to our domain record for chain.link that speciﬁes data.eth as the root domain for the Chainlink ecosystem. (Chainlink thus implicitly leverages the PKI for internet domains to validate its root ENS domain.) • Linking to data.eth from Chainlink’s existing website, e.g., from https://docs.chain.link. (Another implicit use of the PKI for internet domains.) • Making the use of data.eth known via various documents, including this whitepaper. • Posting data.eth publicly on our social-media channels, such as Twitter, and the Chainlink blog [18]. • Placing a large quantity of LINK under the control of the same registrant address as data.eth.

Minimização de confiança

Sendo um sistema descentralizado com a participação de um conjunto heterogêneo de entidades, o A rede Chainlink fornece forte proteção contra falhas tanto na atividade (disponibilidade) quanto na segurança (integridade do relatório). A maioria dos sistemas descentralizados, no entanto, varia em o grau em que os seus componentes constituintes são eles próprios descentralizados. Isto é verdade mesmo para grandes sistemas, onde a descentralização limitada entre os mineradores [32] e intermediários [51] estão presentes há muito tempo. O objetivo de qualquer esforço de descentralização é a minimização da confiança: procuramos reduzir o efeitos adversos de corrupção ou falha sistêmica na rede Chainlink, mesmo que devido a um DON malicioso. Nosso princípio orientador é o Princípio do Menor Privilégio [197]. Os componentes e atores do sistema dentro do sistema devem ter privilégios estritamente definidos para permitir apenas a conclusão bem-sucedida das funções atribuídas. Aqui apresentamos vários mecanismos concretos para Chainlink adotar em seu impulso em direção a uma minimização cada vez maior da confiança. Nós caracterizamos esses mecanismos em termos dos loci, ou seja, componentes do sistema, nos quais estão enraizados, mostrados na Fig. abordar cada locus em uma respectiva subseção. 7.1 Autenticação de fonte de dados Os modelos operacionais atuais para oracles são limitados pelo fato de que poucas fontes de dados assinar digitalmente os dados que omitem, em grande parte porque o TLS não assina nativamente dados. O TLS faz uso de assinaturas digitais em seu protocolo de “handshake” (para estabelecer uma chave compartilhada entre um servidor e um cliente). Servidores habilitados para HTTPS, portanto, possuem certificados em chaves públicas que podem, em princípio, servir para assinar dados, mas geralmente não usam esses certificados para dar suporte à assinatura de dados. Consequentemente, a segurança de um DON, como nas redes oracle atuais, depende de nós oracle que retransmitem fielmente os dados de uma rede de dados fonte para um contrato. Um componente importante de longo prazo de nossa visão para a minimização da confiança em Chainlink envolve uma autenticação mais forte da fonte de dados por meio do suporte de ferramentas e padrões para assinatura de dados. A assinatura de dados pode ajudar a aplicar garantias de integridade de ponta a ponta. Em princípio, se um contrato aceita como entrada um dado D assinado diretamente por um fornecedor de dados

Loci of trust-minimizing mechanisms in the Chainlink network showing data quality, node selection, and oracle report verification

Figura 14: Locais de mecanismos de minimização de confiança discutidos nesta seção. 1⃝Dados fontes fornecem dados para 2⃝DON, que retransmite uma função dos dados para um dependente 3⃝smart contract. Além disso, a rede DON ou oracle inclui 4⃝nós gerenciamento smart contracts em MAINCHAIN para, por exemplo, nós de compensação, proteção trilhos e assim por diante. fonte, então a rede oracle não pode adulterar D. Vários encorajadores surgiram esforços para permitir essa assinatura de dados, incluindo o OpenID Connect, que foi projetado principalmente para autenticação de usuário [9], TLS-N, um projeto acadêmico que visa estender o TLS [191] reaproveitando certificados TLS e extensões de evidências TLS [63]. Embora o OpenID Connect tenha tido alguma adoção, no entanto, as TLS Evidence Extensions e o TLS-N ainda não foi adotado. Outra via potencial de autenticação de fonte de dados é usar os próprios editores Signed HTTP Exchanges (SXG) [230], que podem ser armazenados em cache em redes de distribuição de conteúdo como parte do protocolo Accelerated Mobile Pages (AMP) [225]. O navegador móvel Chrome exibe o conteúdo de SXGs armazenados em cache de AMP como se fossem veiculados por os próprios domínios de rede de seus editores em vez do domínio do servidor de cache. Este incentivo de marca, juntamente com a relativa facilidade de ativá-lo usando serviços como o Real URL [83] da CloudFlare e o amppackager [124] do Google, pode levar à adoção generalizada de SXGs em conteúdo de notícias em cache, o que permitiria uma solução simples e resistente a adulterações. maneira de Chainlink oracles serem acionados em eventos de interesse jornalístico relatados em SXGs válidos. Embora os SXGs armazenados em cache de AMP de editores de notícias não sejam úteis para aplicativos como relatórios sobre dados comerciais, eles podem ser uma fonte segura para informações personalizadas contratos relativos a eventos do mundo real, como condições climáticas extremas ou resultados eleitorais. Acreditamos que a implantação simples, ferramentas maduras e flexibilidade serão vitais para acelerando a assinatura da fonte de dados. Permitir que provedores de dados usem nós Chainlink como um front-end de API autenticado parece uma abordagem promissora. Pretendemos criar umopção para os nós funcionarem neste modo, com ou sem participação na rede como um oracle completo. Nos referimos a esse recurso como origem de dados autenticada (ADO). Ao usar nós Chainlink com ADO, as fontes de dados poderão se beneficiar da experiência e ferramentas desenvolvidas pela comunidade Chainlink para adicionar digital recursos de assinatura para seu conjunto existente de APIs fora da cadeia. Eles deveriam escolher correr seus nós como oracles, eles também podem abrir novos fluxos de receita em potencial sob o mesmo modelo dos provedores de dados existentes, por exemplo, Kraken [28], Kaiko [140], e outros, que executam nós Chainlink para vender dados de API em cadeia. 7.1.1 As limitações da origem de dados autenticados A assinatura digital por fontes de dados, embora possa ajudar a fortalecer a autenticação, não é suficiente por si só para atingir todas as metas naturais de segurança ou operacionais de um oracle rede. Para começar, um determinado dado D ainda deve ser transmitido de forma robusta e oportuna. caminho de uma fonte de dados para smart contract ou outro consumidor de dados. Ou seja, mesmo em um ambiente ideal em que todos os dados são assinados usando chaves pré-programadas em dependentes contratos, um DON ainda seria necessário para comunicar os dados de forma confiável das fontes aos contratos. Além disso, há vários casos em que contratos ou outros dados oracle os consumidores desejam acesso à saída autenticada de várias funções computadas dados de origem por dois motivos principais: • Confidencialidade: uma API de fonte de dados pode fornecer dados confidenciais ou proprietários que precisa ser redigido ou higienizado antes de se tornar publicamente visível na rede. Qualquer modificação nos dados assinados, entretanto, invalidava a assinatura. Coloque outro Dessa forma, o ADO ingênuo e a limpeza de dados são incompatíveis. Mostramos no Exemplo 3 como os dois podem ser reconciliados através de uma forma aprimorada de ADO. • Falhas nas fontes de dados: erros e falhas podem afetar as fontes de dados, e as assinaturas digitais não resolvem nenhum dos problemas. Desde o seu início [98], Chainlink tem já incluía um mecanismo para remediar tais falhas: redundância. Os relatórios emitidos pelas redes oracle normalmente representam os dados combinados de vários fontes. Discutiremos agora os esquemas que estamos explorando no ambiente ADO para aumentar a confidencialidade dos dados de origem e combinar dados de múltiplas fontes com segurança. 7.1.2 Confidencialidade As fontes de dados podem não antecipar e disponibilizar toda a gama de APIs desejada pelos usuários. Especificamente, os usuários podem desejar acessar dados pré-processados para ajudar a garantir confidencialidade. O exemplo a seguir ilustra o problema.Exemplo 3. Alice deseja obter uma credencial de identidade descentralizada (DID) informando que ela tem mais de 18 anos (e portanto pode, por exemplo, contrair um empréstimo). Para fazer então, ela precisa provar esse fato sobre sua idade para um emissor de credencial DID. Alice espera usar dados do Departamento de Veículos Motorizados (DMV) de seu estado site para o efeito. O Detran tem registro de sua data de nascimento e emitirá um atestado A assinado digitalmente no seguinte formato: A = {Nome: Alice, Data de nascimento: 16/02/1999}. Neste exemplo, o atestado A pode ser suficiente para Alice provar ao DID emissor da credencial que ela tem mais de 18 anos. Mas vaza desnecessariamente informações confidenciais: Alice's DoB exato. Idealmente, o que Alice gostaria do DMV seria uma assinatura em um declaração simples A′ de que “Alice tem mais de 18 anos”. Em outras palavras, ela quer que o saída de uma função G em sua data de nascimento X, onde (informalmente), A′ = G(X) = True se DataAtual −X ≥18 anos; caso contrário, G(X) = Falso. Para generalizar, Alice gostaria de poder solicitar da fonte de dados um documento assinado atestado A′ do formato: A′ = {Nome: Alice, Func:G(X), Resultado: Verdadeiro}, onde G(X) denota uma especificação de uma função G e sua(s) entrada(s) X. Imaginamos que um usuário deve ser capaz de fornecer um G(X) desejado como entrada com sua solicitação de um atestado correspondente A′. Observe que o atestado A′ da fonte de dados deve incluir a especificação G(X) para certifique-se de que A′ seja interpretado corretamente. No exemplo acima, G(X) define o significado do valor booleano em A′ e, portanto, True significa o assunto do atestado tem mais de 18 anos de idade. Referimo-nos a consultas flexíveis nas quais um usuário pode especificar G(X) como consultas funcionais. Para dar suporte a casos de uso como o do Exemplo 3, bem como aqueles que envolvem consultas diretamente dos contratos, pretendemos incluir suporte para consultas funcionais envolvendo funções simples G como parte do ADO. 7.1.3 Combinando dados de origem Para reduzir os custos na cadeia, os contratos são geralmente concebidos para consumir dados combinados de múltiplas fontes, conforme ilustrado no exemplo a seguir. Exemplo 4 (Medianização de dados de preços). Para fornecer um feed de preços, ou seja, o valor de um ativo (por exemplo, ETH) em relação a outro (por exemplo, USD), uma rede oracle geralmente obter preços atuais de diversas fontes, como bolsas. A rede oracle normalmente envia para um contrato dependente SC a mediana desses valores. Em um ambiente com assinatura de dados, uma rede oracle funcionando corretamente obtém de fontes de dados S = {S1, . . . , SnS} uma sequência de valores V = {v1, v2, . . . , vnS} de Fontes nS acompanhadas de assinaturas específicas da fonte Σ = {σ1, σ2, . . . , σnS}. Após verificando as assinaturas, transmite o preço v = median(V ) para SC.Infelizmente, não existe uma maneira simples de uma rede oracle transmitir a mediana valor v no Exemplo 4 para SC junto com uma prova sucinta σ∗ de que v foi calculado corretamente sobre entradas assinadas. Uma abordagem ingénua seria codificar em SC as chaves públicas de todas as fontes de dados nS. A rede oracle então retransmitiria (V, Σ) e permitiria que SC calculasse a mediana de V . Isso, no entanto, resultaria em uma prova σ de tamanho O(nS) - ou seja, σ∗não seria sucinto. Também incorreria em elevados custos de gás para SC, que precisaria verificar todas as assinaturas em Σ. O uso de SNARKs, por outro lado, permite uma prova sucinta de valores de origem autenticados combinados corretamente. Pode ser viável na prática, mas impõe custos bastante elevados custos computacionais no provador e custos de gás um tanto elevados na cadeia. Uso de O Pregoeiro também é uma possibilidade, mas exige o uso de TEEs, o que não atende a todos modelos de confiança dos usuários. Um conceito útil para enquadrar soluções para o problema geral de assinatura de dados combinados de fontes é uma ferramenta criptográfica conhecida como assinaturas funcionais [59, 132]. Resumidamente, as assinaturas funcionais permitem que um signatário delegue capacidade de assinatura, de modo que o delegado só pode assinar mensagens no intervalo de uma função F escolhida pelo signatário. Mostramos no Apêndice D como esta restrição funcional pode servir para limitar o intervalo dos valores do relatório emitidos por um DON em função dos valores assinados pelas fontes de dados. Também introduzimos uma nova primitiva, chamada assinatura funcional discretizada, que inclui um requisito relaxado de precisão, mas tem potencialmente um desempenho muito melhor do que abordagens como SNARKs. O problema de combinar fontes de dados de uma forma que inclua autenticação de origem dos resultados também se aplica a agregadores de dados, por exemplo, CoinCap, CoinMarketCap, CoinGecko, CryptoCompare, etc., que obtêm dados de uma multiplicidade de exchanges, que eles peso baseado em volumes, utilizando metodologias que em alguns casos tornam públicas e em outros casos são proprietários. Um agregador que deseja publicar um valor com a autenticação de origem enfrenta o mesmo desafio que uma coleção de nós agregando dados de origem. 7.1.4 Processando dados de origem smart contracts sofisticados provavelmente dependerão de estatísticas agregadas personalizadas fontes primárias de dados, como volatilidade no histórico recente de preços de muitos ativos, ou textos e fotografias de notícias sobre acontecimentos pertinentes. Como a computação e a largura de banda são relativamente baratas em um DON, essas estatísticas— mesmo modelos complexos de aprendizado de máquina com muitas entradas podem ser processados economicamente, desde que qualquer valor de saída destinado a um blockchain seja suficientemente conciso. Para trabalhos computacionalmente intensivos onde DON participantes podem ter diferentes opiniões sobre entradas complexas, rodadas extras de comunicação entre os participantes DON podem ser necessárias para estabelecer consenso sobre as entradas antes de calcular o resultado. Desde que o valor final seja totalmente determinado pelas entradas, uma vez estabelecido o consenso de entrada, cada participante pode simplesmente calcular o valor e transmiti-lo ao outro.participantes com sua assinatura parcial ou enviá-la para um agregador. 7.2 DON Minimização de confiança Imaginamos duas maneiras principais de minimizar a confiança depositada nos componentes do DON: clientes de failover e relatórios minoritários. 7.2.1 Clientes de failover Modelos adversários na literatura de criptografia e sistemas distribuídos normalmente considerar um adversário capaz de corromper (ou seja, comprometer) um subconjunto de nós; por exemplo, menos de um terço para muitos protocolos BFT. É comumente observado, no entanto, que se todos os nós executarem software idêntico, um adversário que identifique uma exploração fatal poderá em princípio, comprometem todos os nós mais ou menos simultaneamente. Esta configuração é frequentemente referida como monocultura de software [47]. Várias propostas para diversificar automaticamente software e configurações de software foram apresentadas para resolver o problema, por exemplo, [47, 113]. Conforme observado em [47], entretanto, a diversidade de software é uma questão complexa e requer consideração cuidadosa. A diversificação de software, por exemplo, pode resultar em pior segurança do que uma monocultura se for aumenta a superfície de ataque de um sistema e, portanto, seus possíveis vetores de ataque em excesso os benefícios de segurança que oferece. Acreditamos que o suporte para clientes robustos de failover, ou seja, clientes aos quais os nós pode mudar diante de um evento catastrófico – é uma forma especialmente atraente de diversificação de software. Os clientes de failover não aumentam o número de vetores potenciais de ataque, pois não são implantados como software principal. Eles oferecem benefícios claros, no entanto, como uma segunda linha de defesa. Pretendemos oferecer suporte a clientes de failover em DONs como um meio fundamental de reduzir sua dependência de segurança em um único cliente. Chainlink já possui um sistema robusto de clientes de failover. Nossa abordagem envolve a manutenção de versões de clientes anteriores e testadas em batalha. Hoje, por exemplo, nós Chainlink com relatórios fora da cadeia (OCR) como cliente principal incluem suporte para o sistema FluxMonitor anterior de Chainlink, se necessário. Tendo sido usado por alguns Ao mesmo tempo, o FluxMonitor recebeu auditorias de segurança e testes de campo. Ele fornece o mesmo funcionalidade como OCR, mas com um custo mais elevado – um custo incorrido apenas conforme a necessidade. 7.2.2 Relatórios Minoritários Dado um conjunto minoritário suficientemente grande de Ominoridade – uma fração de nós honestos que observam a prevaricação da maioria – pode ser útil para eles gerar uma minoria. relatório. Este é um relatório ou sinalizador paralelo, retransmitido para um SC de contrato dependente na cadeia por Ominoridade. SC pode fazer uso desta bandeira de acordo com sua política específica do contrato. Por exemplo, para um contrato em que a segurança é mais importante do que a vivacidade ou a capacidade de resposta, um relatório minoritário pode fazer com que o contrato solicite relatórios suplementares. de outro DON ou acione um disjuntor (veja a próxima seção).Os relatórios minoritários podem desempenhar um papel importante mesmo quando a maioria é honesta, porque qualquer esquema de agregação de relatórios, mesmo que utilize assinaturas funcionais, deve operar de forma limitada, para garantir resiliência contra oracle ou falha de dados. Em outras palavras, deve ser possível produzir um relatório válido com base nas informações de kS < nS oracles, para algum limite kS. Isso significa que um DON corrompido tem alguns latitude na manipulação de valores de relatório, selecionando seus valores kS preferidos entre os nS relatado em V pelo conjunto completo de oracles, mesmo que todas as fontes sejam honestas. Por exemplo, suponha que nS = 10 e kS = 7 em um sistema que utiliza uma função assinatura para autenticar o cálculo da mediana sobre V para o preço da ETH em dólares. Suponha que cinco fontes relatem um preço de $500, while the other ﬁve report $1000. Então, medianizando os 7 relatórios mais baixos, o DON pode gerar um valor válido v = $500, e medianizando o mais alto, pode gerar v = $ 1.000. Ao aprimorar o protocolo DON para que todos os nós estejam cientes de quais dados foram disponíveis e quais dados foram usados para construir um relatório, os nós poderiam detectar e sinalizar tendências estatisticamente significativas para favorecer um conjunto de relatórios em detrimento de outro e produzir como resultado, um relatório minoritário. 7.3 Guarda-corpos Nosso modelo de confiança para DONs trata MAINCHAIN como um sistema de maior segurança e maior privilégio sistema do que DONs. (Embora este modelo de confiança nem sempre seja verdadeiro, é mais fácil adaptar o mecanismo resultante a situações em que DON é a segurança mais alta plataforma do que vice-versa.) Uma estratégia natural de minimização da confiança envolve, portanto, a implementação de mecanismos de monitoramento e à prova de falhas em smart contracts - seja em um front-end MAINCHAIN para um DON ou diretamente em um contrato de dependente SC. Nos referimos a esses mecanismos como guarda-corpos e enumere alguns dos mais importantes aqui: • Disjuntores: o SC pode pausar ou interromper as atualizações de estado em função das características das próprias atualizações de estado (por exemplo, grande variação entre relatórios) ou com base em outras informações. Por exemplo, um disjuntor pode desarmar casos em que os relatórios oracle variam de forma implausível ao longo do tempo. Um disjuntor pode também ser tropeçado por um relatório minoritário. Assim, os disjuntores podem evitar DONs de fazer relatórios grosseiramente errados. Os disjuntores podem fornecer tempo para que intervenções adicionais sejam consideradas ou exercido. Uma dessas intervenções são as saídas de emergência. • Escotilhas de fuga: Em circunstâncias adversas, conforme identificado por um conjunto de custodiantes, detentores de token comunitários ou outros órgãos de curadores, um contrato pode invocar uma instalação de emergência às vezes chamada de escotilha de fuga [163]. Uma escotilha de fuga faz com que o SC seja desligado de alguma maneira e/ou termine pendente e possivelmente transações futuras. Por exemplo, pode devolver fundos custodiados aos usuários [17]),pode rescindir os termos do contrato [162] ou pode cancelar transações pendentes e/ou futuras [173]. As escotilhas de fuga podem ser implantadas em qualquer tipo de contrato, não apenas aquele que depende de um DON, mas eles são de interesse como um buffer potencial contra DON prevaricação. • Failover: Em sistemas onde o SC depende do DON para serviços essenciais, é possível que o SC forneça mecanismos de failover que garantam a continuação do serviço mesmo no caso de falha ou mau comportamento de DON. Por exemplo, no TEF (Secção 6), o contrato âncora SCa pode fornecer interfaces duplas onde tanto on-chain quanto interfaces de execução fora da cadeia são suportadas para certas operações críticas (por exemplo, retirada), ou para transações normais, com um atraso adequado para evitar a antecipação de transações DON. Nos casos em que as fontes de dados assinam dados, os usuários podem também fornecerá relatórios à SCa quando o DON não o fizer. Provas de fraude, conforme proposto para várias formas de rollup otimista (ver Seção 6.3), são semelhantes em sabor e complementares aos mecanismos que enumeramos acima. Eles também fornece uma forma de monitoramento e proteção na cadeia contra possíveis falhas em componentes do sistema fora da cadeia. 7.4 Governança com confiança minimizada Como todos os sistemas descentralizados, a rede Chainlink requer mecanismos de governança ajustar parâmetros ao longo do tempo, responder a emergências e orientar sua evolução. Alguns desses mecanismos residem atualmente no MAINCHAIN e podem continuar a existir. faça isso mesmo com a implantação de DONs. Um exemplo é o mecanismo de pagamento para provedores de nós oracle (nós DON). DON contratos front-end em MAINCHAIN conter mecanismos adicionais, como guarda-corpos, que podem estar sujeitos a alterações periódicas modificação. Prevemos duas classes de mecanismos de governança: evolutivos e emergenciais. Governança evolucionária: Muitas modificações no ecossistema Chainlink são de modo que sua implementação não seja uma questão urgente: Melhorias de desempenho, aprimoramentos de recursos, atualizações de segurança (não urgentes) e assim por diante. À medida que Chainlink avança progressivamente em direção a ainda mais participantes em sua governança, esperamos que muitos ou a maioria dessas mudanças deve ser ratificada pela comunidade de um DON específico afetado por aqueles mudanças. Entretanto, e talvez em última análise como mecanismo paralelo, acreditamos que uma noção de menor privilégio temporal pode ser um meio útil de implementar a governação evolutiva. Muito simplesmente, a ideia é que as mudanças sejam implementadas gradualmente, garantindo à comunidade uma oportunidade de responder a eles. Por exemplo, a migração para um novo O contrato MAINCHAIN pode ser restringido para que o novo contrato seja implantado pelo menos trinta dias antes da ativação.Governança de emergência: Vulnerabilidades exploráveis ou exploradas em MAINCHAIN contratos ou outras formas de vida ou falhas de segurança podem exigir intervenção imediata para garantir resultados catastróficos. Nossa intenção é apoiar um multisig mecanismo de intervenção no qual, para garantir contra má conduta por parte de qualquer organização, os signatários estarão dispersos pelas organizações. Garantindo disponibilidade consistente de assinantes e acesso oportuno às cadeias de comando apropriadas para autorização de emergência as mudanças exigirão claramente um planeamento operacional cuidadoso e uma revisão regular. Estes os desafios são semelhantes aos envolvidos no teste de outras respostas a incidentes de segurança cibernética capacidades [134], com uma necessidade semelhante de combater problemas comuns como o decréscimo de vigilância [223]. A governança de DONs difere daquela de muitos sistemas descentralizados em sua grau potencial de heterogeneidade. Cada DON pode ter fontes de dados, executáveis, requisitos de nível de serviço distintos, como tempo de atividade e usuários. A rede Chainlink mecanismos de governação devem ser suficientemente flexíveis para acomodar tais variações na metas e parâmetros operacionais. Estamos explorando ativamente ideias de design e planejamos publicar pesquisas sobre este tema no futuro. 7,5 Infraestrutura de chave pública Com a descentralização progressiva, surgirá a necessidade de uma identificação robusta dos participantes da rede, incluindo nós DON. Em particular, Chainlink requer um forte Infraestrutura de chave pública (PKI). Uma PKI é um sistema que vincula chaves a identidades. Para Por exemplo, uma PKI sustenta o sistema de conexões seguras (TLS) da Internet: quando você se conecta a um site via HTTPS (por exemplo, https://www.chainlinklabs.com) e um lock aparece no seu navegador, isso significa que a chave pública do proprietário do domínio foi foi vinculado a esse proprietário por uma autoridade - especificamente, por meio de uma assinatura digital em um chamado certificado. Um sistema hierárquico de autoridades de certificação (CAs), cujas autoridades raiz de nível superior estão conectadas a navegadores populares, ajuda a garantir que os certificados são emitidos apenas para os legítimos proprietários de domínios. Esperamos que Chainlink eventualmente faça uso de serviços de nomes descentralizados, inicialmente o Ethereum Name Service (ENS) [22], como base para nossa PKI. Como seu nome sugere, ENS é análogo ao DNS, o Sistema de Nomes de Domínio que mapeia nomes de domínio (legíveis por humanos) para endereços IP na Internet. O ENS, no entanto, mapeia nomes Ethereum legíveis por humanos para endereços blockchain. Porque ENS opera no Ethereum blockchain, impedindo o comprometimento da chave, adulterando seu namespace é, em princípio, tão difícil quanto adulterar o contrato que o administra e/ou o blockchain subjacente. (O DNS, por outro lado, tem sido historicamente vulnerável para falsificação, sequestro e outros ataques.) Registramos data.eth com ENS na rede principal Ethereum e pretendemos estabelecê-lo como um namespace raiz sob o qual as identidades dos serviços de dados oracle e outras entidades de rede Chainlink residem. Os domínios no ENS são hierárquicos, o que significa que cada domínio pode conter referências para outros nomes sob ele. Os subdomínios no ENS podem servir como uma forma de organizar edelegar confiança. A principal função do data.eth será servir como um serviço de diretório on-chain para feeds de dados. Tradicionalmente, os desenvolvedores e usuários de oracles têm usado fontes fora da cadeia (por exemplo, sites como docs.chain.link ou data.chain.link, ou redes sociais como Twitter) para publicar e obter endereços de feed de dados oracle (como o preço ETH-USD alimentação). Com um namespace raiz altamente confiável como data.eth, é possível estabelecer um mapeamento de eth-usd.data.eth para, por exemplo, o endereço smart contract de um agregador de rede oracle on-chain para o feed de preços ETH-USD. Isso seria criar um caminho seguro para qualquer pessoa se referir ao blockchain como a fonte da verdade para aquele feed de dados desse par preço/nome (ETH-USD). Consequentemente, tal uso de ENS percebe dois benefícios não disponíveis em fontes de dados fora da cadeia: • Segurança forte: todas as alterações e atualizações no domínio são registradas de forma imutável e protegidos criptograficamente, em oposição aos endereços de texto em um site, que não desfrute de nenhuma dessas duas propriedades de segurança. • Propagação automatizada na cadeia: atualizações no endereço subjacente de um feed de dados smart contract podem acionar notificações que se propagam para dispositivos inteligentes dependentes. contratos e pode, por exemplo, atualizar automaticamente contratos dependentes com os novos endereços.13 Namespaces como ENS, no entanto, não validam automaticamente a propriedade legítima de nomes afirmados. Assim, por exemplo, se o namespace incluir a entrada ⟨“Acme Oracle Node Co.”, endereço⟩, então, um usuário obtém a garantia de que addr pertence ao requerente do nome Acme Oracle Node Co. Sem mecanismos adicionais para administração de namespace, no entanto, ela não obtém garantia de que o nome pertence a uma entidade legitimamente chamado Acme Oracle Node Co. em um sentido significativo do mundo real. Nossa abordagem para validação de nomes, ou seja, garantir sua propriedade por entidades correspondentes e legítimas do mundo real, depende de vários componentes. Hoje, Chainlink Laboratórios atua efetivamente como uma CA para a rede Chainlink. Enquanto os laboratórios Chainlink continuarão para validar nomes, nossa PKI evoluirá para um modelo mais descentralizado de duas maneiras: • Modelo de rede de confiança: A contrapartida descentralizada de uma PKI hierárquica é muitas vezes referida como uma rede de confiança.14 Variantes têm sido propostas desde a década de 1990, por exemplo, [98], e vários pesquisadores observaram que blockchains podem facilitar o uso da ideia, por exemplo, [227] registrando certificados de uma forma globalmente consistente. livro razão. Estamos explorando variantes deste modelo para validar as identidades das entidades na rede Chainlink de forma mais descentralizada. 13Um contrato dependente pode incluir opcionalmente um atraso predeterminado para permitir inspeção manual e intervenção de administradores de contratos dependentes. 14Um termo cunhado por Phil Zimmermann para PGP [238].• Vinculação com dados de validação: hoje, uma quantidade substancial de dados de desempenho de nós oracle é visível na cadeia e, portanto, vinculada de forma arquivística aos endereços de nós. Esses dados podem ser vistos como enriquecedores de uma identidade na PKI, fornecendo provas históricas da sua participação (confiável) na rede. Além disso, ferramentas para identidade descentralizada baseada em DECO e Town Crier [160] habilitar nós para acumular credenciais derivadas de dados do mundo real. Como apenas um exemplo, um o operador do nó pode anexar uma credencial à sua identidade PKI que comprove a posse de uma classificação Dun e Bradstreet. Estas formas complementares de validação podem suplemento staking na criação de garantia de segurança da rede. Um nó oracle com uma identidade estabelecida no mundo real pode ser visto como tendo participação em um sistema derivado de sua reputação. (Consulte a Seção 4.3 e a Seção 9.6.3.) Um requisito final para a PKI Chainlink é a inicialização segura, ou seja, publicando o nome raiz da rede Chainlink, atualmente data.eth (analogamente à conexão física de domínios de nível superior em navegadores). Em outras palavras, como os usuários Chainlink determine que data.eth é de fato o domínio de nível superior associado ao Chainlink projeto? A solução para este problema para a rede Chainlink é multifacetada e pode envolver: • Adicionar um registro TXT [224] ao nosso registro de domínio para chain.link que especifica data.eth como domínio raiz do ecossistema Chainlink. (Chainlink aproveita implicitamente a PKI para domínios da Internet para validar seu domínio ENS raiz.) • Link para data.eth do site existente de Chainlink, por exemplo, de https://docs.chain.link. (Outro uso implícito da PKI para domínios da Internet.) • Divulgar o uso do data.eth por meio de vários documentos, incluindo este whitepaper. • Publicar data.eth publicamente em nossos canais de mídia social, como o Twitter, e o blog Chainlink [18]. • Colocar uma grande quantidade de LINK sob o controle do mesmo endereço de registrante como dados.eth.

DON Deployment Considerations

While not a part of our core design, there are several important technical considerations in the realization of DONs that deserve treatment here.

8.1 Rollout Approach This paper lays out an ambitious vision of advanced Chainlink functionality whose realization will require solutions to many challenges along the way. This whitepaper identiﬁes some challenges, but unanticipated ones are sure to arise. We plan to implement elements of this vision in an incremental fashion over an extended period of time. Our expectation is that DONs will initially launch with support for speciﬁc pre-built components built collaboratively by teams within the Chainlink community. The intention is that broader uses of DONs, e.g., the ability to launch arbitrary executables, will see support at a later time. One reason for such caution is that composition of smart contracts can have complex, unintended, and dangerous side eﬀects, as recent ﬂash-loan-based attacks have for instance shown [127, 189]. Similarly, composition of smart contracts, adapters, and executables will require extreme care. In our initial deployment of DONs, we plan to include only a pre-built set of templatized executables and adapters. This will enable study of the compositional security of these functionalities using formal methods [46, 170] and other approaches. It will also simplify pricing: Functionality pricing can be established by DON nodes on a perfunctionality basis, rather than through generalized metering, an approach adopted in, e.g., [156]. We also expect the Chainlink community to take part in the creation of additional templates, combining various adapters and executables into increasingly useful decentralized services that can be run by hundreds, if not thousands of individual DONs. Additionally, this approach can help prevent state bloat, i.e., the need for DON nodes to retain an unworkable amount of state in working memory. This problem is already arising in permissionless blockchains, motivating approaches such as “stateless clients” (see, e.g., [206]). It can be more acute in higher throughput systems, motivating an approach in which a DON deploys only state-size-optimized executables. As DONs evolve and mature and include robust guard rails, as discussed in Section 7, cryptoeconomic and reputation-based security mechanisms as discussed in Section 9, and other features that provide a high degree of assurance for DON users, we also expect to develop a framework and tools to facilitate broader launch and use of DONs by the community. Ideally, these tools will enable a collection of node operators to come together as an oracle network and launch their own DONs in a permissionless or self-service manner, meaning that they can do so unilaterally. 8.2 Dynamic DON Membership The set of nodes running a given DON may change over time. There are two approaches to key management for skL given dynamic membership in O. The ﬁrst is to update shares of skL held by the nodes upon changes in membership, while keeping pkL unchanged. This approach, explored in [41, 161, 198], has the merit of not requiring that relying parties update pkL.

The classical technique of share resharing, introduced in [122], provides a simple and eﬃcient way of realizing such share updates. It enables a secret to be transferred between one set of nodes O(1) and a second, possibly intersecting one O(2). In this approach, each node O(1) i performs a (k(2), n(2)) secret sharing of its secret share across nodes in O(2) for n(2) = |O(2)| and desired (possibly new) threshold k(2). Various veriﬁable secret sharing (VSS) schemes [108] can provide security against an adversary that actively corrupts nodes, i.e., introduces malicious behavior into the protocol. Techniques in [161] aim to do so while reducing communication complexity and providing resilience against failures in cryptographic hardness assumptions. A second approach is to update the ledger key pkL. This has the beneﬁt of forward security: Compromise of old shares of pkL (i.e., former committee nodes) would not result in compromise of the current key. Updates to pkL, however, carry two drawbacks: (1) Data encrypted under pkL needs to be re-encrypted during a key refresh and (2) Key updates need to be propagated to relying parties. We intend to explore both approaches, as well as hybridizations of the two. 8.3 DON Accountability As with existing Chainlink oracle networks, DONs will include mechanisms for accountability, i.e., recording, monitoring, and enforcing correct node behavior. DONs will have much more substantial data capacity than many existing permissionless blockchains, particularly given their ability to connect to external decentralized storage. Consequently, they will be able to record nodes’ performance history in detail, allowing for more ﬁne-grained accountability mechanisms. For example, oﬀ-chain computation of asset prices may involve inputs that are discarded before a median result is sent on chain. In a DON, these intermediate results could be recorded. Misbehavior or performance lapses by individual nodes in a DON can thus be remedied or penalized on the DON in a ﬁne-grained way. We have additionally discussed approaches to building guard rails in Section 7.3 that address the contract-speciﬁc impact of systemic failures. It is also important, however, to have failsafe mechanisms for DONs themselves, i.e., protections against systemic, potentially catastrophic DON failures, speciﬁcally forking / equivocation and service-level agreement (SLA) failures, as we now explain. Forking / equivocation: Given suﬃciently many faulty nodes, a DON can fork or equivocate, producing two distinct, inconsistent blocks or sequences of blocks in L. Because a DON digitally signs the contents of L, however, it is possible to leverage a main chain MAINCHAIN to prevent and/or penalize equivocation. The DON can periodically checkpoint state from L in an audit contract on MAINCHAIN. If its future state deviates from a checkpointed state, a user / auditor can present proof of this misbehavior to the audit contract. Such proof can be used to generate an alert or penalize DON nodes via slashing in the contract. This latter approach introduces an incentive design problem similar to that for speciﬁc oracle feeds, and can build on our work outlined in Section 9.

Enforcing service-level agreements: While DONs are not necessarily meant to run indeﬁnitely, it is important that they adhere to service level agreements (SLAs) with their users. Basic SLA enforcement is possible on a main chain. For example, DON nodes might commit to maintaining the DON until a certain date, or to providing advance notice of service termination (e.g., three months’ notice). A contract on MAINCHAIN can provide basic cryptoeconomic SLA enforcement. For example, the SLA contract can slash DON-deposited funds if checkpoints are not provided at required intervals. A user can deposit funds and challenge the DON to prove that a checkpoint correctly represents a sequence of valid blocks (in a manner analogous to, e.g. [141]). Of course, block production does not equate with transaction processing, but the SLA contract can also serve to enforce the latter. For example, in the legacy-compatible version of FSS in which transactions are fetched from the mempool (see Section 5.2), transactions are eventually mined and placed on chain. A user can prove DON malfeasance by furnishing the SLA contract with a transaction that was mined but wasn’t transmitted by the DON for processing by the target contract within the appropriate interval of time.15 It is also possible to prove the existence of and penalize more ﬁne-grained SLA failures, including errors in computation using executables (via, e.g., the mechanisms for proving correct oﬀ-chain state transactions outlined in Section 6.3) or failure to run executables based on initiators visible on a DON, failure to relay data on the DON to MAINCHAIN in a timely way, and so forth.

DON Considerações sobre implantação

Embora não faça parte do nosso design principal, existem várias considerações técnicas importantes na realização de DONs que merecem tratamento aqui.

8.1 Abordagem de implementação Este artigo apresenta uma visão ambiciosa da funcionalidade avançada Chainlink cujo a realização exigirá soluções para muitos desafios ao longo do caminho. Este artigo identifica alguns desafios, mas certamente surgirão desafios imprevistos. Planejamos implementar elementos desta visão de forma incremental ao longo de um período de tempo prolongado. Nossa expectativa é que DONs seja lançado inicialmente com suporte para componentes pré-construídos específicos construídos de forma colaborativa por equipes dentro do Chainlink comunidade. A intenção é que usos mais amplos de DONs, por exemplo, a capacidade de lançar executáveis arbitrários, terá suporte posteriormente. Uma razão para tal cautela é que a composição de smart contracts pode ter efeitos colaterais complexos, não intencionais e perigosos, como recentes ataques baseados em empréstimos flash por exemplo mostrado [127, 189]. Da mesma forma, a composição de smart contracts, adaptadores e executáveis exigirão extremo cuidado. Em nossa implantação inicial de DONs, planejamos incluir apenas um conjunto pré-construído de executáveis e adaptadores modelados. Isto permitirá o estudo da segurança composicional dessas funcionalidades usando métodos formais [46, 170] e outras abordagens. Isso vai também simplificar o preço: o preço da funcionalidade pode ser estabelecido por nós DON com base na funcionalidade, em vez de por meio de medição generalizada, uma abordagem adotada em, por exemplo, [156]. Esperamos também que a comunidade Chainlink participe na criação de modelos adicionais, combinando vários adaptadores e executáveis em cada vez mais serviços descentralizados úteis que podem ser administrados por centenas, senão milhares de indivíduos DONs. Além disso, esta abordagem pode ajudar a evitar o inchaço do estado, ou seja, a necessidade de DON nós para reter uma quantidade impraticável de estado na memória de trabalho. Este problema é já surgindo em blockchains sem permissão, motivando abordagens como “stateless clientes” (ver, por exemplo, [206]). Pode ser mais agudo em sistemas de maior rendimento, motivando uma abordagem na qual um DON implanta apenas executáveis otimizados para tamanho de estado. À medida que os DONs evoluem e amadurecem e incluem barreiras de proteção robustas, conforme discutido na Seção 7, mecanismos de segurança criptoeconômicos e baseados em reputação, conforme discutido na Seção 9, e outros recursos que fornecem um alto grau de garantia para usuários de DON, nós também esperamos desenvolver uma estrutura e ferramentas para facilitar o lançamento e uso mais amplo de DONs pela comunidade. Idealmente, essas ferramentas permitirão uma coleção de operadores de nós se unirem como uma rede oracle e lançarem seus próprios DONs em um ambiente sem permissão ou de autoatendimento, o que significa que podem fazê-lo unilateralmente. 8.2 Associação dinâmica DON O conjunto de nós executando um determinado DON pode mudar com o tempo. Existem duas abordagens ao gerenciamento de chaves para skL, dada a associação dinâmica em O. A primeira é atualizar as ações de skL mantidas pelos nós após mudanças na associação, enquanto mantém o pkL inalterado. Esta abordagem, explorada em [41, 161, 198], tem o mérito de não exigir que as partes confiantes atualizem o pkL.A técnica clássica de compartilhar novamente, introduzida em [122], fornece uma maneira simples e eficiente de realizar tais atualizações de compartilhamento. Permite que um segredo seja transferido entre um conjunto de nós O(1) e um segundo, possivelmente cruzando um O(2). Neste abordagem, cada nó O (1) eu executa um compartilhamento secreto (k(2), n(2)) de seu compartilhamento secreto entre nós em O(2) para n(2) = |O(2)| e limite desejado (possivelmente novo) k(2). Vários esquemas de compartilhamento de segredos verificáveis (VSS) [108] podem fornecer segurança contra um adversário que corrompe ativamente os nós, ou seja, introduz comportamento malicioso no protocolo. As técnicas em [161] visam fazer isso, reduzindo a complexidade da comunicação e fornecendo resiliência contra falhas em suposições de dureza criptográfica. Uma segunda abordagem é atualizar a chave do razão pkL. Isto tem a vantagem de avançar segurança: O comprometimento de antigos compartilhamentos de pkL (ou seja, antigos nós do comitê) não seria resultar no comprometimento da chave atual. As atualizações do pkL, no entanto, apresentam duas desvantagens: (1) Os dados criptografados sob pkL precisam ser criptografados novamente durante uma atualização de chave e (2) As principais atualizações precisam ser propagadas para terceiros confiáveis. Pretendemos explorar ambas as abordagens, bem como hibridizações das duas. 8.3 DON Responsabilidade Tal como acontece com as redes Chainlink oracle existentes, DONs incluirão mecanismos de responsabilização, ou seja, gravação, monitoramento e aplicação do comportamento correto do nó. DONs terão capacidade de dados muito mais substancial do que muitos blockchains sem permissão existentes, especialmente devido à sua capacidade de conexão com armazenamento descentralizado externo. Consequentemente, eles serão capazes de registrar detalhadamente o histórico de desempenho dos nós, permitindo mecanismos de responsabilização mais refinados. Por exemplo, computação fora da cadeia de os preços dos ativos podem envolver insumos que são descartados antes que um resultado mediano seja enviado cadeia. Em um DON, esses resultados intermediários poderiam ser registrados. O mau comportamento ou falhas de desempenho de nós individuais em um DON podem, portanto, ser remediados ou penalizados em o DON de uma forma refinada. Além disso, discutimos abordagens para construir grades de proteção na Seção 7.3 que abordam o impacto específico do contrato de falhas sistêmicas. Contudo, também é importante ter mecanismos à prova de falhas para os próprios DONs, ou seja, proteções contra falhas DON sistêmicas e potencialmente catastróficas, especificamente falhas de bifurcação/equivocação e acordo de nível de serviço (SLA), como explicamos agora. Bifurcação / equívoco: Dado um número suficiente de nós defeituosos, um DON pode bifurcar ou equívoco, produzindo dois blocos ou sequências de blocos distintos e inconsistentes em L. Entretanto, como um DON assina digitalmente o conteúdo de L, é possível aproveitar um cadeia principal MAINCHAIN para prevenir e/ou penalizar equívocos. O DON pode verificar periodicamente o estado de L em um contrato de auditoria no MAINCHAIN. Se o seu estado futuro se desviar de um estado de checkpoint, um usuário/auditor poderá apresentar prova deste mau comportamento ao contrato de auditoria. Tal prova pode ser usada para gerar um alerta ou penalizar os nós DON por meio de cortes no contrato. Esta última abordagem introduz um problema de design de incentivo semelhante ao de feeds oracle específicos e pode se basear nosso trabalho descrito na Seção 9.Aplicação de acordos de nível de serviço: Embora DONs não sejam necessariamente destinados a executados indefinidamente, é importante que eles cumpram os acordos de nível de serviço (SLAs) com seus usuários. A aplicação básica do SLA é possível em uma cadeia principal. Por exemplo, Os nós DON podem se comprometer a manter o DON até uma determinada data ou a fornecer aviso prévio de rescisão do serviço (por exemplo, aviso prévio de três meses). Um contrato em MAINCHAIN pode fornecer aplicação básica de SLA criptoeconômico. Por exemplo, o contrato SLA pode reduzir os fundos depositados em DON se os pontos de verificação forem não fornecido nos intervalos exigidos. Um usuário pode depositar fundos e desafiar o DON para provar que um ponto de verificação representa corretamente uma sequência de blocos válidos (de uma maneira análogo a, por ex. [141]). É claro que a produção de blocos não significa transação processamento, mas o contrato SLA também pode servir para fazer cumprir este último. Por exemplo, em a versão compatível com legado do FSS, na qual as transações são buscadas no mempool (consulte a Seção 5.2), as transações são eventualmente extraídas e colocadas na cadeia. Um usuário pode provar DON prevaricação fornecendo ao contrato SLA uma transação que foi extraído, mas não foi transmitido pelo DON para processamento pelo contrato alvo dentro do intervalo de tempo apropriado.15 Também é possível provar a existência e penalizar SLAs mais refinados. falhas, incluindo erros na computação usando executáveis (através, por exemplo, dos mecanismos para provar transações estaduais fora da cadeia corretas descritas na Seção 6.3) ou falha na execução executáveis baseados em iniciadores visíveis em um DON, falha na retransmissão de dados em DON para MAINCHAIN em tempo hábil e assim por diante.

Economics and Cryptoeconomics

For the Chainlink network to achieve strong security within a decentralized trust model, it is essential that nodes collectively exhibit correct behavior, meaning that they adhere a majority of the time exactly to DON protocols. In this section, we discuss approaches to helping enforce such behavior by means of economic incentives, a.k.a. cryptoeconomic incentives. These incentives fall into two categories: explicit and implicit, realized respectively through staking and future fee opportunity (FFO). Staking: Staking in Chainlink, as in other blockchain systems, involves network participants, i.e., oracle nodes, depositing locked funds in the form of LINK tokens. These funds, which we also refer to as stake or explicit stake are an explicit incentive. They are subject to forfeiture upon node failure or malfeasance. In the blockchain context, this procedure is often called slashing. Staking by oracle nodes in Chainlink, however, diﬀers fundamentally from staking by validators in permissionless blockchains. Validators can misbehave by equivocating or adversarially ordering transactions. The underlying consensus protocol in a 15As users can replace transactions in the mempool, care is required to ensure a correct correspondence between the mined and DON-submitted transactions.

permissionless blockchain, though, uses hard-and-fast block-validation rules and cryptographic primitives to prevent validators from generating invalid blocks. In contrast, programmatic protections cannot prevent a cheating oracle network from generating invalid reports. The reason is a key diﬀerence between the two types of system: transaction validation in blockchains is a property of internal consistency, while the correctness of oracle reports on a blockchain is a property of external, i.e., oﬀ-chain data. We have designed a preliminary staking mechanism for the Chainlink network based on an interactive protocol among oracle nodes that may make use of external data. This mechanism creates ﬁnancial incentives for correct behavior using explicit rewards and penalties (slashing). As the mechanism is economic, it is designed to prevent node corruption by an adversary that uses ﬁnancial resources to corrupt nodes by means of bribery. (Such an adversary is very general, and extends, e.g., to nodes cooperating to extract value from their collective misbehavior.) The Chainlink staking mechanism we have designed has some powerful and novel features.16 The main such feature is super-linear staking impact (speciﬁcally, quadratic). An adversary must have resources considerably in excess of nodes’ deposited funds in order to subvert the mechanism. Our staking mechanism additionally provides protection against a stronger adversary than previously considered in similar systems, namely an adversary that can create bribes conditioning on nodes’ future behavior. Additionally, we discuss how Chainlink tools such as DECO can help strengthen our staking mechanism by facilitating correct adjudication in the case of faulty node behavior. Future fee opportunity (FFO): Permissionless blockchains—of both the PoW and PoS variety—today rely critically on what we call implicit incentives. These are economic incentives for honest behavior that derive not from explicit rewards, but from platform participation itself. For example, the Bitcoin miner community is incentivized against mounting a 51% attack by the risk of undermining conﬁdence in Bitcoin, depressing its value, and consequently eroding the value of their collective capital investments in mining infrastructure [150]. The Chainlink network beneﬁts from a similar implicit incentive that we refer to as future fee opportunity (FFO). Oracle nodes with strong performance histories or reputations attract fees from users. Misbehavior by an oracle node jeopardizes future fee payments and thus penalizes the node with an opportunity cost in terms of potential revenue earned through participation in the network. By analogy with explicit stake, FFO may be viewed as a form of implicit stake, an incentive for honest behavior that derives from the shared beneﬁt of maintaining conﬁdence in the platform on which node operators’ business depends, i.e., the positive performance and reputation of the network. This incentive is inherent in but not explicitly expressed in Chainlink network protocols. In Bitcoin, maintaining the value of mining operations as mentioned above 16The staking mechanism we describe here currently aims only to enforce delivery of correct reports by oracle networks. We expect in future work to extend it to ensure correct execution of the many other functionalities DONs will provide.

may similarly be viewed as a form of implicit stake. We emphasize that FFO already exists in Chainlink and helps secure the network today. Our main contribution in the further development of Chainlink will be a principled, empirically driven approach to evaluating implicit incentives such as FFO through what we call the Implicit-Incentive Framework (IIF). To estimate quantities such as the future fee opportunity of nodes, the IIF will draw continuously on the comprehensive performance and payment data amassed by the Chainlink network. Such estimates will enable IIF-based parameterization of staking systems that reﬂects node incentives with greater accuracy than current heuristic and/or static models. To summarize, then, the two main economic incentives for correct oracle node behavior in the developing Chainlink network will be: • Staking (deposited stake) o Explicit incentive • Future fee opportunity (FFO) o Implicit incentive These two forms of incentive are complementary. Oracle nodes can simultaneously participate in the Chainlink staking protocol, enjoy an ongoing revenue stream from users, and collectively beneﬁt from their continued good behavior. Thus both incentives contribute to the cryptoeconomic security provided by an oracle network. Additionally, the two incentives can reinforce and/or be traded oﬀagainst one another. For example, a new oracle operator without a performance history and revenue stream can stake a large quantity of LINK as a guarantee of honest behavior, thereby attracting users and fees. Conversely, an established oracle operator with a long, relatively fault-free performance history can charge substantial fees from a large user base and thus rely more heavily on its FFO as a form of implicit incentive. In general, the approach we consider here aims for a given amount of oracle-network resource to create the greatest possible economic incentives in Chainlink for rational agents—i.e., nodes maximizing their ﬁnancial utility—to behave honestly. Put another way, the goal is to maximize the ﬁnancial resources required for an adversary to attack the network successfully. By formulating a staking protocol with mathematically well deﬁned economic security and also using the IIF, we aim to measure the strength of Chainlink’s incentives as accurately as possible. The creators of relying contracts will then be able to determine with strong conﬁdence whether an oracle network meets their required levels of cryptoeconomic security. The virtuous cycle of economic security: The incentives we discuss in this section, staking and FFO, have an impact beyond their reinforcement of the security of DONs. They promise to induce what we call a virtuous cycle of economic security. Super-linear staking impact (and other economies of scale) result in lower operational cost as a DON’s security grows. Lower cost attracts additional users to the DON,

boosting fee payments. A rise in fee payments continues to incentivize growth of the network, which perpetuates the virtuous cycle. We believe that the virtuous cycle of economic security is just one example of an economy of scale and network eﬀect among others that we discuss later in this section. Section organization: Staking presents notable technical and conceptual challenges for which we have designed a mechanism with novel features. Staking will therefore be our main focus in this section. We give an overview of the staking approach we introduce in this paper in Section 9.1, followed by detailed discussion in Sections 9.2 to 9.5. We present the IFF in Section 9.6. We present a summary view of Chainlink network incentives in Section 9.7. In Section 9.8, we discuss the virtuous cycle of economic security our proposed staking approach can bring to oracle networks. Finally, we brieﬂy describe other potential eﬀects propelling growth of the Chainlink network in Section 9.9. 9.1 Staking Overview The staking mechanism design we introduce here, as noted above, involves an interactive protocol among oracle nodes allowing for resolution of inconsistencies in the reporting of external data. Staking aims to ensure honest behavior from rational oracle nodes. We can therefore model an adversary attacking a staking protocol as a briber: The adversary’s strategy is to corrupt oracle nodes using ﬁnancial incentives. The adversary may derive ﬁnancial resources prospectively from successfully tampering with an oracle report, e.g., oﬀer to share the resulting proﬁt with corrupted nodes. We aim in our staking mechanism design simultaneously at two ambitious goals: 1. Resisting a powerful adversary: The staking mechanism is designed to protect oracle networks against a broad class of adversaries that are capable of complex, conditional bribing strategies, including prospective bribery, which oﬀers bribes to oracles whose identities are determined after the fact (e.g., oﬀers bribes to oracles randomly selected for high-priority alerting). While other oracle designs have considered a narrow set of attacks without the full capabilities of a realistic adversary, to the best of our knowledge the adversarial mechanism we introduce here is the ﬁrst to explicitly address a broad set of bribing strategies and show resistance in this model. Our model assumes that nodes besides the attacker are economically rational (as opposed to honest), and we assume the existence of a source of truth that is prohibitively expensive for typical usage but is available in case of disagreement (discussed further below). 2. Achieving super-linear staking impact: Our aim is to ensure that an oracle network composed of rational agents reports truthfully even in the presence of an attacker with a budget that is super-linear

in the total stake deposited by the entire network. In existing staking systems, if each of n nodes stakes $d, an attacker can issue a credible bribe which requests that nodes behave dishonestly in exchange for a payment of slightly more than $d to each node, using a total budget of about $dn. This is already a high bar as the attacker has to have a liquid budget on the order of the combined deposits of all stakers in the network. Our goal is a still stronger degree of economic security than this already substantial hurdle. We aim to design the ﬁrst staking system that can achieve security for a general attacker with a budget super-linear in n. While practical considerations may achieve a lower impact, as we discuss below, our preliminary design achieves an adversarial budget requirement greater than $dn2/2, i.e., scaling quadratic in n, rendering bribery largely impractical even when nodes stake only moderate amounts. Reaching these two goals requires an innovative combination of incentive design and cryptography. Key ideas: Our staking approach hinges on an idea we call watchdog priority. A report generated by a Chainlink oracle network and sent to a relying contract (e.g., on an asset price) is aggregated from individual reports contributed by participating nodes (e.g., by taking the median). Typically a service-level agreement (SLA) speciﬁes acceptable bounds of deviation for reports, i.e., how far a node’s report can deviate from the aggregate report and how far the aggregate should be permitted to deviate from the true value to be considered correct. In our staking system, for a given reporting round, each oracle node can act as a watchdog to raise an alert if it believes the aggregate report is incorrect. In each reporting round, each oracle node is assigned a public priority that determines the order in which its alert (if any) will be processed. Our mechanism aims at reward concentration, meaning that the highest-priority watchdog to raise an alert earns the entire reward yielded by conﬁscating the deposits of faulty nodes. Our staking system designs involve two tiers: the ﬁrst, default tier, and the second, backstop tier. The ﬁrst tier is the oracle network itself, a set of n nodes. (For simplicity, we assume n is odd.) If a majority of nodes report incorrect values, a watchdog in the ﬁrst tier is strongly incentivized to raise an alert. If an alert is raised, the reporting decision of the network is then escalated to a second tier—a high-cost, maximumreliability system that can be user-speciﬁed in the network service-level agreement. This could be a system which, for example, is composed only of nodes with strong historical reliability scores, or one that has an order of magnitude more oracles than the ﬁrst tier. Additionally, as discussed in Section 9.4.3, DECO or Town Crier can serve as powerful tools to help ensure eﬃcient and conclusive adjudication in the second tier. For simplicity we thus assume that this second-tier system arrives at a correct report value. While it might seem attractive just to rely on the second tier to generate all reports, the beneﬁt of our design is that it consistently achieves the security properties of the

second-tier system while only paying the operating cost, in the typical case, of the ﬁrst-tier system. Watchdog priority results in super-linear staking impact in the following way: if the ﬁrst-tier oracle network outputs an incorrect result and a number of watchdog nodes alert, the staking incentive mechanism rewards the highest-priority watchdog with more than $dn/2 drawn from the deposits of the (majority) misbehaving nodes. The total reward is thus concentrated in the hands of this single watchdog, which therefore determines the minimum that an adversary must promise a potential watchdog to incentivize it not to alert. Since our mechanism ensures that every oracle gets the chance to act as watchdog if the higher-priority watchdogs have accepted their bribes (and chosen not to alert), the adversary must therefore oﬀer a bribe of more than $dn/2 to every node to prevent any alert being raised. Since there are n nodes, the adversary’s requisite budget for a successful bribe amounts to more than $dn2/2, which is quadratic in the number n of nodes in the network. 9.2 Background Our approach to staking draws on research in the ﬁelds of game theory and mechanism design (MD) (for a textbook reference, see [177]). Game theory is the mathematically formalized study of strategic interaction. In this context, a game is a model of such an interaction, typically in the real world, that codiﬁes sets of actions available to participants in the game, known as players. A game also speciﬁes the payoﬀs obtained by the individual players—rewards that depend on a player’s chosen actions and the actions of the other players. Perhaps the best known example of a game studied in game theory is the Prisoners’ Dilemma [178]. Game theorists generally aim to understand the equilibrium or equilibria (if any) represented in a given game. An equilibrium is a set of strategies (one for each player) such that no one player can obtain a higher payoﬀby unilaterally deviating from its strategy. Mechanism design, meanwhile, is the science of designing incentives such that the equilibrium of an interaction (and its associated game) has some desirable property. MD may be viewed as the inverse of game theory: The canonical question in game theory is, “given the incentives and model, what will the equilibrium be?” In MD, the question is instead, “what incentives will result in a game with a desirable equilibrium?” A typical goal of a mechanism designer is to create an ‘incentive compatible’ mechanism, meaning that participants in the mechanism (e.g., an auction or other information elicitation system [228]) are incentivized to report the truth on some matter (e.g., how much they value a particular item). The Vickrey (second-price) auction is perhaps the best known incentive compatible mechanism, in which participants submit sealed bids for an item and the highest bidder wins the item but pays the second-highest price [214]. Cryptoeconomics is a domain-speciﬁc form of MD that leverages cryptographic techniques to create desirable equilibria within decentralized systems. Bribery and collusion create signiﬁcant challenges throughout the ﬁeld of MD. Almost all mechanisms break in the presence of collusion, deﬁned as side contracts be-

tween the parties participating in a mechanism [125, 130]. Bribery, in which an external party introduces novel incentives into the game, presents an even tougher problem than does collusion; collusion may be viewed as a special case of bribery among game participants. Blockchain systems can often be conceptualized as games with monetary (cryptocurrencybased) payoﬀs. A simple example is Proof-of-Work mining: miners have an action space in which they can choose the hashrate with which to mine for blocks. The payoﬀof mining is a guaranteed negative reward (cost of electricity and equipment) plus a stochastic positive reward (mining subsidy) that depends on the number of other active miners [106, 172] and transaction fees. Crowdsourced oracles like SchellingCoin [68] are another example: the action space is the set of possible reports an oracle may send, while the payoﬀis the reward speciﬁed by the oracle mechanism, e.g., payment might depend on how close an oracle’s report is to the median of the other reports [26, 68, 119, 185]. Blockchain games oﬀer ripe opportunities for collusion and bribery attacks; indeed, smart contracts can even facilitate such attacks [96, 165]. Perhaps the best known bribery attack on crowdsourced oracles is the p-plus-epsilon attack [67]. This attack arises in the context of a SchellingCoin-like mechanism in which players submit booleanvalued reports (i.e., false or true) and are rewarded with p if they agree with the majority submission. In a p-plus-epsilon attack, the attacker credibly promises to, e.g., pay users $p + ϵ for voting false if and only if the majority submission is true. The result is an equilibrium, in which all players are incentivized to report false irrespective of what other players do; consequently, the briber can induce the nodes through its promised bribe to report false without actually paying the bribe (!). Exploration of other briber strategies in the context of oracles, however—and particularly oracles that are not crowdsourced—has been limited to fairly weak adversarial models. For example, in the PoW setting, researchers have studied outcome-contingent bribes, i.e., bribes paid only if a target message is successfully censored and does not appear in a block, irrespective of an individual miner’s action [96, 165]. In the case of oracles, however, other than the p-plus-epsilon attack, we are aware only of work in a strictly limited model of bribery in which a briber sends a bribe conditioned on an individual player’s action, not on the resulting outcome. Here we sketch designs of information-elicitation mechanisms that remain incentive compatible even in a strong adversarial model, as described in the next subsection. 9.3 Modeling Assumptions In this subsection, we explain how we model the behavior and capabilities of players in our system, speciﬁcally ﬁrst-tier oracle nodes, nodes in the second-tier (adjudication) layer, and adversaries.

9.3.1 First-Tier Incentive Model: Rational Actors Many blockchain systems rely for security on the assumption of some number of honest participating nodes. Nodes are deﬁned to be honest if they follow the protocol even when it is not in their ﬁnancial interest to do so. Proof-of-Work systems typically require the majority of hash power to be honest, Proof-of-Stake systems typically require $2/3$ or more of all participating stake to be honest, and even layer-2 systems like Arbitrum [141] require at least a single honest participant. In modeling for our staking mechanism, we make a much weaker assumption. (To be clear, weaker assumptions mean stronger security properties and are therefore preferable.) We assume that the adversary has corrupted, i.e., controls, some (minority) fraction of ﬁrst-tier oracle nodes. We model the remaining nodes not as honest agents, but as rational expected-utility maximizers. These nodes act entirely according to selfinterested ﬁnancial incentives, choosing actions that result in an expected ﬁnancial gain. For example, if a node is oﬀered a bribe larger than the reward resulting from honest behavior, it will accept the bribe. Note on adversarial nodes: In accordance with the trust modeling common for decentralized systems, we assume that all nodes are rational, i.e., seeking to maximize net revenue, rather than controlled by a malicious adversary. Our claims, however— speciﬁcally super-linear or quadratic staking impact—hold asymptotically provided that the set of adversarially controlled nodes is at most $(1/2 - c)n$, for some positive constant $c$. 9.3.2 Second-Tier Adjudication Model: Correctness by Assumption Recall that a critical feature of our staking mechanism that helps achieve security against rational nodes is its second-tier system. In our proposed staking mechanism, any oracle may raise an alert indicating that it believes the output of the mechanism is incorrect. An alert results in a high-trust second-tier system activating and reporting the correct result. Thus, a key modeling requirement for our approach is correct adjudication, i.e., correct reporting by the second-tier system. Our staking model assumes a second-tier system that acts as an incorruptible, maximally reliable source of truth. Such a system is likely to be expensive and slow, and thus inappropriate for use for the typical case. In the equilibrium case, however, i.e., when the ﬁrst-tier system functions correctly, the second-tier system will not be invoked. Instead, its existence boosts the security of the whole oracle system by providing a high-assurance backstop. The use of a high-trust, high-cost adjudication layer resembles the appeals process at the heart of most judicial systems. It is also already common in the design of oracle systems, e.g., [119, 185]. We brieﬂy discuss approaches to realization of the second tier in our mechanism in Section 9.4.3.

Our staking protocol uses the assumed correct adjudication of the second-tier system as a credible threat to enforce correct reporting by oracle nodes. The protocol conﬁscates part or all of the stake of oracle nodes that generate reports identiﬁed by the second-tier system as incorrect. Oracle nodes are thus deterred from misbehaving by the resulting ﬁnancial penalty. This approach is similar in ﬂavor to that used in optimistic rollups, e.g., [141, 10]. 9.3.3 Adversarial Model Our staking mechanism is designed to elicit truthful information while achieving security against a broad, well-deﬁned class of adversaries. It improves upon prior works, which either omit an explicit adversarial model or focus on narrow sub-classes of adversaries, e.g., the p-plus-epsilon adversary discussed above. Our goal is to design a staking mechanism with formally proven security against the full spectrum of adversaries likely to be encountered in practice. We model our adversary as having a ﬁxed (parameterizable) budget, denoted by $B. The adversary can communicate individually and conﬁdentially with each oracle in the network, and can secretly oﬀer any individual oracle guaranteed payment of a bribe contingent on publicly observable outcomes of the mechanism. Outcomes determining bribes can include, for example, the value reported by the oracle, any public messages sent by any oracle to the mechanism (e.g., an alert), the values reported by other oracles, and the value output by the mechanism. No mechanism can secure against an attacker with unlimited capabilities. We therefore consider some behaviors as unrealistic or out-of-scope. We assume our attacker cannot break standard cryptographic primitives, and, as noted above, has a ﬁxed (if potentially large) budget $B. We further assume that the adversary does not control communication in the oracle network, speciﬁcally that it cannot substantially delay traﬃc between ﬁrst-tier and/or second-tier nodes. (Whether the adversary can observe such communication depends on the particular mechanism, as we explain below.) Informally, however, as noted above, we assume that the adversary can: (1) Corrupt a fraction of oracle nodes ($(1/2 - c)$-fraction for some constant $c$), i.e., fully control them, and (2) Oﬀer bribes to any desired nodes, with guaranteed payment contingent on outcomes speciﬁed by the adversary, as described above. While we don’t oﬀer a formal model or complete taxonomy of the adversary’s full range of bribing capabilities in this whitepaper, here are examples of the kinds of bribers encompassed by our model. For simplicity, we assume that oracles emit Boolean reports whose correct value (w.l.o.g.) is true, and that a ﬁnal outcome is computed as an aggregate of these reports to be used by a consuming smart contract. The briber’s aim is for the ﬁnal outcome to be incorrect, i.e., false. • Unconditional briber: Briber oﬀers bribe $b to any oracle that reports false. • Probabilistic briber: Briber oﬀers bribe $b with some probability q to any oracle that reports false.

• false-outcome conditioned briber: Briber oﬀers bribe $b to any oracle that reports false provided that the ﬁnal outcome is false. • No-alert-conditioned briber: Briber oﬀers bribe $b to any oracle that reports false as long as no alert is raised. • p-plus-epsilon Briber: Briber oﬀers bribe $b to any oracle that reports false as long as the majority of oracles do not report false. • Prospective briber: Briber oﬀers bribe $b in advance to whichever oracle is selected for a randomized role and reports false. In our proposed staking protocol, all nodes act as potential watchdogs, and we are able to show that randomization of watchdog priorities does not lend itself to prospective bribery. Many proofof-work, proof-of-stake, and permissioned systems are susceptible to prospective bribery, however, which shows the importance of considering it in our adversarial model and ensuring that our staking protocols are resilient to it. See Appendix E for more details. 9.3.4 How Much Cryptoeconomic Security Is Enough? A rational adversary will only spend money to attack a system if it can obtain a proﬁt larger than its expenditure. Thus for our adversarial model and proposed staking mechanism, $B may be viewed as a measure of the potential proﬁt an adversary is able to extract from relying smart contracts by corrupting an oracle network and causing it to generate an incorrect report or set of reports. In deciding whether an oracle network oﬀers a suﬃcient degree of cryptoeconomic security for their purposes, a user should assess the network from this perspective. For plausible adversaries in practical settings, we expect that $B will generally be substantially smaller than the total assets in relying smart contracts. In most cases, it is infeasible for an adversary to extract these assets in their totality. 9.4 Staking Mechanism: Sketch Here we present the main ideas and general structure of the staking mechanism we are currently considering. For ease of presentation, we describe a simple but slow (multi-round) protocol in this subsection. We note, however, that this scheme is quite practical. Given the economic assurances provided by the mechanism, i.e., the penalization of and consequent incentive against faulty nodes, many users may be willing to accept reports optimistically. In other words, such users may accept reports prior to potential adjudication by the second tier. Users unwilling to accept reports optimistically can choose to wait until the protocol execution terminates, i.e., until any potential escalation to the second tier occurs. This, however, can substantially slow the conﬁrmation time for reports. We therefore brieﬂy

Schematic of Chainlink staking scheme with alerting showing watchdog escalation and penalty mechanisms

Figure 15: Schematic of staking scheme with alerting. In this example, 1⃝a majority of nodes are corrupted / bribed and emit an incorrect value ˜r, rather than the correct report value r. The watchdog node 2⃝sends an alert to the second-tier committee, which 3⃝determines and emits the correct report value r, resulting in corrupted nodes forfeiting their deposits—each $d to the watchdog node 4⃝. outline some optimizations that result in a faster (single-round) if somewhat more complex design in Section 9.5. Recall that the ﬁrst tier in our staking mechanism consists of the basic oracle network itself. The main structure of our mechanism, as described above, is that in each round, each node can act as a “watchdog” with some priority, and it thus has the ability to raise an alert if the mechanism arrives at an incorrect output ˜r, rather than a correct one r. This alert causes second-tier resolution, which we assume arrives at a correct report. Nodes with incorrect reports are punished, in the sense that their stakes are slashed and awarded to watchdogs. This basic structure is common in oracle systems, as in, e.g., [119, 185]. The key innovation in our design, mentioned brieﬂy above, is that every node is assigned a distinct priority in the ordering of potential watchdogs. That is, watchdogs are given opportunities to alert in priority sequence. Recall that if a node has the highest priority to raise an alert, it receives the slashed deposit $d of every misbehaving node, for a total of more than $dn/2 = $d × n/2, as an incorrect report implies a majority of bad nodes. Consequently, the adversary must pay at least this reward to bribe an arbitrary node. Thus, to bribe a majority of nodes, the adversary must pay a large bribe to a majority of nodes, namely, strictly more than $dn2/2. We show schematically how alerting and watchdog escalation works in Fig. 15.

9.4.1 Further Mechanism Details The bribery-resistant system we now describe in further detail is a simpliﬁed sketch of the two-tiered construction we intend to build. Most of our focus will be on describing the ﬁrst-tier network (henceforth simply “network” where clear from context) along with its incentive mechanism and the procedure for escalation to the second tier. Consider a Chainlink network composed of n oracle nodes that are responsible for regularly (e.g., once a minute) reporting a boolean value (e.g., whether the market capitalization of BTC exceeds that of ETH). As part of the staking mechanism, nodes must provide two deposits: a deposit $d subject to slashing in the event of disagreement with the majority and a watchdog deposit $dw subject to slashing in the event of a faulty escalation. We assume that the nodes cannot copy the submissions of other nodes, e.g., through a commit-reveal scheme as discussed in Section 5.3. In each round, nodes ﬁrst commit to their report, and once all nodes have committed (or a timeout has expired), nodes reveal their reports. For each report to be generated, every node is also given a watchdog priority between 1 and n chosen at random, with 1 being top priority. This priority enables the concentration of reward in the hands of one watchdog. After all reports are public, an alerting phase ensues. Over a sequence of n (synchronous) rounds, the node with priority i has the opportunity to alert in round i. Let us consider the possible outcomes for the mechanism after nodes have revealed their reports. Again assuming a binary report, suppose the correct value is true and the incorrect one is false. Suppose also that the ﬁrst-tier mechanism outputs the majority value output by nodes as the ﬁnal report r. There are three possible outcomes in the mechanism: • Complete agreement: In the best case, nodes are in complete agreement: all nodes are available and have provided a timely report of the same value r (either true or false). In this case, the network need only forward r to relying contracts and reward each node with a ﬁxed per-round payment $p, which is much smaller than $d. • Partial agreement: It is possible that some nodes are oﬄine or there is disagreement about which value is correct, but most nodes report true and only a minority reports false. This case is also straightforward. The majority value (true) is computed, resulting in a correct report r. All nodes that reported r are rewarded with $p while the oracles that reported incorrectly have their deposits slashed modestly, e.g., by $10p. • Alert: In the event that a watchdog believes the output of the network is incorrect, it publicly triggers an alert, escalating the mechanism to the second-tier network. There are then two possible results: – Correct alert: If the second-tier network conﬁrms that the output of the

Diagram showing how concentrated alerting rewards amplify the cost for a briber attempting to corrupt the oracle network

Figure 16: Amplifying briber’s cost through concentrated alerting rewards. A bribing adversary must bribe each node with more than the reward it stands to gain by alerting (shown as a red bar). If alerting rewards are shared, then this reward may be relatively small. Concentrated alerting rewards increase the reward that any single node may obtain (tall red bar). Consequently the total payout by the adversary for a viable bribe (gray regions) is much larger with concentrated than shared alerting rewards. ﬁrst-tier network was incorrect, the alerting watchdog node receives a reward consisting of all slashed deposits, and thus more than $dn/2. – Faulty alert: If the second-tier and ﬁrst-tier oracles agree, the escalation is deemed faulty and the alerting node loses its $dw deposit. In the case of optimistic acceptance of reports, watchdog alerts do not cause any change in execution of relying contracts. For contracts designed to await potential arbitration by the second-tier committee, watchdog alerts delay but do not freeze contract execution. It is also possible for contracts to designate a failover DON for periods of adjudication. 9.4.2 Quadratic Staking Impact The ability for every node to act as a watchdog, combined with strict node priority ensuring concentrated rewards, enables the mechanism to achieve quadratic staking impact for each kind of bribing attacker described in Section 9.3.3. Recall that this means speciﬁcally in our setting that, for a network with n nodes each with deposit $d, a successful briber (of any of the kinds above) must have a budget of bigger than $dn2/2. To be precise, the briber must corrupt at least (n+1)/2 nodes, since the briber must corrupt a majority of n nodes (for odd n, by assumption). Thus, a watchdog stands to earn a reward of $d(n + 1)/2. The briber consequently must pay this amount to every

node to ensure that none acts as a watchdog. We are working to show formally that if the briber has a budget of at most $d(n2 + n)/2, then the subgame perfect equilibrium of the game between the bribers and the oracles—in other words, the equilibrium at any point during the play of the game—is for the briber not to issue the bribe and for each oracle to report its true values honestly. We have explained above how it is possible that a successful briber could require a budget signiﬁcantly larger than that of the sum of the node deposits. To illustrate this intuitive result, Fig. 16 shows the impact of concentrated alert rewards graphically. As we see there, if the reward for watchdog alerting—namely the deposits of bribed nodes reporting false)—were split among all potential alerting, the total amount that any individual alerting node could expect would be relatively small, on the order of $d. A briber, knowing that a payout of larger than $d was improbable, could use a false-outcome conditional bribe to bribe each of n nodes with slightly more than $d + ϵ. Counterintuitively, Fig. 16 shows that a system that distributes a reward broadly among nodes signaling an alert is far weaker than one that concentrates the reward in the hands of a single watchdog. Example parameters: Consider a (ﬁrst-tier) network with n = 100 nodes, each depositing $d = $20K. This network would have a total of $2M deposited but would be protected against a briber with budget $100M = $dn2/2. Increasing the number of oracles is more eﬀective than increasing $d, of course, and can have a dramatic eﬀect: a network with n = 300 nodes and deposits $d = $20K would be protected against a briber with budget up to $900M. Note that a staking system can in many cases protect smart contracts representing more value than the oﬀered level of bribery protection. This is because an adversary attacking these contracts cannot extract the full value in many cases. For example, a Chainlink-powered contract securing $1B in value may only require security against a briber with $100M in resource because such an adversary can feasibly extract a proﬁt of only 10% of the value of the contract. Note: The idea that the value of a network can grow quadratically is expressed in the well known Metcalfe’s Law [167, 235], which states that the value of a network grows quadratically in the number of connected entities. Metcalfe’s Law, however, arises from growth in the number of potential pairwise network connections, a different phenomenon than that underlying quadratic staking impact in our incentive mechanism. 9.4.3 Realization of Second Tier Two operational features facilitate realization of a high-reliability second tier: (1) Second-tier adjudication should be a rare event in oracle networks and therefore can be signiﬁcantly more costly than normal operation of the ﬁrst tier and (2) Assuming

optimistically accepted reports—or contracts whose execution can await arbitration— the second tier need not execute in real time. These features result in a range of conﬁguration options for the second tier to meet the requirements of particular DONs. As an example approach, a second tier committee can consist of nodes selected by a DON (i.e., ﬁrst tier) from the longest-serving and most reliable nodes in the Chainlink network. In addition to considerable relevant operational experience, the operators of such nodes have a considerable implicit incentive in FFO that motivates a desire to ensure that the Chainlink network remains highly reliable. They also have publicly available performance histories that provide transparency into their reliability. Secondtier nodes, it is worth noting, need not be participants in the ﬁrst-tier network, and may adjudicate faults across multiple ﬁrst-tier networks. Nodes in a given DON can pre-designate and publicly commit to a set of n′ such nodes as constituting the second-tier committee for that DON. Additionally, DON nodes publish a parameter k′ ≤n′ that determines the number of second-tier votes required to penalize a ﬁrst-tier node. When an alert is generated for a given report, the members of the second tier vote on the correctness of the values provided by each of the ﬁrst-tier nodes. Any ﬁrst-tier node that receives k′ negative votes forfeits its deposits to the watchdog node. Because of the rareness of adjudication and opportunity for extended-time execution noted above, in contrast to the ﬁrst tier, nodes in the second tier can: 1. Be highly compensated for conducting adjudication. 2. Draw on additional data sources, beyond even the diverse set used by the ﬁrsttier. 3. Rely on manual and/or expert inspection and intervention, e.g., to identify and reconcile errors in source data and distinguish between an honest node relaying faulty data and a misbehaving node. We emphasize that the approach we have just described for selection of secondtier nodes and policy governing adjudication represents just a point within a large design space of possible realizations of the second tier. Our incentive mechanism oﬀers complete ﬂexibility as to how the second tier is realized. Individual DONs can thus constitute and set rules for their second tiers that meet the particular requirements and expectations of participating nodes and users. DECO and Town Crier as adjudication tools: It is essential for the second tier in our mechanism to be able to distinguish between adversarial ﬁrst-tier nodes that intentionally produce incorrect reports and honest ﬁrst-tier nodes that unintentionally relay data that is incorrect at the source. Only then can the second tier implement slashing to disincentivize cheating, the goal of our mechanism. DECO and Town Crier are powerful tools that can enable second-tier nodes to make this critical distinction reliably.

Second-tier nodes may in some cases be able to directly query the data source used by a ﬁrst-tier node or use ADO Section 7.1 in order to check whether an incorrect report resulted from a faulty data source. In other cases, however, second tier nodes may lack direct access to a ﬁrst-tier node’s data source. In such cases, correct adjudication would appear to be infeasible or require a reliance on subjective judgment. Previous oracle dispute systems have relied upon ineﬃcient, escalating rounds of voting to address such challenges. Using DECO or Town Crier, however, a ﬁrst tier node can prove correct behavior to second-tier nodes. (See Section 3.6.2 for details on the two systems.) Speciﬁcally, if the second tier node identiﬁes a ﬁrst-tier node as having output a faulty report value ˜r, the ﬁrst-tier node can use DECO or Town Crier to generate tamperproof evidence for second-tier nodes that it is correctly relaying ˜r correctly from a (TLS-enabled) source recognized as authoritative by the DON. Critically, the ﬁrst-tier node can do this without second-tier nodes requiring direct access to the data source.17 Consequently, correct adjudication is feasible in Chainlink for any desired data source. 9.4.4 Misreporting Insurance The strong bribery resistance achieved by our staking mechanism relies fundamentally on slashed funds being awarded to alerters. Without a monetary reward, alerters would have no direct incentive to reject bribes. As a result, however, slashed funds are not available to compensate users harmed by incorrect reports, e.g., users that lose money when incorrect price data is relayed to a smart contract. By assumption, incorrect reports don’t pose a problem if reports are accepted by a contract only after potential adjudication, i.e., action by the second tier. As explained above, though, to achieve the best possible performance, contracts may instead rely optimistically on the mechanism to enforce correct reporting, meaning that they accept reports before potential second-tier adjudication. Indeed, such optimistic behavior is safe in our model assuming rational adversaries whose budgets do not exceed the staking impact of the mechanism. Users concerned about the improbable event of a mechanism failure resulting from, e.g., adversaries with overwhelming ﬁnancial resources, may wish to employ an additional layer of economic security in the form of misreporting insurance. We know of multiple insurers already intending to oﬀer smart-contract-backed policies of this kind for Chainlink-secured protocols in the near future, including through innovative mechanisms such as DAOs, e.g., [7]. The existence of performance history for Chainlink nodes and other data about nodes such as their stake amounts provides an exceptionally strong basis for actuarial assessments of risk, making it possible to price policies in ways that are inexpensive for policyholders yet sustainable for insurers. 17With Town Crier, it is additionally possible for ﬁrst-tier nodes to locally generate attestations of correctness for the reports they output and provide these attestations to second-tier nodes on an as-needed basis.

Basic forms of misreporting insurance can be implemented in a trustworthy and eﬃcient manner using smart contracts. As a simple example, a parametric insurance contract SCins can compensate policyholders automatically if our incentive mechanism’s second tier identiﬁes an error in a report generated in the ﬁrst tier. A user U that wishes to purchase an insurance policy, e.g., the creator of a target contract SC, can submit a request to a decentralized insurer for an policy amount $M on the contract. On approving U, the insurer can set an ongoing (e.g., monthly) premium of $P in SCins. While U pays the premium, her policy remains active. If a reporting failure occurs in SC, the result will be the emission of a pair (r1, r2) of conﬂicting reports for SC, where r1 is signed by the ﬁrst tier in our mechanism and r2, the corresponding corrected report, is signed by the second tier. If the U furnishes such a valid pair (r1, r2) to SCins, the contract automatically pays her $M, provided her premium payments are up-to-date. 9.5 Single-Round Variant The protocol described in the previous subsection requires that the second-tier committee wait n rounds to determine whether a watchdog has raised an alert. This requirement holds even in the optimistic case, i.e., when the ﬁrst tier is functioning correctly. For users unwilling to accept reports optimistically, i.e., prior to potential adjudication, the delay associated with that approach would be unworkable. For this reason, we are also exploring alternative protocols that require just one round. In this approach, all oracle nodes submit secret bits indicating whether or not they wish to raise an alert. The second-tier committee then checks these values in priority order. To provide a rough sketch, such a scheme might involve the following steps: 1. Watchdog bit submission: Each node Oi secret-shares a one-bit watchdog value wi ∈{no alert, alert} among nodes in the second tier for every report it generates. 2. Anonymous tips: Any oracle node can submit an anonymous tip α to the secondtier committee in the same round that watchdog bits are submitted. This tip α is a message indicating that an alert has been raised for the current report. 3. Watchdog bit checking: The second-tier committee reveals oracle nodes’ watchdog bits in priority order. Note that nodes must send no alert watchdog bits when they don’t alert: otherwise, traﬃc analysis reveals all nodes’ bits. The protocol does reveal the no alert watchdog bits of nodes with higher priority than the highest-priority alerting watchdog. Observe that what is revealed is identical with that of our n-round protocol. Rewards are also distributed identically with that scheme, i.e., the ﬁrst identiﬁed watchdog receives the slashed deposits of nodes that have submitted incorrect reports.

The use of anonymous tips enables the second-tier committee to remain noninteractive in cases where no alert has been raised, reducing communication complexity in the common case. Note that any watchdog that raises an alert has an economic incentive to submit an anonymous tip: If no tip is submitted, no reward is paid to any node. To ensure that the sender Oi of an anonymous tip α cannot be identiﬁed by the adversary based on network data, the anonymous tip can be sent over an anonymous channel, e.g, via Tor, or, more practically, proxied via a cloud service provider. To authenticate the tip as originating with O, Oi can sign α using a ring signature [39, 192]. Alternatively, to prevent unattributable denial-of-service attacks against the secondtier committee by a malicious oracle node, α can be an anonymous credential with revocable anonymity [73]. This protocol, while practically achievable, has somewhat heavyweight engineering requirements (which we are exploring ways to reduce). First-tier nodes, for instance, must communicate directly with second-tier nodes, requiring maintenance of a directory. The need for anonymous channels and ring signatures adds to the engineering complexity of the scheme. Finally, there is a special trust requirement brieﬂy discussed in the note below. We are therefore also exploring simpler schemes that still achieve super-linear staking impact, but perhaps less than quadratic, in which a briber asymptotically needs resources of at least $n log n, for example. Some of the schemes under consideration involve random selection of a strict subset of nodes to act as watchdogs, in which case prospective bribery becomes an especially powerful attack. Remark: The security of this single-round staking mechanism requires untappable channels between oracle and second-tier nodes—a standard requirement in coercionresistant systems, e.g., voting [82, 138], and a reasonable one in practice. Additionally, however, a node Oi that seeks to cooperate with a briber can construct its secret shares in such a way as to show the briber that it has encoded a particular value. For example, if Oi does not know which nodes the briber controls, then Oi can submit 0-valued shares to all committee members. The briber can then verify Oi’s compliance probabilistically. To avoid this problem in any single-round protocol, we require that Oi know the identity of at least one honest second-tier node. With an interactive protocol in which each second-tier node adds a randomization factor to shares, the best the briber can do is enforce selection by Oi of a random watchdog bit. 9.6 Implicit-Incentive Framework (IIF) FFO is a form of implicit incentive for correct behavior in the Chainlink network. It functions like explicit stake, i.e., deposits, in that it helps enforce economic security for the network. In other words, FFO should be included as part of the (eﬀective) deposit $d of a node in the network.

The question is: How do we measure FFO and other forms of implicit incentive within the Chainlink network? The Implicit-Incentive Framework (IIF) is a set of principles and techniques that we plan to develop for this purpose. Blockchain systems provide many forms of unprecedented transparency, and the high-trust records of node performance they create are a springboard for our vision of how the IIF will work. Here we very brieﬂy sketch ideas on key elements of the IIF. The IIF itself will consist of a set of factors we identify as important in evaluating implicit incentives, along with mechanisms for publishing relevant data in a highassurance form for consumption by analytics algorithms. Diﬀerent Chainlink users may wish to use the IIF in diﬀerent ways, e.g., giving diﬀerent weighting to diﬀerent factors. We expect analytics services to arise in the community that help users apply the IIF according to their individual risk-evaluation preferences, and our goal is to facilitate such services by ensuring their access to high-assurance and timely supporting data, as we discuss below (Section 9.6.4). 9.6.1 Future Fee Opportunity Nodes participate in the Chainlink ecosystem to earn a share of the fees that the networks pay out for any of the various services we have described in this paper, from ordinary data feeds to advanced services such as decentralized identity, fair sequencing, and conﬁdentiality-preserving DeFi. Fees in the Chainlink network support node operators’ costs for, e.g., running servers, acquiring necessary data licenses, and maintaining a global staﬀto ensure high uptime. FFO denotes the service fees, net of expenses, that a node stands to gain in the future—or lose should it demonstrate faulty behavior. FFO is a form of stake that helps secure the network. A helpful feature of FFO is the fact that on-chain data (supplemented by oﬀ-chain data) establish a high-trust record of a node’s history, enabling computation of FFO in a transparent, empirically driven manner. A simple, ﬁrst-order measure of FFO can derive from the average net revenue of a node over a period of time (i.e., gross revenue minus operating expenses). FFO may then be calculated as, e.g., the net present value [114] of cumulative future net revenue, in other words, the time-discounted value of all future earnings. Node revenue can be volatile, however, as shown for example in Fig. 17. More importantly, node revenue may not follow a distribution that is stationary over time. Consequently, other factors we plan to explore in estimating FFO include: • Performance history: An operator’s performance history—including the correctness and timeliness of its reports, as well as its up time—provides an objective touchstone for users to evaluate its reliability. Performance history will thus provide a critical factor in users’ selection of oracle nodes (or, with the advent of DONs, their selection of DONs). A strong performance history is likely to correlate with high ongoing revenue.18 18An important research question we intend to address is detection of falsiﬁed service volumes.

Revenue earned by Chainlink nodes on a single ETH-USD data feed showing correlation with price volatility

Figure 17: Revenue earned by Chainlink nodes on a single data feed (ETH-USD) during a representative week in March 2021. • Data access: While oracles may obtain many forms of data from open APIs, certain forms of data or certain high-quality sources may be available only on a subscription basis or through contractual agreements. Privileged access to certain data sources can play a role in creating a stable revenue stream. • DON participation: With the advent of DONs, communities of nodes will come together to provide particular services. We expect that many DONs will include operators on a selective basis, establishing participation in reputable DONs as a privileged market position that helps ensure a consistent source of revenue. • Cross-platform activity: Some node operators may have well-established presences and performance track records in other contexts, e.g., as PoS validators or data providers in non-blockchain contexts. Their performance in these other systems (when data on it is available in a trustworthy form) can inform evaluation of their performance history. Similarly, faulty behavior in the Chainlink network can jeopardize revenue in these other systems by driving away users, i.e., FFO can extend across platforms. 9.6.2 Speculative FFO Node operators participate in the Chainlink network not just to generate revenue from operations, but to create and position themselves to take advantage of new opportunities to run jobs. In other words, expenditure by oracle nodes in the network is also a positive statement about the future of DeFi and other smart-contract application domains as well as emerging non-blockchain applications of oracle networks. Node operators today earn the fees available on existing Chainlink networks and simultaneously These are loosely analogous to fake reviews on internet sites, except that the problem is easier in the oracle setting because we have a deﬁnitive record of whether the goods, i.e., reports, were ordered and delivered—as opposed to, e.g., physical goods ordered in online shops. Put another way, in the oracle setting, performance can be validated, even if customer veracity can’t.

build a reputation, performance history, and operational expertise that will position them advantageously to earn fees available in future networks (contingent, of course, on honest behavior). The nodes operating in the Chainlink ecosystem today will in this sense have an advantage over newcomers in earning the fees as additional Chainlink services become available. This advantage applies to new operators, as well as technology companies with established reputations; for example, T-Systems, a traditional technology provider (subsidiary of Deutsche Telekom), and Kraken, a large centralized exchange, have established early presences in the Chainlink ecosystem [28, 143]. Such participation by oracle nodes in future opportunities may be regarded itself as a kind of speculative FFO, and thus constitutes a form of stake in the Chainlink network. 9.6.3 External Reputation The IIF as we have described it can operate in a network with strictly pseudonymous operators, i.e., without disclosure of the people or real-world entities involved. One potentially important factor for user selection of providers, however, is external reputation. By external reputation, we mean the perception of trustworthiness attaching to real-world identities, rather than pseudonyms. Reputational risk attaching to real-world identities can be viewed as a form of implicit incentive. We view reputation through the lens of the IIF, i.e., in a cryptoeconomic sense, as a means of establishing cross-platform activity that may be incorporated into FFO estimates. The beneﬁt of using external reputation as a factor in estimates of FFO, as opposed to pseudonymous linkage, is that external reputation links performance not just to an operator’s existing activities, but also to future ones. If, for instance, a bad reputation attaches to an individual person, it can taint that person’s future enterprises. Put another way, external reputation can capture a broader swath of FFO than pseudonymous performance records, as the impact of malfeasance attaching to a person or established company is harder to escape than that associated with a pseudonymous operation. Chainlink is compatible with decentralized identity technologies (Section 4.3) that can provide support for the use of external reputation in the IIF. Such technologies can validate and thereby help ensure the veracity of operators’ asserted real-world identities.19 9.6.4 Open IIF Analytics The IIF, as we have noted, aims to provide reliable open-source data and tools for implicit-incentive analytics. The goal is to enable providers within the community to develop analytics tailored to the risk-assessment needs of diﬀerent parts of the Chainlink user base. 19Decentralized identity credentials can also, where desired, embellish pseudonyms with validated supplementary information. For example, a node operator could in principle use such credentials to prove that it is a Fortune 500 company, without revealing which one.

A considerable amount of historical data regarding nodes’ revenue and performance resides on chain in a high-trust, immutable form. Our goal, however, is to provide the most comprehensive possible data, including data on behaviors that are visible only oﬀ chain, such as Oﬀ-Chain Reporting (OCR) or DON activity. Such data can potentially be voluminous. The best way to store it and ensure its integrity, i.e., protect it from tampering, we believe, will be with the help of DONs, using techniques discussed in Section 3.3. Some incentives lend themselves to direct forms of measurement, such as staking deposits and basic FFO. Others, such as speculative FFO and reputation, are harder to measure in an objective manner, but we believe that supporting forms of data, including historical growth of the Chainlink ecosystem, social-media metrics of reputation, etc., can support IIF analytics models even for these harder-to-quantify elements. We can imagine that dedicated DONs arise speciﬁcally to monitor, validate, and record data relating to oﬀ-chain performance records of nodes, as well as other data used in the IIF, such as validated identity information. These DONs can provide uniform, high-trust IIF data for any analytics providers serving the Chainlink community. They will also provide a golden record that makes the claims of analytics providers independently veriﬁable by the community. 9.7 Putting It All Together: Node Operator Incentives Synthesizing our discussions above on explicit and implicit incentives for node operators provides a holistic view of the ways that node operators participate in and beneﬁt from the Chainlink network. As a conceptual guide, we can express the total assets at stake by a given Chainlink node operator $S in a rough, stylized form as: $S ≈$D + $F + $FS + $R, where: • $D is the aggregate of all explicitly deposited stake across all networks in which the operator participates; • $F is the net present value of the aggregate of all FFO across all networks in which the operator participates; • $FS is the net present value of the speculative FFO of the operator; and • $R is the reputational equity of the operator outside the Chainlink ecosystem that might be jeopardized by identiﬁed misbehavior in its oracle nodes. While largely conceptual, this rough equality helpfully shows that there is a multiplicity of economic factors favoring high-reliability performance by Chainlink nodes. All of these factors other than $D are present in today’s Chainlink networks.

9.8 The Virtuous Cycle of Economic Security The combination of super-linear staking impact with representation of fee payments as future fee opportunity (FFO) in the IIF can lead to what we call the virtuous cycle of economic security in an oracle network. This can be seen as a kind of economy of scale. As the total amount secured by a particular network rises, the amount of additional stake it takes to add a ﬁxed amount of economic security decreases as does the average per-user cost. It’s therefore cheaper, in terms of fees, for a user to join an already-existing network than to achieve the same increase in network economic security by creating a new network. Importantly, the addition of each new user lowers the cost of the service for all previous users of that network. Given a particular fee structure (e.g. a particular yield rate on the amount staked), if the total fees earned by a network increases, this incentivizes the ﬂow of additional stake into the network to secure it at a higher rate. Speciﬁcally, if the total stake an individual node may hold in the system is capped, then when new fee payments enter the system, raising its FFO, the number of nodes n will increase. Thanks to the super-linear staking impact of our incentive system design, the economic security of the system will rise faster than n, e.g., as n2 in the mechanism we sketch in Section 9.4. As a result, the average cost for economic security—i.e., amount of stake contributing a dollar of economic security—will drop. The network can therefore charge its users lower fees. Assuming that demand for oracle services is elastic (see, e.g., [31] for a brief explanation), demand will rise, generating additional fees and FFO. We illustrate this point with the following example. Example 5. Since the economic security of an oracle network with our incentive scheme is $dn2 for stake $dn, the economic security contributed by a dollar of stake is n and thus the average cost per dollar of economic security—i.e, amount of stake contributing to a dollar of economic security—is 1/n. Consider a network in which the economic incentives consist entirely of FFO, capped at $d ≤$10K per node. Suppose the network has n = 3 nodes. Then the average cost per dollar of economic security is about $0.33. Suppose that the total FFO of the network rises above $30K (e.g., to $31K). Given the cap on per-node FFO, the network grows to (at least) n = 4. Now the average cost per dollar of economic security drops to about $0.25. We illustrate the full virtuous cycle of economic security in oracle networks schematically in Fig. 18. We emphasize that the virtuous cycle of economic security derives from the eﬀect of users pooling their fees. It is their collective FFO that works in favor of larger network sizes and thus greater collective security. We also note that the virtuous cycle of economic security works in favor of DONs achieving ﬁnancial sustainability. Once created, DONs that address user needs should grow to and beyond the point at which revenue from fees exceed operational costs for oracle nodes.

Schematic of the virtuous cycle of Chainlink staking showing how user fees drive security and value capture

Figure 18: Schematic of the virtuous cycle of Chainlink staking. A rise in user fee payments to an oracle network 1⃝causes it to grow, leading to growth in its economic security 2⃝. This super-linear growth realizes economies of scale in Chainlink networks 3⃝. Speciﬁcally, it means a reduction in the average cost of economic security , i.e., the per-dollar economic security arising from fee payments or other sources of stake increases. Lower costs, passed along to users, stimulate increased demand for oracle services 4⃝. 9.9 Additional Factors Driving Network Growth As the Chainlink ecosystem continues to expand, we believe that its attractiveness to users and importance as infrastructure for the blockchain economy will accelerate. The value provided by oracle networks is super-linear, meaning that it grows faster

than the size of the networks themselves. This growth in value derives from both economies of scale—greater per-user cost eﬃciency as service volumes increase—and network eﬀects—an increase of network utility as users adopt DONs more widely. As existing smart contracts continue to see more value secured and entirely new smart contract applications are made possible by more decentralized services, the total use of and aggregate fees paid to DONs should grow. Increasing pools of fees in turn translate into the means and incentive to create even more decentralized services, resulting in a virtuous cycle. This virtuous cycle solves a critical chicken-and-egg problem in the hybrid smart contract ecosystem: Innovative smart contract features often require decentralized services that don’t yet exist (e.g., new DeFi markets often require new data feeds) yet need suﬃcient economic demand to come into existence. The pooling of fees by various smart contracts for existing DONs will signal demand for additional decentralized services from a growing user base, giving rise to their creation by DONs and an ongoing enablement of new and varied hybrid smart contracts. In summary, we believe that the growth in network security driven by virtuous cycles in the Chainlink staking mechanism exempliﬁes larger patterns of growth that the Chainlink network can help bring about in an on-chain economy for decentralized services.

Economia e Criptoeconomia

Para que a rede Chainlink alcance uma segurança forte dentro de um modelo de confiança descentralizado, é essencial que os nós exibam coletivamente um comportamento correto, o que significa que eles aderem na maioria das vezes exatamente para protocolos DON. Nesta seção, discutimos abordagens para ajudar a impor tal comportamento por meio de incentivos econômicos, também conhecidos como criptoeconômicos incentivos. Esses incentivos se enquadram em duas categorias: explícitos e implícitos, realizados respectivamente por meio de staking e oportunidade de taxa futura (FFO). Estacamento: O staking em Chainlink, como em outros sistemas blockchain, envolve participantes da rede, ou seja, nós oracle, depositando fundos bloqueados na forma de LINK tokens. Estes os fundos, que também chamamos de participação ou participação explícita, são um incentivo explícito. Eles estão sujeitos a confisco em caso de falha ou prevaricação do nó. No contexto blockchain, esse procedimento costuma ser chamado de corte. O piqueteamento por nós oracle em Chainlink, no entanto, difere fundamentalmente de staking por validators em blockchains sem permissão. Os validadores podem se comportar mal ao ordenar transações de forma equivocada ou adversária. O protocolo de consenso subjacente em um 15Como os usuários podem substituir transações no mempool, é necessário cuidado para garantir uma correspondência correta entre as transações extraídas e as enviadas por DON.blockchain sem permissão, entretanto, usa regras de validação de bloco rígidas e rápidas e primitivas criptográficas para evitar que validators gerem blocos inválidos. Em contraste, as proteções programáticas não podem impedir que uma rede oracle trapaceira gere relatórios inválidos. O motivo é uma diferença fundamental entre os dois tipos de sistema: a validação da transação em blockchains é uma propriedade de consistência interna, enquanto a correção dos relatórios oracle em um blockchain é uma propriedade de dados externos, ou seja, dados fora da cadeia. Projetamos um mecanismo staking preliminar para a rede Chainlink baseada em um protocolo interativo entre nós oracle que podem fazer uso de dados externos. Isto mecanismo cria incentivos financeiros para o comportamento correto usando recompensas explícitas e penalidades (corte). Como o mecanismo é econômico, ele foi projetado para evitar que os nós corrupção por um adversário que usa recursos financeiros para corromper nós por meio de suborno. (Tal adversário é muito geral e se estende, por exemplo, a nós que cooperam para extrair valor de seu mau comportamento coletivo.) O mecanismo Chainlink staking que projetamos tem alguns recursos poderosos e inovadores características.16 A principal característica é o impacto superlinear staking (especificamente, quadrático). Um adversário deve ter recursos consideravelmente superiores aos fundos depositados pelos nós em para subverter o mecanismo. Nosso mecanismo staking fornece adicionalmente proteção contra um adversário mais forte do que considerado anteriormente em sistemas semelhantes, ou seja, um adversário que pode criar subornos condicionados ao comportamento futuro dos nós. Além disso, discutimos como ferramentas Chainlink como DECO podem ajudar a fortalecer nosso staking mecanismo, facilitando a adjudicação correta no caso de comportamento defeituoso do nó. Oportunidade de taxa futura (FFO): blockchains sem permissão - tanto do PoW e variedade de PoS – hoje dependem criticamente do que chamamos de incentivos implícitos. Estes são incentivos económicos para o comportamento honesto que não derivam de recompensas explícitas, mas da própria participação na plataforma. Por exemplo, a comunidade mineira Bitcoin é incentivada a não montar um ataque de 51% pelo risco de minar a confiança em Bitcoin, deprimindo seu valor e, conseqüentemente, corroendo o valor de seu coletivo investimentos de capital em infraestrutura de mineração [150]. A rede Chainlink se beneficia de um incentivo implícito semelhante ao qual nos referimos como oportunidade de taxa futura (FFO). Nós Oracle com fortes históricos de desempenho ou reputações atraem taxas dos usuários. O mau comportamento de um nó oracle compromete o futuro pagamentos de taxas e, portanto, penaliza o nó com um custo de oportunidade em termos de potencial receitas obtidas através da participação na rede. Por analogia com a aposta explícita, O FFO pode ser visto como uma forma de participação implícita, um incentivo para um comportamento honesto que deriva do benefício compartilhado de manter a confiança na plataforma na qual o negócio dos operadores de nós depende, ou seja, do desempenho positivo e da reputação do rede. Este incentivo é inerente, mas não explicitamente expresso, na rede Chainlink protocolos. Em Bitcoin, manutenção do valor das operações de mineração conforme mencionado acima 16O mecanismo staking que descrevemos aqui atualmente visa apenas forçar a entrega de relatórios corretos por redes oracle. Esperamos em trabalhos futuros estendê-lo para garantir a execução correta dos muitos outras funcionalidades DONs fornecerão.pode igualmente ser visto como uma forma de aposta implícita. Ressaltamos que o FFO já existe em Chainlink e ajuda a proteger a rede hoje. Nossa principal contribuição no desenvolvimento futuro de Chainlink será uma abordagem baseada em princípios e empiricamente orientada para avaliar incentivos implícitos, como o FFO, por meio de o que chamamos de Quadro de Incentivos Implícitos (IIF). Para estimar quantidades como o oportunidade futura de taxas dos nós, o IIF aproveitará continuamente o abrangente dados de desempenho e pagamento acumulados pela rede Chainlink. Tais estimativas permitirá a parametrização baseada em IIF de sistemas staking que reflete os incentivos dos nós com maior precisão do que os modelos heurísticos e/ou estáticos atuais. Para resumir, então, os dois principais incentivos econômicos para o nó oracle correto o comportamento na rede Chainlink em desenvolvimento será: • Staking (participação depositada) ó Incentivo explícito • Oportunidade de taxas futuras (FFO) ó Incentivo implícito Essas duas formas de incentivo são complementares. Os nós Oracle podem simultaneamente participe do protocolo Chainlink staking, desfrute de um fluxo de receita contínuo de usuários e se beneficiar coletivamente de seu bom comportamento contínuo. Assim, ambos os incentivos contribuir para a segurança criptoeconômica fornecida por uma rede oracle. Além disso, os dois incentivos podem reforçar-se e/ou ser negociados entre si. Por exemplo, um novo operador oracle sem histórico de desempenho e fluxo de receita pode apostar um grande quantidade de LINK como garantia de comportamento honesto, atraindo assim usuários e taxas. Por outro lado, um operador oracle estabelecido com um tempo longo e relativamente livre de falhas histórico de desempenho pode cobrar taxas substanciais de uma grande base de usuários e, portanto, depender mais fortemente no seu FFO como forma de incentivo implícito. Em geral, a abordagem que consideramos aqui visa uma determinada quantidade de oracle-rede recurso para criar os maiores incentivos econômicos possíveis em Chainlink para racional agentes – isto é, nós que maximizam sua utilidade financeira – se comportem honestamente. Coloque outro Dessa forma, o objetivo é maximizar os recursos financeiros necessários para um adversário atacar a rede com sucesso. Ao formular um protocolo staking com matematicamente bem segurança econômica definida e também usando o IFI, pretendemos medir a força de Os incentivos de Chainlink com a maior precisão possível. Os criadores de contratos confiáveis irão então ser capaz de determinar com forte confiança se uma rede oracle atende seus níveis exigidos de segurança criptoeconômica. O ciclo virtuoso da segurança económica: Os incentivos que discutimos nesta seção, staking e FFO, têm um impacto além do reforço da segurança de DONs. Eles prometem induzir o que chamamos de ciclo virtuoso de segurança económica. O impacto superlinear staking (e outras economias de escala) resulta em menor custo à medida que a segurança de um DON aumenta. O custo mais baixo atrai usuários adicionais para DON,aumentando o pagamento de taxas. Um aumento no pagamento de taxas continua a incentivar o crescimento do rede, que perpetua o ciclo virtuoso. Acreditamos que o ciclo virtuoso da segurança económica é apenas um exemplo de uma economia de escala e efeito de rede, entre outros que discutiremos mais adiante nesta seção. Organização da seção: O piqueteamento apresenta desafios técnicos e conceituais notáveis para que projetamos um mecanismo com recursos novos. O piqueteamento será, portanto, nosso foco principal nesta seção. Fornecemos uma visão geral da abordagem staking que apresentamos neste artigo na Seção 9.1, seguida por uma discussão detalhada nas Seções 9.2 a 9.5. Apresentamos o IFF na Seção 9.6. Apresentamos uma visão resumida dos incentivos da rede Chainlink na Seção 9.7. Na Secção 9.8, discutimos o ciclo virtuoso de segurança económica que a nossa abordagem staking proposta pode trazer para as redes oracle. Finalmente, descrevemos brevemente outros potenciais efeitos que impulsionam o crescimento da rede Chainlink na Seção 9.9. 9.1 Visão geral do piqueteamento O design do mecanismo staking que apresentamos aqui, conforme observado acima, envolve um protocolo interativo entre nós oracle permitindo a resolução de inconsistências no reporte de dados externos. O piqueteamento visa garantir um comportamento honesto de nós oracle racionais. Podemos, portanto, modelar um adversário atacando um protocolo staking como um subornador: A estratégia do adversário é corromper nós oracle usando incentivos financeiros. O adversário pode obter recursos financeiros prospectivamente através da manipulação bem-sucedida com um relatório oracle, por exemplo, oferta para compartilhar o lucro resultante com nós corrompidos. Em nosso projeto de mecanismo staking visamos simultaneamente dois objetivos ambiciosos: 1. Resistir a um adversário poderoso: O mecanismo staking foi projetado para proteger oracle redes contra uma ampla classe de adversários que são capazes de ações complexas, estratégias de suborno condicional, incluindo suborno prospectivo, que oferece subornos para oracles cujas identidades são determinadas após o fato (por exemplo, oferece subornos a oracles selecionados aleatoriamente para alerta de alta prioridade). Enquanto outros designs oracle consideraram um conjunto restrito de ataques sem todas as capacidades de um cenário realista adversário, até onde sabemos, o mecanismo adversário que introduzimos aqui é o primeiro a abordar explicitamente um amplo conjunto de estratégias de suborno e mostrar resistência neste modelo. Nosso modelo assume que os nós além do invasor estão economicamente racional (em oposição a honesto), e assumimos a existência de um fonte de verdade que é proibitivamente cara para uso típico, mas está disponível em caso de desacordo (discutido mais abaixo). 2. Alcançando impacto superlinear staking: Nosso objetivo é garantir que uma rede oracle composta por agentes racionais reporte sinceramente, mesmo na presença de um invasor com um orçamento superlinearna participação total depositada por toda a rede. Em sistemas staking existentes, se cada um dos n nós aposta $d, um invasor pode emitir um suborno confiável que solicita que os nós se comportem desonestamente em troca de um pagamento de um pouco mais do que $d to each node, using a total budget of about $dn. Isto já é um padrão alto, pois o invasor precisa ter um orçamento líquido da ordem dos depósitos combinados de todos os participantes da rede. O nosso objectivo é um grau ainda mais forte de segurança económica do que este obstáculo já substancial. Nosso objetivo é projetar o primeiro sistema staking que pode alcançar segurança para um invasor geral com um orçamento superlinear em n. Embora as considerações práticas possam ter um impacto menor, como discutiremos abaixo, nosso projeto preliminar atinge um requisito orçamentário adversário maior do que $dn2/2, ou seja, escalando quadrático em n, tornando o suborno amplamente impraticável, mesmo quando os nós apostam apenas quantias moderadas. Alcançar estes dois objectivos requer uma combinação inovadora de concepção de incentivos e criptografia. Ideias principais: Nossa abordagem staking depende de uma ideia que chamamos de prioridade de vigilância. Um relatório gerado por uma rede Chainlink oracle e enviado para um contrato confiável (por exemplo, no preço de um ativo) é agregado a partir de relatórios individuais contribuídos pelos nós participantes (por exemplo, tomando a mediana). Normalmente, um acordo de nível de serviço (SLA) especifica limites aceitáveis de desvio para relatórios, ou seja, até que ponto o relatório de um nó pode desviar-se do relatório agregado e até que ponto o agregado deve ser autorizado a desviar do valor verdadeiro para ser considerado correto. Em nosso sistema staking, para uma determinada rodada de relatórios, cada nó oracle pode atuar como um watchdog para emitir um alerta se acreditar que o relatório agregado está incorreto. Em cada rodada de relatórios, cada nó oracle recebe uma prioridade pública que determina o ordem em que seu alerta (se houver) será processado. Nosso mecanismo visa recompensar concentração, o que significa que o cão de guarda de maior prioridade para emitir um alerta ganha o recompensa total obtida pelo confisco dos depósitos de nós defeituosos. Nossos projetos de sistema staking envolvem dois níveis: o primeiro, nível padrão, e o segundo, nível de proteção. A primeira camada é a própria rede oracle, um conjunto de n nós. (Para simplificar, assumimos que n é ímpar.) Se a maioria dos nós relatar valores incorretos, um watchdog no O primeiro nível é fortemente incentivado a emitir um alerta. Se um alerta for gerado, o relatório A decisão da rede é então escalada para um segundo nível – um sistema de alto custo e máxima confiabilidade que pode ser especificado pelo usuário no acordo de nível de serviço da rede. Este poderia ser um sistema que, por exemplo, é composto apenas por nós com forte pontuações de confiabilidade histórica, ou uma que tenha uma ordem de magnitude maior que oracles do que o primeiro nível. Além disso, conforme discutido na Seção 9.4.3, DECO ou Town Crier podem servir como ferramentas poderosas para ajudar a garantir uma adjudicação eficiente e conclusiva no segundo nível. Para simplificar, assumimos assim que este sistema de segundo nível chega a um relatório correto valor. Embora possa parecer atraente confiar apenas no segundo nível para gerar todos os relatórios, o benefício do nosso design é que ele atinge consistentemente as propriedades de segurança dosistema de segundo nível, pagando apenas o custo operacional, no caso típico, do sistema de primeiro nível. A prioridade do watchdog resulta em impacto superlinear staking da seguinte maneira: se o rede oracle de primeira camada gera um resultado incorreto e vários nós de vigilância alerta, o mecanismo de incentivo staking recompensa o cão de guarda de maior prioridade com mais de $dn/2 retirados dos depósitos da (maioria) nós com comportamento inadequado. O a recompensa total é, portanto, concentrada nas mãos deste único cão de guarda, que, portanto, determina o mínimo que um adversário deve prometer a um cão de guarda em potencial para incentivá-lo a não alertar. Como nosso mecanismo garante que todo oracle receba o chance de agir como cão de guarda se os cães de guarda de maior prioridade aceitarem seus subornos (e optou por não alertar), o adversário deve, portanto, oferecer um suborno de mais de $dn/2 para cada nó para evitar que qualquer alerta seja gerado. Como existem n nós, o o orçamento necessário do adversário para um suborno bem-sucedido equivale a mais de $dn2/2, o que é quadrático no número n de nós na rede. 9.2 Plano de fundo Nossa abordagem para staking baseia-se em pesquisas nas áreas de teoria dos jogos e mecanismos design (MD) (para referência de livro, consulte [177]). A teoria dos jogos é matematicamente estudo formalizado de interação estratégica. Neste contexto, um jogo é um modelo de tal uma interação, tipicamente no mundo real, que codifica conjuntos de ações disponíveis para participantes do jogo, conhecidos como jogadores. Um jogo também especifica os pagamentos obtidos pelos jogadores individuais - recompensas que dependem das ações escolhidas pelo jogador e do ações dos outros jogadores. Talvez o exemplo mais conhecido de jogo estudado em game teoria é o Dilema dos Prisioneiros [178]. Os teóricos dos jogos geralmente pretendem compreender o equilíbrio ou equilíbrios (se houver) representados em um determinado jogo. Um equilíbrio é um conjunto de estratégias (uma para cada jogador) tal que nenhum jogador possa obter um valor mais alto recompensa ao desviar-se unilateralmente da sua estratégia. O desenho de mecanismos, por sua vez, é a ciência de desenhar incentivos de modo que o O equilíbrio de uma interação (e seu jogo associado) tem alguma propriedade desejável. MD pode ser visto como o inverso da teoria dos jogos: a questão canônica no jogo a teoria é: “dados os incentivos e o modelo, qual será o equilíbrio?” Em MD, o a questão é, em vez disso, “que incentivos resultarão num jogo com um equilíbrio desejável?” Um objetivo típico de um projetista de mecanismo é criar um mecanismo “compatível com incentivos”, o que significa que os participantes do mecanismo (por exemplo, um leilão ou outra informação sistema de elicitação [228]) são incentivados a relatar a verdade sobre algum assunto (por exemplo, como quanto eles valorizam um determinado item). O leilão de Vickrey (segundo preço) é talvez o mecanismo compatível com incentivos mais conhecido, no qual os participantes apresentam propostas lacradas para um item e o licitante com lance mais alto ganha o item, mas paga o segundo preço mais alto [214]. A criptoeconomia é uma forma de MD de domínio específico que aproveita a criptografia técnicas para criar equilíbrios desejáveis dentro de sistemas descentralizados. O suborno e o conluio criam desafios significativos em todo o campo da DM. Quase todos os mecanismos quebram na presença de conluio, definido como contratos paralelos entreentre as partes participantes de um mecanismo [125, 130]. O suborno, em que uma parte externa introduz novos incentivos no jogo, apresenta um problema ainda mais difícil do que o conluio; o conluio pode ser visto como um caso especial de suborno entre jogadores participantes. Os sistemas Blockchain podem muitas vezes ser conceituados como jogos com recompensas monetárias (baseadas em criptomoedas). Um exemplo simples é a mineração Proof-of-Work: os mineradores têm um espaço de ação no qual eles podem escolher a hashtaxa com a qual extrair blocos. O retorno da mineração é uma recompensa negativa garantida (custo de eletricidade e equipamentos) mais um fator estocástico. recompensa positiva (subsídio de mineração) que depende do número de outros mineradores ativos [106, 172] e taxas de transação. oracles crowdsourced como SchellingCoin [68] são outro exemplo: o espaço de ação é o conjunto de relatórios possíveis que um oracle pode enviar, enquanto a recompensa é a recompensa especificada pelo mecanismo oracle, por exemplo, o pagamento pode depender sobre quão próximo o relatório de um oracle está da mediana dos outros relatórios [26, 68, 119, 185]. Os jogos Blockchain oferecem oportunidades propícias para ataques de conluio e suborno; na verdade, smart contracts podem até facilitar tais ataques [96, 165]. Talvez o mais conhecido O ataque de suborno a oracles de crowdsourcing é o ataque p-plus-epsilon [67]. Este ataque surge no contexto de um mecanismo semelhante ao SchellingCoin, no qual os jogadores enviam relatórios com valor booleano (ou seja, falsos ou verdadeiros) e são recompensados com p se concordarem com o submissão da maioria. Em um ataque p-mais-épsilon, o invasor promete, com credibilidade, por exemplo, pague aos usuários $p + ϵ por votarem falso se e somente se a submissão da maioria for verdadeira. O resultado é um equilíbrio, em que todos os intervenientes são incentivados a denunciar falsas independentemente do que os outros jogadores façam; conseqüentemente, o subornador pode induzir os nós através do suborno prometido para reportar informações falsas sem realmente pagar o suborno (!). A exploração de outras estratégias de suborno no contexto de oracles, no entanto - e particularmente de oracles que não são de crowdsourcing - tem sido limitada a adversários bastante fracos. modelos. Por exemplo, no cenário PoW, os pesquisadores estudaram subornos, ou seja, subornos pagos apenas se uma mensagem alvo for censurada com sucesso e não aparecem em um bloco, independentemente da ação individual de um minerador [96, 165]. No caso de oracles, no entanto, além do ataque p-plus-epsilon, estamos cientes apenas do trabalho em um modelo estritamente limitado de suborno, no qual um subornador envia um suborno condicionado a um ação individual do jogador, não no resultado resultante. Aqui esboçamos projetos de mecanismos de elicitação de informações que permanecem incentivos compatível mesmo em um modelo adversário forte, conforme descrito na próxima subseção. 9.3 Suposições de modelagem Nesta subseção, explicamos como modelamos o comportamento e as capacidades dos jogadores em nosso sistema, especificamente nós oracle de primeira camada, nós de segunda camada (julgamento) camada e adversários.9.3.1 Modelo de incentivo de primeiro nível: atores racionais Muitos sistemas blockchain dependem de segurança na suposição de um certo número de informações honestas nós participantes. Os nós são definidos para serem honestos se seguirem o protocolo mesmo quando não for do seu interesse financeiro fazê-lo. Sistemas de prova de trabalho normalmente exigem que a maior parte do poder de hash seja honesto, os sistemas de prova de participação normalmente exigem que 2/3 ou mais de todas as participações participantes sejam honestos, e até mesmo sistemas de camada 2 como Arbitrum [141] exige pelo menos um único participante honesto. Na modelagem do nosso mecanismo staking, fazemos uma suposição muito mais fraca. (Para ser suposições claras e mais fracas significam propriedades de segurança mais fortes e são, portanto, preferíveis.) Assumimos que o adversário corrompeu, ou seja, controla, alguns (minoria) fração de nós oracle de primeira camada. Modelamos os nós restantes não como agentes honestos, mas como maximizadores racionais da utilidade esperada. Esses nós agem inteiramente de acordo com incentivos financeiros de interesse próprio, escolhendo ações que resultem em um resultado financeiro esperado. ganho. Por exemplo, se for oferecido a um nó um suborno maior do que a recompensa resultante de comportamento honesto, aceitará o suborno. Nota sobre nós adversários: De acordo com a modelagem de confiança comum para sistemas descentralizados, assumimos que todos os nós são racionais, ou seja, buscando maximizar receita líquida, em vez de ser controlada por um adversário malicioso. Nossas reivindicações, no entanto - impacto staking especificamente superlinear ou quadrático - mantido assintoticamente fornecido que o conjunto de nós controlados adversamente é no máximo (1/2 −c)n, para alguns pontos positivos constante c. 9.3.2 Modelo de adjudicação de segundo nível: correção por suposição Lembre-se de que um recurso crítico do nosso mecanismo staking que ajuda a alcançar a segurança contra nós racionais é seu sistema de segunda camada. Em nosso mecanismo staking proposto, qualquer oracle pode gerar um alerta indicando que ele acredita que a saída do mecanismo está incorreta. Um alerta resulta em uma alta confiança sistema de segundo nível ativando e relatando o resultado correto. Assim, uma modelagem chave O requisito para a nossa abordagem é a adjudicação correta, ou seja, o relato correto por parte do sistema de segundo nível. Nosso modelo staking assume um sistema de segundo nível que atua como uma fonte de verdade incorruptível e extremamente confiável. É provável que tal sistema seja caro e lento e, portanto, inadequado para uso no caso típico. No caso de equilíbrio, entretanto, ou seja, quando Se o sistema de primeira camada funcionar corretamente, o sistema de segunda camada não será invocado. Em vez disso, a sua existência aumenta a segurança de todo o sistema oracle, fornecendo um proteção de alta segurança. O uso de uma camada de julgamento de alta confiança e alto custo assemelha-se ao processo de apelação no coração da maioria dos sistemas judiciais. Também já é comum no design de oracle sistemas, por exemplo, [119, 185]. Discutimos brevemente abordagens para a realização do segundo nível em nosso mecanismo na Seção 9.4.3.Nosso protocolo staking usa a suposta adjudicação correta do sistema de segundo nível como uma ameaça credível para impor relatórios corretos por nós oracle. O protocolo confisca parte ou toda a participação dos nós oracle que geram relatórios identificados por o sistema de segundo nível como incorreto. Os nós Oracle são, portanto, impedidos de se comportarem mal pela penalidade financeira resultante. Esta abordagem é semelhante em sabor àquela usada em rollups otimistas, por exemplo, [141, 10]. 9.3.3 Modelo Adversário Nosso mecanismo staking foi projetado para obter informações verdadeiras e, ao mesmo tempo, obter segurança contra uma classe ampla e bem definida de adversários. Melhora os trabalhos anteriores, que omitem um modelo adversário explícito ou se concentram em subclasses estreitas de adversários, por exemplo, o adversário p-mais-épsilon discutido acima. Nosso objetivo é projetar um staking mecanismo com segurança formalmente comprovada contra todo o espectro de adversários prováveis a ser encontrado na prática. Modelamos nosso adversário como tendo um orçamento fixo (parametrizável), denotado por $ B. O adversário pode se comunicar individual e confidencialmente com cada oracle em rede e pode oferecer secretamente a qualquer indivíduo oracle pagamento garantido de suborno dependente de resultados publicamente observáveis do mecanismo. Resultados determinantes subornos podem incluir, por exemplo, o valor relatado pelo oracle, quaisquer mensagens públicas enviado por qualquer oracle ao mecanismo (por exemplo, um alerta), os valores relatados por outros oracles e o valor gerado pelo mecanismo. Nenhum mecanismo pode proteger contra um invasor com capacidades ilimitadas. Portanto, consideramos alguns comportamentos irrealistas ou fora do escopo. Presumimos que nosso atacante não pode quebrar primitivas criptográficas padrão e, como observado acima, tem um valor fixo (se potencialmente grande) orçamento $B. Assumimos ainda que o adversário não controla comunicação na rede oracle, especificamente que não pode atrasar substancialmente tráfego entre nós de primeira e/ou segunda camada. (Se o adversário pode observar tal comunicação depende do mecanismo específico, conforme explicamos abaixo.) Informalmente, porém, como observado acima, presumimos que o adversário pode: (1) Corromper uma fração de nós oracle ((1/2 −c)-fração para alguma constante c), ou seja, controle total e (2) oferecer subornos a quaisquer nós desejados, com pagamento contingente garantido nos resultados especificados pelo adversário, conforme descrito acima. Embora não ofereçamos um modelo formal ou uma taxonomia completa da situação completa do adversário, gama de capacidades de suborno neste whitepaper, aqui estão exemplos dos tipos de subornos abrangidos pelo nosso modelo. Para simplificar, assumimos que oracles emitem booleanos relatórios cujo valor correto (w.l.o.g.) é verdadeiro, e que um resultado final é calculado como um agregado desses relatórios a ser usado por um consumidor smart contract. O subornado O objetivo é que o resultado final seja incorreto, ou seja, falso. • Subornador incondicional: O suborno oferece suborno $b a qualquer oracle que reporte algo falso. • Subornador probabilístico: o subornador oferece suborno $b com alguma probabilidade q para qualquer oracle que reporta falso.• suborno condicionado a resultado falso: o subornador oferece suborno $b a qualquer oracle que relate falso, desde que o resultado final seja falso. • Subornador sem alerta: o subornador oferece suborno em $b a qualquer oracle que denuncie false enquanto nenhum alerta for gerado. • Subornador p-plus-epsilon: O suborno oferece suborno $b a qualquer oracle que relate falso como desde que a maioria dos oracles não relatem falsos. • Subornador em potencial: o suborno oferece suborno $b antecipadamente para qualquer oracle selecionado para um papel aleatório e relatórios falsos. Em nosso protocolo staking proposto, todos nós atuam como potenciais vigilantes, e somos capazes de mostrar que a randomização das prioridades de vigilância não se presta a possíveis subornos. Muitos sistemas de prova de trabalho, proof-of-stake e sistemas autorizados são suscetíveis a possíveis suborno, no entanto, o que mostra a importância de considerá-lo em nosso contexto antagônico modelo e garantindo que nossos protocolos staking sejam resilientes a ele. Consulte o Apêndice E para mais detalhes. 9.3.4 Quanto de segurança criptoeconômica é suficiente? Um adversário racional só gastará dinheiro para atacar um sistema se puder obter lucro maior do que as suas despesas. Assim, para nosso modelo adversário e proposto staking mecanismo, $B pode ser visto como uma medida do lucro potencial que um adversário é capaz extrair de smart contracts confiáveis corrompendo uma rede oracle e causando-a para gerar um relatório ou conjunto de relatórios incorreto. Ao decidir se uma rede oracle oferece um grau suficiente de segurança criptoeconômica para seus propósitos, um usuário deve avaliar a rede a partir desta perspectiva. Para adversários plausíveis em ambientes práticos, esperamos que $B seja geralmente substancialmente menor do que os ativos totais em smart contracts confiáveis. Na maioria dos casos, é é inviável para um adversário extrair esses ativos na sua totalidade. 9.4 Mecanismo de piquetagem: esboço Apresentamos aqui as ideias principais e a estrutura geral do mecanismo staking que estão considerando atualmente. Para facilitar a apresentação, descrevemos um método simples, mas lento protocolo (multi-round) nesta subseção. Notamos, no entanto, que este esquema é bastante prático. Dadas as garantias económicas proporcionadas pelo mecanismo, ou seja, a penalização e o consequente incentivo contra nós defeituosos, muitos utilizadores podem estar dispostos a aceitar relatórios com otimismo. Em outras palavras, tais usuários podem aceitar relatórios antes de possível julgamento pela segunda camada. Os usuários que não desejam aceitar relatórios de forma otimista podem optar por esperar até que o protocolo a execução termina, ou seja, até que ocorra qualquer escalonamento potencial para o segundo nível. Isto, no entanto, pode retardar substancialmente o tempo de confirmação dos relatórios. Portanto, brevementeFigura 15: Esquema do esquema staking com alerta. Neste exemplo, 1⃝a maioria de nós são corrompidos/subornados e emitem um valor incorreto ˜r, em vez do correto valor do relatório r. O nó watchdog 2⃝envia um alerta ao comitê de segundo nível, que 3⃝determina e emite o valor correto do relatório r, resultando em nós corrompidos perdendo seus depósitos - cada $d para o nó watchdog 4⃝. delinear algumas otimizações que resultam em uma rodada mais rápida (rodada única), embora um pouco mais projeto complexo na Seção 9.5. Lembre-se de que a primeira camada do nosso mecanismo staking consiste no oracle básico própria rede. A estrutura principal do nosso mecanismo, conforme descrito acima, é que em cada rodada, cada nó pode atuar como um “watchdog” com alguma prioridade e, portanto, tem a capacidade de emitir um alerta se o mecanismo chegar a uma saída incorreta ˜r, em vez de uma saída correta um R. Este alerta causa uma resolução de segundo nível, que presumimos que chega a um nível correto relatório. Nós com relatórios incorretos são punidos, no sentido de que suas apostas são cortado e concedido a cães de guarda. Esta estrutura básica é comum em sistemas oracle, como em, por exemplo, [119, 185]. A principal inovação em nosso projeto, mencionada brevemente acima, é que cada nó é atribuiu uma prioridade distinta na ordenação de potenciais vigilantes. Ou seja, cães de guarda recebem oportunidades de alertar em sequência de prioridade. Lembre-se de que se um nó tiver o prioridade mais alta para gerar um alerta, ele recebe o depósito reduzido $d de cada mau comportamento nó, para um total de mais de $dn/2 = $d × n/2, pois um relatório incorreto implica um maioria dos nós ruins. Consequentemente, o adversário deve pagar pelo menos esta recompensa ao subornar um nó arbitrário. Assim, para subornar a maioria dos nós, o adversário deve pagar uma taxa grande suborno para a maioria dos nós, ou seja, estritamente mais do que $dn2/2. Mostramos esquematicamente como funciona o alerta e o escalonamento do watchdog na Figura 15.9.4.1 Mais detalhes do mecanismo O sistema resistente ao suborno que descrevemos agora com mais detalhes é um esboço simplificado de a construção de dois níveis que pretendemos construir. A maior parte do nosso foco será na descrição a rede de primeiro nível (doravante simplesmente “rede” quando claro no contexto) junto com o seu mecanismo de incentivo e o procedimento de escalada para o segundo nível. Considere uma rede Chainlink composta por n nós oracle que são responsáveis por regularmente (por exemplo, uma vez por minuto) relatando um valor booleano (por exemplo, se o mercado a capitalização do BTC excede a da ETH). Como parte do mecanismo staking, nós deve fornecer dois depósitos: um depósito $d sujeito a redução em caso de desacordo com a maioria e um depósito de vigilância $dw sujeito a redução em caso de defeito escalada. Assumimos que os nós não podem copiar os envios de outros nós, por exemplo, através de um esquema commit-reveal conforme discutido na Seção 5.3. Em cada rodada, os nós primeiro comprometer-se com seu relatório e, quando todos os nós forem confirmados (ou o tempo limite expirar), nós revelam seus relatórios. Para cada relatório a ser gerado, cada nó também recebe uma prioridade de watchdog entre 1 e n escolhida aleatoriamente, sendo 1 a prioridade máxima. Esta prioridade permite concentração de recompensa nas mãos de um cão de guarda. Depois que todos os relatórios forem públicos, segue-se uma fase de alerta. Ao longo de uma sequência de n rodadas (síncronas), o nó com prioridade i tem a oportunidade de alertar na rodada i. Vamos considerar os resultados possíveis para o mecanismo após os nós terem revelado seus relatórios. Novamente assumindo um relatório binário, suponha que o valor correto seja verdadeiro e o incorreto é falso. Suponha também que o mecanismo de primeiro nível produza o valor majoritário produzido pelos nós como o relatório final r. Existem três resultados possíveis no mecanismo: • Concordância completa: na melhor das hipóteses, os nós estão em concordância completa: todos os nós estão disponíveis e forneceram um relatório oportuno com o mesmo valor r (verdadeiro ou falso). Neste caso, a rede precisa apenas encaminhar r para contratos confiáveis e recompensar cada nó com um pagamento fixo por rodada $p, que é muito menor do que $ d. • Concordância parcial: é possível que alguns nós estejam off-line ou haja desacordo sobre qual valor é correto, mas a maioria dos nós reporta verdadeiro e apenas um relatórios minoritários falsos. Este caso também é simples. O valor majoritário (verdadeiro) é calculado, resultando em um relatório correto r. Todos os nós que relataram r são recompensado com $p enquanto os oracles que relataram incorretamente têm seus depósitos reduzido modestamente, por exemplo, em US$ 10 centavos. • Alerta: Caso um watchdog acredite que a saída da rede está incorreta, ele aciona publicamente um alerta, escalando o mecanismo para a rede de segundo nível. Existem então dois resultados possíveis: – Alerta correto: Se a rede de segundo nível confirmar que a saída doFigura 16: Ampliando o custo do suborno por meio de recompensas concentradas em alertas. Um suborno O adversário deve subornar cada nó com mais do que a recompensa que pode ganhar ao alertar (mostrado como uma barra vermelha). Se as recompensas de alerta forem compartilhadas, então esta recompensa pode ser relativamente pequeno. Recompensas de alerta concentrado aumentam a recompensa que qualquer nó único pode obter (barra vermelha alta). Consequentemente, o pagamento total pelo adversário por um suborno viável (regiões cinzas) é muito maior com recompensas de alerta concentradas do que compartilhadas. rede de primeira camada estava incorreta, o nó watchdog alertador recebe uma recompensa consistindo em todos os depósitos reduzidos e, portanto, mais de $dn/2. – Alerta de falha: Se os oracles de segundo e primeiro nível concordarem, o escalonamento é considerado defeituoso e o nó de alerta perde seu depósito $dw. No caso de aceitação otimista dos relatórios, os alertas de vigilância não causam qualquer alteração na execução de contratos de confiança. Para contratos concebidos para aguardar possível arbitragem pelo comitê de segundo nível, alertas de vigilância atrasam, mas não congele a execução do contrato. Também é possível que os contratos designem um failover DON para períodos de adjudicação. 9.4.2 Impacto de piquetagem quadrática A capacidade de cada nó atuar como um cão de guarda, combinada com uma prioridade estrita de nó garantindo recompensas concentradas, permite que o mecanismo atinja staking quadrático impacto para cada tipo de atacante de suborno descrito na Seção 9.3.3. Lembre-se que isso significa especificamente em nossa configuração que, para uma rede com n nós, cada um com depósito $d, um subornador bem-sucedido (de qualquer um dos tipos acima) deve ter um orçamento maior que $dn2/2. Para ser mais preciso, o subornador deve corromper pelo menos (n+1)/2 nós, uma vez que o subornador deve corromper a maioria de n nós (para n ímpares, por suposição). Assim, um cão de guarda deve ganhe uma recompensa de $d(n + 1)/2. O subornador, consequentemente, deve pagar esta quantia a cadanó para garantir que nenhum atue como um cão de guarda. Estamos trabalhando para mostrar formalmente que se o subornador tem um orçamento de no máximo $d(n2 + n)/2, então o equilíbrio perfeito do subjogo do jogo entre os subornadores e os oracles - em outras palavras, o equilíbrio em qualquer ponto durante o jogo - é para o subornador não emitir o suborno e para cada oracle relate seus verdadeiros valores honestamente. Explicamos acima como é possível que um subornador bem-sucedido exija uma orçamento significativamente maior do que a soma dos depósitos dos nós. Para ilustrar isso resultado intuitivo, a Fig. 16 mostra graficamente o impacto das recompensas de alerta concentrado. Como vemos aí, se a recompensa pelo alerta de vigilância - nomeadamente os depósitos de dinheiro subornado nós reportando falsos) - foram divididos entre todos os alertas potenciais, o valor total que qualquer nó de alerta individual poderia esperar que fosse relativamente pequeno, da ordem de $d. Um subornador, sabendo que um pagamento maior que $d era improvável, poderia usar um suborno condicional de resultado falso para subornar cada um dos n nós com um pouco mais de $d + ϵ. Contra-intuitivamente, a Fig. 16 mostra que um sistema que distribui uma recompensa amplamente entre os nós que sinalizam um alerta é muito mais fraco do que aquele que concentra a recompensa em nas mãos de um único cão de guarda. Parâmetros de exemplo: Considere uma rede (de primeira camada) com n = 100 nós, cada depositando $d = $20K. Esta rede teria um total de US$ 2 milhões depositados, mas estar protegido contra suborno com orçamento $100M = $dn2/2. Aumentando o número de oracles é mais eficaz do que aumentar $d, é claro, e pode ter um efeito dramático: uma rede com n = 300 nós e depósitos $d = $20K estaria protegida contra um subornador com orçamento de até US$ 900 milhões. Observe que um sistema staking pode, em muitos casos, proteger smart contracts representando mais valor do que o nível oferecido de proteção contra suborno. Isso ocorre porque um adversário atacar estes contratos não consegue extrair o valor total em muitos casos. Por exemplo, um O contrato movido por Chainlink que garante US$ 1 bilhão em valor só pode exigir garantia contra um subornador com US$ 100 milhões em recursos porque tal adversário pode extrair lucro de maneira viável de apenas 10% do valor do contrato. Nota: A ideia de que o valor de uma rede pode crescer quadraticamente é expressa em a conhecida Lei de Metcalfe [167, 235], que afirma que o valor de uma rede cresce quadraticamente no número de entidades conectadas. A Lei de Metcalfe, no entanto, surge do crescimento no número de possíveis conexões de rede em pares, um fenômeno diferente daquele impacto quadrático subjacente staking em nosso incentivo mecanismo. 9.4.3 Realização do Segundo Nível Dois recursos operacionais facilitam a realização de um segundo nível de alta confiabilidade: (1) A adjudicação de segundo nível deve ser um evento raro em redes oracle e, portanto, pode ser significativamente mais dispendioso do que a operação normal do primeiro nível e (2) Assumindorelatórios aceitos com otimismo – ou contratos cuja execução pode aguardar arbitragem – a segunda camada não precisa ser executada em tempo real. Estas características resultam em uma série de opções de configuração para o segundo nível para atender aos requisitos de DONs específicos. Como exemplo de abordagem, um comitê de segundo nível pode consistir em nós selecionados por um DON (ou seja, primeiro nível) dos nós mais antigos e confiáveis no Chainlink rede. Além de considerável experiência operacional relevante, os operadores de tais nós têm um incentivo implícito considerável no FFO que motiva um desejo para garantir que a rede Chainlink permaneça altamente confiável. Eles também têm publicamente históricos de desempenho disponíveis que fornecem transparência em sua confiabilidade. Vale ressaltar que os nós de segunda camada não precisam ser participantes da rede de primeira camada, e pode julgar falhas em múltiplas redes de primeira camada. Os nós em um determinado DON podem pré-designar e comprometer-se publicamente com um conjunto de n′ tais nós como constituindo o comitê de segundo nível para aquele DON. Além disso, DON os nós publicam um parâmetro k′ ≤n′ que determina o número de votos de segundo nível necessário para penalizar um nó de primeira camada. Quando um alerta é gerado para um determinado relatório, os membros do segundo nível votam na correção dos valores fornecidos por cada dos nós de primeira camada. Qualquer nó de primeira camada que receber k′ votos negativos perde sua depósitos no nó watchdog. Devido à raridade do julgamento e à oportunidade de execução prolongada mencionado acima, em contraste com o primeiro nível, os nós do segundo nível podem: 1. Ser altamente remunerado pela condução da adjudicação. 2. Recorrer a fontes de dados adicionais, para além do conjunto diversificado utilizado pelo primeiro nível. 3. Confiar na inspeção e intervenção manual e/ou especializada, por exemplo, para identificar e reconciliar erros nos dados de origem e distinguir entre um nó honesto retransmitindo dados defeituosos e um nó com mau comportamento. Enfatizamos que a abordagem que acabamos de descrever para a seleção de nós de segundo nível e para a adjudicação de políticas que governam representa apenas um ponto dentro de um grande espaço de design de possíveis realizações do segundo nível. Nosso mecanismo de incentivo oferece total flexibilidade quanto à forma como o segundo nível é realizado. DONs individuais podem, portanto, constituir e definir regras para seus segundos níveis que atendam aos requisitos específicos e expectativas dos nós e usuários participantes. DECO e Town Crier como ferramentas de adjudicação: É essencial para o segundo nível em nosso mecanismo para sermos capazes de distinguir entre nós adversários de primeira camada que produzem intencionalmente relatórios incorretos e nós honestos de primeira camada que involuntariamente retransmitir dados incorretos na origem. Só então o segundo nível poderá implementar cortar para desincentivar a trapaça, o objetivo do nosso mecanismo. DECO e Pregoeiro são ferramentas poderosas que podem permitir que nós de segundo nível façam essa distinção crítica de forma confiável.Os nós de segunda camada podem, em alguns casos, ser capazes de consultar diretamente a fonte de dados usada por um nó de primeira camada ou use a Seção 7.1 do ADO para verificar se um relatório incorreto resultou de uma fonte de dados defeituosa. Em outros casos, entretanto, os nós de segundo nível podem não ter acesso direto à fonte de dados de um nó de primeira camada. Nesses casos, a decisão correta seria parecem ser inviáveis ou exigem confiança em julgamento subjetivo. Anterior oracle sistemas de disputas têm dependido de rodadas de votação ineficientes e crescentes para resolver tais desafios. Usando DECO ou Town Crier, no entanto, um nó de primeiro nível pode provar o comportamento correto para nós de segunda camada. (Veja a Seção 3.6.2 para detalhes sobre os dois sistemas.) Especificamente, se o nó da segunda camada identifica um nó da primeira camada como tendo gerado um valor de relatório defeituoso ˜r, o nó de primeiro nível pode usar DECO ou Town Crier para gerar evidências à prova de falsificação para nós de segunda camada que estão retransmitindo corretamente ˜r de uma fonte (habilitada para TLS) reconhecido como oficial pelo DON. Criticamente, o nó de primeira camada pode fazer isso sem nós de segundo nível que exijam acesso direto à fonte de dados.17 Consequentemente, a adjudicação correta é viável em Chainlink para qualquer fonte de dados desejada. 9.4.4 Relatório incorreto de seguro A forte resistência ao suborno alcançada pelo nosso mecanismo staking depende fundamentalmente sobre a redução de fundos concedidos aos alertadores. Sem uma recompensa monetária, os alertadores não têm incentivo direto para rejeitar subornos. Como resultado, porém, os fundos cortados não são disponível para compensar usuários prejudicados por relatórios incorretos, por exemplo, usuários que perdem dinheiro quando dados de preço incorretos são retransmitidos para smart contract. Por suposição, relatórios incorretos não representam um problema se os relatórios forem aceitos por um contrato somente após eventual adjudicação, ou seja, ação da segunda camada. Como explicado acima, porém, para alcançar o melhor desempenho possível, os contratos podem, em vez disso, contar com otimistas sobre o mecanismo para impor relatórios corretos, o que significa que eles aceitam relatórios antes de uma possível adjudicação de segundo nível. Na verdade, esse comportamento optimista está seguro em nosso modelo assumindo adversários racionais cujos orçamentos não excedam o staking impacto do mecanismo. Usuários preocupados com o evento improvável de falha do mecanismo resultante de, por exemplo, adversários com recursos financeiros esmagadores podem querer empregar uma camada adicional de segurança económica sob a forma de declarações falsas de seguros. Nós sabemos de múltiplas seguradoras que já pretendem oferecer apólices deste tipo apoiadas por contratos inteligentes para protocolos protegidos por Chainlink em um futuro próximo, inclusive por meio de mecanismos inovadores como DAOs, por exemplo, [7]. A existência de histórico de desempenho para Chainlink nós e outros dados sobre nós, como seus valores de participação, fornecem uma base excepcionalmente forte para avaliações atuariais de risco, tornando possível definir preços de políticas de formas que sejam baratas para os segurados, mas sustentáveis para as seguradoras. 17Com o Town Crier, também é possível que nós de primeiro nível gerem atestados localmente de correção para os relatórios que eles produzem e fornecem esses atestados para nós de segundo nível em um conforme necessário.Formas básicas de seguro contra declarações falsas podem ser implementadas de forma confiável e maneira eficiente usando smart contracts. Como exemplo simples, um seguro paramétrico contrato SCins pode compensar os segurados automaticamente se nosso mecanismo de incentivo segunda camada identifica um erro em um relatório gerado na primeira camada. Um usuário U que deseja adquirir uma apólice de seguro, por exemplo, o criador de um alvo contrato SC, pode enviar uma solicitação a uma seguradora descentralizada por um valor de apólice $ milhões no contrato. Ao aprovar U, a seguradora pode definir um valor contínuo (por exemplo, mensal) prêmio de $P em SCins. Enquanto U paga o prêmio, sua apólice permanece ativa. Caso ocorra falha de reporte no SC, o resultado será a emissão de um par (r1, r2) de relatórios conflitantes para SC, onde r1 é assinado pelo primeiro nível em nosso mecanismo e r2, o relatório corrigido correspondente, é assinado pelo segundo nível. Se o U fornecer um par válido (r1, r2) para SCins, o contrato paga automaticamente $M a ela, desde que seus pagamentos de prêmio estão em dia. 9,5 Variante de Rodada Única O protocolo descrito na subseção anterior exige que o comitê de segundo nível espere n rodadas para determinar se um cão de guarda emitiu um alerta. Isto O requisito é válido mesmo no caso otimista, ou seja, quando o primeiro nível está funcionando corretamente. Para usuários que não desejam aceitar relatórios de forma otimista, ou seja, antes de possíveis adjudicação, o atraso associado a essa abordagem seria impraticável. Por esta razão, também estamos explorando protocolos alternativos que requerem apenas um redondo. Nesta abordagem, todos os nós oracle enviam bits secretos indicando se ou não eles desejam levantar um alerta. O comité de segundo nível verifica então estes valores em ordem de prioridade. Para fornecer um esboço, tal esquema pode envolver o seguinte etapas: 1. Envio de bits de watchdog: cada nó Oi compartilha secretamente um valor de watchdog de um bit wi ∈{no alert, alert} entre os nós da segunda camada para cada relatório gerado. 2. Dicas anônimas: Qualquer nó oracle pode enviar uma dica anônima α ao comitê de segundo nível na mesma rodada em que os bits de vigilância são enviados. Essa dica α é uma mensagem indicando que um alerta foi gerado para o relatório atual. 3. Verificação de bits de vigilância: o comitê de segundo nível revela o cão de guarda dos nós oracle bits em ordem de prioridade. Observe que os nós não devem enviar bits de vigilância de alerta quando não alertam: caso contrário, a análise de tráfego revela os bits de todos os nós. O protocolo revela o não alerta bits de watchdog de nós com prioridade mais alta do que o watchdog de alerta de maior prioridade. Observe que o que é revelado é idêntico ao do nosso protocolo n-round. As recompensas também são distribuídas de forma idêntica a esse esquema, ou seja, o primeiro cão de guarda identificado recebe os depósitos reduzidos de nós que enviaram relatórios incorretos.O uso de denúncias anônimas permite que o comitê de segundo nível permaneça não interativo nos casos em que nenhum alerta foi levantado, reduzindo a complexidade da comunicação no caso comum. Observe que qualquer cão de guarda que emita um alerta tem um incentivo econômico para enviar uma denúncia anônima: se nenhuma denúncia for enviada, nenhuma recompensa será paga a qualquer nó. Para garantir que o remetente Oi de uma denúncia anônima α não possa ser identificado pelo adversário com base em dados de rede, a denúncia anônima pode ser enviada por meio de uma rede anônima canal, por exemplo, via Tor, ou, mais praticamente, proxy através de um provedor de serviços em nuvem. Para autenticar a ponta como originária de O, Oi pode assinar α usando uma assinatura de anel [39, 192]. Alternativamente, para evitar ataques de negação de serviço não atribuíveis contra o comitê de segundo nível por um nó oracle malicioso, α pode ser uma credencial anônima com anonimato revogável [73]. Este protocolo, embora praticamente alcançável, possui engenharia um tanto pesada requisitos (que estamos explorando maneiras de reduzir). Nós de primeira camada, por exemplo, deve se comunicar diretamente com nós de segunda camada, exigindo manutenção de um diretório. A necessidade de canais anônimos e assinaturas em anel aumenta a engenharia complexidade do esquema. Finalmente, há um requisito especial de confiança brevemente discutido na nota abaixo. Estamos, portanto, também a explorar esquemas mais simples que ainda alcançam impacto superlinear staking, mas talvez menos que quadrático, em que um subornador precisa assintoticamente de recursos de pelo menos $n log n, por exemplo. Alguns dos esquemas sob consideração envolve a seleção aleatória de um subconjunto estrito de nós para atuar como vigilantes, nesse caso, o possível suborno torna-se um ataque especialmente poderoso. Observação: A segurança deste mecanismo staking de rodada única requer canais entre oracle e nós de segundo nível - um requisito padrão em sistemas resistentes à coerção, por exemplo, votação [82, 138], e um requisito razoável na prática. Além disso, porém, um nó da Oi que busca cooperar com um subornador pode construir suas ações secretas de forma a mostrar ao subornador que ele codificou um determinado valor. Por exemplo, se a Oi não sabe quais nós o subornador controla, então a Oi pode enviar ações com valor 0 para todos os membros do comitê. O subornador pode então verificar as informações da Oi conformidade probabilisticamente. Para evitar este problema em qualquer protocolo de rodada única, exigir que a Oi conheça a identidade de pelo menos um nó honesto de segunda camada. Com um protocolo interativo no qual cada nó de segunda camada adiciona uma randomização fator para as ações, o melhor que o subornador pode fazer é forçar a seleção pela Oi de um número aleatório pedaço de cão de guarda. 9.6 Quadro de Incentivos Implícitos (IIF) FFO é uma forma de incentivo implícito para o comportamento correto na rede Chainlink. Isso funciona como participação explícita, ou seja, depósitos, na medida em que ajuda a reforçar a segurança económica para a rede. Em outras palavras, o FFO deve ser incluído como parte do depósito (efetivo) $d de um nó na rede.A questão é: como medimos o FFO e outras formas de incentivo implícito dentro da rede Chainlink? O Quadro de Incentivos Implícitos (IIF) é um conjunto de princípios e técnicas que planejamos desenvolver para esse fim. Sistemas Blockchain fornecem muitas formas de transparência sem precedentes e os registros de alta confiança dos nós O desempenho que eles criam é um trampolim para a nossa visão de como o IIF funcionará. Aqui esboçamos brevemente ideias sobre elementos-chave do IIF. O próprio IIF consistirá em um conjunto de fatores que identificamos como importantes na avaliação incentivos implícitos, juntamente com mecanismos para publicação de dados relevantes de forma altamente segura para consumo por algoritmos analíticos. Diferentes usuários Chainlink podem desejam usar o IFI de maneiras diferentes, por exemplo, dando pesos diferentes a fatores diferentes. Esperamos que surjam serviços de análise na comunidade que ajudem os usuários a aplicar o IIF de acordo com suas preferências individuais de avaliação de risco, e nosso objetivo é facilitar tais serviços, garantindo o seu acesso a dados de apoio de alta segurança e oportunos, conforme discutiremos abaixo (Seção 9.6.4). 9.6.1 Oportunidade de taxas futuras Os nós participam do ecossistema Chainlink para ganhar uma parte das taxas que as redes pagam por qualquer um dos vários serviços descritos neste artigo, desde feeds de dados comuns para serviços avançados, como identidade descentralizada, sequenciamento justo, e preservação de confidencialidade DeFi. As taxas na rede Chainlink suportam os custos dos operadores de nós para, por exemplo, executar servidores, adquirir licenças de dados necessárias e manter uma equipe global para garantir alto tempo de atividade. FFO denota as taxas de serviço, líquidas de despesas, que um nó pode ganhar no futuro – ou perder caso demonstre comportamento defeituoso. FFO é uma forma de participação que ajuda a proteger a rede. Uma característica útil do FFO é o fato de que os dados on-chain (complementados por dados off-chain dados) estabelecem um registro de alta confiança do histórico de um nó, permitindo o cálculo do FFO de forma transparente e empiricamente orientada. Uma medida simples e de primeira ordem do FFO pode derivar da receita líquida média de um nó durante um período de tempo (ou seja, receita bruta menos despesas operacionais). FFO pode então ser calculado como, por exemplo, o valor presente líquido [114] da receita líquida futura acumulada, em outras palavras, o valor descontado no tempo de todos os ganhos futuros. A receita do nó pode ser volátil, no entanto, como mostrado, por exemplo, na Figura 17. Mais importante ainda, a receita do nó pode não seguir uma distribuição estacionária ao longo do tempo. Consequentemente, outros fatores que planejamos explorar na estimativa do FFO incluem: • Histórico de desempenho: o histórico de desempenho de um operador – incluindo a exatidão e pontualidade de seus relatórios, bem como seu tempo de atividade – fornece um objetivo pedra de toque para os usuários avaliarem sua confiabilidade. O histórico de desempenho será, portanto, fornecem um fator crítico na seleção de nós oracle pelos usuários (ou, com o advento de DONs, sua seleção de DONs). É provável que um forte histórico de desempenho correlacionar com alta receita contínua.18 18Uma importante questão de investigação que pretendemos abordar é a detecção de volumes de serviços falsificados.Figura 17: Receita obtida por nós Chainlink em um único feed de dados (ETH-USD) durante uma semana representativa em março de 2021. • Acesso a dados: embora oracles possam obter muitas formas de dados de APIs abertas, certas formas de dados ou certas fontes de alta qualidade podem estar disponíveis apenas em um por assinatura ou por meio de acordos contratuais. Acesso privilegiado a determinados as fontes de dados podem desempenhar um papel na criação de um fluxo de receitas estável. • Participação de DON: Com o advento de DONs, comunidades de nós surgirão juntos para fornecer serviços específicos. Esperamos que muitos DONs incluam operadores de forma seletiva, estabelecendo participação em DONs respeitáveis como um posição privilegiada no mercado que ajuda a garantir uma fonte consistente de receitas. • Atividade entre plataformas: alguns operadores de nós podem ter presenças bem estabelecidas e registros de desempenho em outros contextos, por exemplo, como PoS validators ou provedores de dados em contextos não blockchain. O seu desempenho nestes outros sistemas (quando os dados sobre eles estão disponíveis de forma confiável) pode informar a avaliação de seu histórico de desempenho. Da mesma forma, comportamento defeituoso na rede Chainlink pode comprometer a receita nesses outros sistemas, afastando usuários, ou seja, FFO pode se estender através de plataformas. 9.6.2 FFO especulativo Os operadores de nós participam da rede Chainlink não apenas para gerar receita de operações, mas sim criar e posicionar-se para aproveitar novas oportunidades para administrar empregos. Em outras palavras, os gastos por oracle nós da rede também são uma declaração positiva sobre o futuro de DeFi e outras aplicações de contratos inteligentes domínios, bem como aplicativos emergentes não blockchain de redes oracle. Os operadores de nós hoje ganham as taxas disponíveis nas redes Chainlink existentes e, simultaneamente, Estas são vagamente análogas às avaliações falsas em sites da Internet, exceto que o problema é mais fácil no oracle porque temos um registro definitivo se as mercadorias, ou seja, relatórios, foram encomendadas e entregues - em oposição, por exemplo, a bens físicos encomendados em lojas online. Dito de outra forma, no oracle configuração, o desempenho pode ser validado, mesmo que a veracidade do cliente não possa.construir uma reputação, histórico de desempenho e conhecimento operacional que posicionará vantajosamente para ganhar taxas disponíveis em redes futuras (contingentes, é claro, sobre comportamento honesto). Os nós que operam no ecossistema Chainlink hoje irão neste sentido, têm uma vantagem sobre os recém-chegados em ganhar taxas adicionais Chainlink serviços ficam disponíveis. Esta vantagem aplica-se a novos operadores, bem como a empresas de tecnologia com reputação estabelecida; por exemplo, a T-Systems, uma tradicional fornecedor de tecnologia (subsidiária da Deutsche Telekom) e Kraken, uma grande empresa centralizada exchange, estabeleceram presenças iniciais no ecossistema Chainlink [28, 143]. Tal participação dos nós oracle em oportunidades futuras pode ser considerada em si como uma espécie de FFO especulativo e, portanto, constitui uma forma de participação no Chainlink rede. 9.6.3 Reputação Externa O IIF, como o descrevemos, pode operar em uma rede com nomes estritamente pseudônimos. operadores, ou seja, sem divulgação das pessoas ou entidades do mundo real envolvidas. Um fator potencialmente importante para a seleção de fornecedores pelos usuários, no entanto, é a reputação. Por reputação externa entendemos a percepção de confiabilidade associada a identidades do mundo real, em vez de pseudônimos. Risco reputacional associado a identidades do mundo real podem ser vistas como uma forma de incentivo implícito. Nós vemos a reputação através das lentes do IIF, ou seja, no sentido criptoeconômico, como meio de estabelecer atividade multiplataforma que pode ser incorporada nas estimativas de FFO. O benefício de usar a reputação externa como um fator nas estimativas do FFO, em oposição à ligação por pseudônimo, é que a reputação externa vincula o desempenho não apenas a um atividades atuais do operador, mas também às futuras. Se, por exemplo, uma má reputação atribui a uma pessoa individual, pode manchar os futuros empreendimentos dessa pessoa. Dito de outra forma, a reputação externa pode capturar uma faixa mais ampla de FFO do que o pseudônimo registros de desempenho, como o impacto da má conduta associada a uma pessoa ou estabelecida empresa é mais difícil de escapar do que aquela associada a uma operação pseudônima. Chainlink é compatível com tecnologias de identidade descentralizadas (Seção 4.3) que pode fornecer suporte para o uso da reputação externa no IFI. Tais tecnologias pode validar e, assim, ajudar a garantir a veracidade das declarações do mundo real afirmadas pelos operadores. identidades.19 9.6.4 Abra a análise IIF O IIF, como observamos, visa fornecer dados e ferramentas confiáveis e de código aberto para análise de incentivo implícito. O objetivo é capacitar os provedores da comunidade desenvolver análises adaptadas às necessidades de avaliação de risco de diferentes partes do Chainlink base de usuários. 19Credenciais de identidade descentralizadas também podem, quando desejado, embelezar pseudônimos com informações validadas informações complementares. Por exemplo, um operador de nó poderia, em princípio, usar essas credenciais para provar que se trata de uma empresa Fortune 500, sem revelar qual.Uma quantidade considerável de dados históricos sobre receita e desempenho dos nós reside na cadeia de uma forma imutável e de alta confiança. Nosso objetivo, no entanto, é fornecer o dados mais abrangentes possíveis, incluindo dados sobre comportamentos que são visíveis apenas fora cadeia, como relatório fora da cadeia (OCR) ou atividade DON. Esses dados podem potencialmente ser volumoso. A melhor forma de armazená-lo e garantir sua integridade, ou seja, protegê-lo de a adulteração, acreditamos, será com a ajuda de DONs, usando técnicas discutidas na Seção 3.3. Alguns incentivos se prestam a formas diretas de medição, como staking depósitos e FFO básico. Outros, como o FFO especulativo e a reputação, são mais difíceis de medir de maneira objetiva, mas acreditamos que apoiar formas de dados, incluindo crescimento histórico do ecossistema Chainlink, métricas de reputação de mídia social, etc., pode suportar modelos analíticos IIF mesmo para esses elementos mais difíceis de quantificar. Podemos imaginar que DONs dedicados surgem especificamente para monitorar, validar e registrar dados relacionados a registros de desempenho off-chain de nós, bem como outros dados usados no IIF, como informações de identidade validadas. Esses DONs podem fornecer dados IIF uniformes e de alta confiança para qualquer provedor de análise que atenda à comunidade Chainlink. Eles também fornecerão um registro de ouro que fará com que as reivindicações dos provedores de análise verificável de forma independente pela comunidade. 9.7 Juntando tudo: incentivos para operadores de nós Sintetizando nossas discussões acima sobre incentivos explícitos e implícitos para operadores de nós fornece uma visão holística das maneiras pelas quais os operadores de nós participam e se beneficiam a rede Chainlink. Como guia conceitual, podemos expressar o total de ativos em jogo por um determinado Chainlink operador de nó $S em uma forma aproximada e estilizada como: $S ≈$D + $F + $FS +$R, onde: • $D é o agregado de todas as participações explicitamente depositadas em todas as redes nas quais a operadora participa; • $F é o valor presente líquido do agregado de todos os FFO em todas as redes em em que o operador participa; • $FS é o valor presente líquido do FFO especulativo do operador; e • $R é o patrimônio reputacional do operador fora do ecossistema Chainlink que pode ser prejudicado pelo mau comportamento identificado em seus nós oracle. Embora em grande parte conceitual, essa igualdade aproximada mostra de forma útil que há uma multiplicidade de fatores econômicos que favorecem o desempenho de alta confiabilidade dos nós Chainlink. Todos esses fatores, exceto $D, estão presentes nas redes Chainlink atuais.9,8 O Ciclo Virtuoso da Segurança Económica A combinação do impacto superlinear staking com representação de pagamentos de taxas como a oportunidade de taxas futuras (FFO) no IIF pode levar ao que chamamos de ciclo virtuoso de segurança econômica em uma rede oracle. Isto pode ser visto como uma espécie de economia de escala. À medida que o montante total garantido por uma determinada rede aumenta, o montante de a participação adicional necessária para adicionar uma quantidade fixa de segurança econômica diminui, assim como o custo médio por usuário. Portanto, é mais barato, em termos de taxas, para um usuário aderir uma rede já existente do que alcançar o mesmo aumento na economia de rede segurança criando uma nova rede. É importante ressaltar que a adição de cada novo usuário diminui o custo do serviço para todos os usuários anteriores dessa rede. Dada uma estrutura de taxas específica (por exemplo, uma taxa de rendimento específica sobre o valor apostado), se o total de taxas recebidas por uma rede aumentar, isso incentiva o fluxo de recursos adicionais apostar na rede para protegê-la a uma taxa mais alta. Especificamente, se a aposta total um nó individual pode reter no sistema é limitado, então, quando novos pagamentos de taxas entrar no sistema, aumentando seu FFO, o número de nós n aumentará. Graças ao impacto superlinear staking do design do nosso sistema de incentivos, a segurança econômica de o sistema subirá mais rápido que n, por exemplo, como n2 no mecanismo que esboçamos na Seção 9.4. Como resultado, o custo médio para a segurança económica – ou seja, a quantidade de participação que contribui um dólar de segurança económica – cairá. A rede pode, portanto, cobrar de seus usuários taxas mais baixas. Supondo que a demanda por serviços oracle seja elástica (ver, por exemplo, [31] para um breve explicação), a demanda aumentará, gerando taxas e FFO adicionais. Ilustramos esse ponto com o seguinte exemplo. Exemplo 5. Visto que a segurança económica de uma rede oracle com o nosso incentivo esquema é $dn2 for stake $dn, a segurança econômica contribuída por um dólar de participação é n e, portanto, o custo médio por dólar de segurança econômica - ou seja, o valor da participação contribuir para um dólar de segurança económica – é 1/n. Considere uma rede na qual os incentivos económicos consistem inteiramente em FFO, limitados em $d ≤$10K por nó. Suponha que a rede tenha n = 3 nós. Então o custo médio por dólar de segurança económica é de cerca de 0,33 dólares. Suponha que o FFO total da rede ultrapasse $30K (e.g., to $31K). Dado o limite de FFO por nó, a rede cresce para (pelo menos) n = 4. Agora o custo médio por dólar de segurança económica cai para cerca de 0,25 dólares. Ilustramos esquematicamente o ciclo virtuoso completo da segurança económica nas redes oracle na Fig. Enfatizamos que o ciclo virtuoso da segurança económica deriva do efeito dos usuários agrupando suas taxas. É o seu FFO colectivo que trabalha a favor de maiores tamanhos de rede e, portanto, maior segurança coletiva. Notamos também que o ciclo virtuoso da segurança económica funciona a favor de DONs alcançarem a sustentabilidade financeira. Uma vez criados, DONs que atendem às necessidades do usuário devem crescer até e além do ponto em que a receita proveniente de taxas excede os custos operacionais para nós oracle.

Revenue earned by Chainlink nodes on a single ETH-USD data feed showing correlation with price volatility

Diagram showing how concentrated alerting rewards amplify the cost for a briber attempting to corrupt the oracle network

Schematic of Chainlink staking scheme with alerting showing watchdog escalation and penalty mechanisms

Schematic of the virtuous cycle of Chainlink staking showing how user fees drive security and value capture

Figura 18: Esquema do ciclo virtuoso de Chainlink staking. Um aumento nas taxas de utilização pagamentos para uma rede oracle 1⃝faz com que ela cresça, levando ao crescimento de sua economia segurança 2⃝. Este crescimento superlinear realiza economias de escala em redes Chainlink 3⃝. Especificamente, significa uma redução no custo médio da segurança económica, ou seja, a segurança econômica por dólar decorrente de pagamentos de taxas ou outras fontes de participação aumenta. Custos mais baixos, repassados aos usuários, estimulam o aumento da demanda por oracle serviços 4⃝. 9,9 Fatores adicionais que impulsionam o crescimento da rede À medida que o ecossistema Chainlink continua a se expandir, acreditamos que a sua atratividade para os usuários e a importância da infraestrutura para a economia blockchain irá acelerar. O valor fornecido pelas redes oracle é superlinear, o que significa que cresce mais rápidodo que o tamanho das próprias redes. Este crescimento em valor decorre tanto economias de escala – maior eficiência de custos por usuário à medida que os volumes de serviço aumentam – e efeitos de rede – um aumento da utilidade da rede à medida que os usuários adotam DONs mais amplamente. À medida que os smart contracts existentes continuam a ver mais valor garantido e totalmente novo smart contract aplicações são possibilitadas por serviços mais descentralizados, o total o uso e as taxas agregadas pagas a DONs devem aumentar. Aumentar os conjuntos de taxas em por sua vez, traduzem-se em meios e incentivos para criar serviços ainda mais descentralizados, resultando em um ciclo virtuoso. Este ciclo virtuoso resolve uma questão crítica do ovo e da galinha problema no ecossistema híbrido smart contract: recursos inovadores smart contract muitas vezes exigem serviços descentralizados que ainda não existem (por exemplo, novos mercados DeFi muitas vezes exigem novos fluxos de dados) mas precisam de procura económica suficiente para existirem. O agrupamento de taxas por vários smart contracts para DONs existentes sinalizará a demanda por serviços descentralizados adicionais a partir de uma base de utilizadores crescente, dando origem à sua criação por DONs e uma capacitação contínua de novos e variados smart contracts híbridos. Em resumo, acreditamos que o crescimento da segurança de rede impulsionado por princípios virtuosos ciclos no mecanismo Chainlink staking exemplificam padrões maiores de crescimento que a rede Chainlink pode ajudar a criar uma economia em cadeia para descentralização serviços.

Conclusion

In this paper, we have set forth a vision for Chainlink’s evolution. The main theme in this vision is oracle networks’ ability to provide a much broader range of service for smart contracts than mere data delivery. Using DONs as a foundation for the decentralized services of the future, Chainlink will aim to provide performant, conﬁdentialityenhanced oracle functionality. Its oracle networks will oﬀer strong trust minimization through a combination of principled cryptoeconomic mechanisms such as staking and carefully conceived guard rails and service-level enforcement on relying main chains. DONs will also help layer-2 systems enforce ﬂexible, fair ordering policies on transactions, as well as reduced gas costs for mempool-routed transactions. Taken together, these capabilities all drive in the direction of secure and richly functional hybrid smart contracts. The ﬂexibility of DONs will enhance existing Chainlink services and give rise to many additional smart contract features and applications. Among these are seamless connection to a wide variety of oﬀ-chain systems, decentralized identity creation from existing data, priority channels to help ensure timely delivery of infrastructure-critical transactions, and conﬁdentiality-preserving DeFi instruments. The vision we’ve set forth here is ambitious. In the short term, we seek to empower hybrid contracts to accomplish goals beyond the reach of smart contracts today, while in the long term we aim to realize a decentralized metalayer. Happily we can draw on new tools and ideas—ranging from consensus algorithms to zero-knowledge proof systems—that the community is developing as the fruit of rapidly evolving research.

Similarly, we expect to prioritize implementation of the ideas in this paper in response to the needs of Chainlink’s community of users. We look forward to the next stage in our quest to empower smart contracts through universal connectivity and establish decentralized technologies as the backbone of the world’s next generation of ﬁnancial and legal systems. Acknowledgements Thanks to Julian Alterini and Shawn Lee for rendering the ﬁgures in this paper.

Conclusão

Neste artigo, apresentamos uma visão para a evolução de Chainlink. O tema principal nesta visão está a capacidade das redes oracle de fornecer uma gama muito mais ampla de serviços para smart contracts do que a mera entrega de dados. Usando DONs como base para os serviços descentralizados do futuro, Chainlink terá como objetivo fornecer funcionalidade oracle de desempenho e confidencialidade aprimorada. Suas redes oracle oferecerão forte minimização de confiança através de uma combinação de mecanismos criptoeconômicos de princípios, como staking e guarda-corpos cuidadosamente concebidos e aplicação do nível de serviço em cadeias principais confiáveis. DONs também ajudarão os sistemas de camada 2 a aplicar políticas de pedidos flexíveis e justas nas transações, bem como a reduzir os custos de gás para transações roteadas em mempool. Tomados em conjunto, todos esses recursos direcionam na direção de sistemas inteligentes híbridos seguros e altamente funcionais contratos. A flexibilidade dos DONs irá melhorar os serviços Chainlink existentes e dar origem a muitos recursos e aplicativos smart contract adicionais. Entre estes estão perfeitos conexão a uma ampla variedade de sistemas fora da cadeia, criação descentralizada de identidade a partir de dados existentes, canais prioritários para ajudar a garantir a entrega oportuna de recursos críticos para a infraestrutura transações e instrumentos de preservação de confidencialidade DeFi. A visão que apresentamos aqui é ambiciosa. No curto prazo, procuramos capacitar contratos híbridos para cumprir metas além do alcance de smart contracts hoje, enquanto no longo prazo, pretendemos realizar uma metacamada descentralizada. Felizmente podemos desenhar em novas ferramentas e ideias – desde algoritmos de consenso até prova de conhecimento zero sistemas – que a comunidade está desenvolvendo como fruto de pesquisas em rápida evolução.

Da mesma forma, esperamos priorizar a implementação das ideias deste documento em resposta às necessidades da comunidade de usuários de Chainlink. Estamos ansiosos pela próxima etapa em nossa busca para capacitar smart contracts por meio da conectividade universal e estabelecer tecnologias descentralizadas como a espinha dorsal da próxima geração de recursos financeiros do mundo e sistemas jurídicos. Agradecimentos Agradecimentos a Julian Alterini e Shawn Lee pela representação das figuras neste artigo.