Chainlink: Jaringan Oracle Terdesentralisasi
Abstract
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 confidentiality-preserving universal connectivity and off-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, offering interfaces for smart contracts to extensive off-chain resources and highly efficient yet decentralized off-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: Offering a powerful, general framework for augmenting existing smart contract capabilities by securely composing on-chain and off-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. • Confidentiality: Enabling next-generation systems that combine blockchains’ innate transparency with strong new confidentiality 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.
Abstrak
Dalam whitepaper ini, kami mengartikulasikan visi evolusi Chainlink melampaui konsep awalnya dalam whitepaper Chainlink asli. Kami meramalkan peran yang semakin luas untuk jaringan oracle, yang mana jaringan tersebut melengkapi dan meningkatkan blockchain yang sudah ada dan yang baru dengan menyediakan layanan yang cepat, andal, dan konektivitas universal yang menjaga kerahasiaan dan komputasi off-chain untuk smart contractdtk. Landasan rencana kami adalah apa yang kami sebut Jaringan Oracle Terdesentralisasi, atau DONs singkatnya. DON adalah jaringan yang dikelola oleh komite Chainlink node. Ini mendukung berbagai fungsi oracle yang tidak terbatas yang dipilih penyebaran oleh panitia. Dengan demikian, DON bertindak sebagai lapisan abstraksi yang kuat, menawarkan antarmuka untuk smart contracts ke sumber daya off-chain yang luas dan sangat sumber daya komputasi off-chain yang efisien namun terdesentralisasi dalam DON itu sendiri. Dengan DONs sebagai batu loncatan, Chainlink berencana untuk fokus pada kemajuan dalam tujuh bidang utama: • Hybrid smart contracts: Menawarkan kerangka kerja umum yang kuat untuk meningkatkan kemampuan smart contract yang ada dengan menyusun on-chain secara aman dan sumber daya komputasi off-chain menjadi apa yang kami sebut hybrid smart contracts. • Mengabstraksi kompleksitas: Menghadirkan pengembang dan pengguna dengan sederhana fungsionalitas menghilangkan kebutuhan untuk memahami hal-hal mendasar yang kompleks protokol dan batasan sistem. • Penskalaan: Memastikan bahwa layanan oracle mencapai latensi dan throughput dituntut oleh sistem desentralisasi yang berkinerja tinggi. • Kerahasiaan: Memungkinkan sistem generasi berikutnya yang menggabungkan blockchains' transparansi bawaan dengan perlindungan kerahasiaan baru yang kuat untuk sensitif data. • Kewajaran pesanan untuk transaksi: Mendukung pengurutan transaksi dengan berbagai cara yang adil bagi pengguna akhir dan mencegah serangan front-running dan lainnya bot dan penambang eksploitatif. • Minimalkan kepercayaan: Menciptakan lapisan dukungan yang sangat dapat dipercaya smart contracts dan sistem lain yang bergantung pada oracle melalui desentralisasi, penahan yang kuat pada blockchains dengan keamanan tinggi, kriptografi teknik, dan jaminan kriptoekonomi. • Keamanan berbasis insentif (kriptoekonomi): Merancang secara ketat dan menerapkan mekanisme yang kuat untuk memastikan node di DONs memiliki insentif ekonomi yang kuat untuk berperilaku andal dan benar, bahkan dalam menghadapi musuh yang mempunyai sumber daya yang baik. Kami menyajikan inovasi awal dan berkelanjutan dari komunitas Chainlink di masing-masing bidang tersebut, memberikan gambaran mengenai perluasan dan peningkatannya kemampuan canggih yang direncanakan untuk jaringan Chainlink.
Introduction
Introduction
Blockchain oracles are often viewed today as decentralized services with one objective: to forward data from off-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 justifies 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 off-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 off-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 confidentiality-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 verifiable random functions (VRF) and Off-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 offer a fresh definition 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 off-chain resources for both smart contracts and other systems. It also provides access to highly efficient yet decentralized off-chain computing resources. In general, a DON supports operations on a main chain. Its goal is to enable secure and flexi-
ble hybrid smart contracts, which combine on-chain and off-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, confidentiality, 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 offer these resources with strong confidentiality, integrity, and availability properties,1 as well as accountability. DONs are formed by committees of oracle nodes that cooperate to fulfill a specific 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 flexible tool for application developers to create off-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 benefits, including high performance and the ability to perform confidential 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].
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 figure showing as an example how a Decentralized Oracle Network can realize basic oracle functionality, i.e., relay off-chain data to a contract. An executable uses adapters to fetch off-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 flow 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 benefit 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 briefly 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 off-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 benefit from real-world data and a variety of functionalities that are inherently unachievable on chain, including various forms of confidential 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 off-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 off-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 first 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 first, overarching one of hybrid contracts. These focuses involve removing visible complexity from hybrid contracts, creating additional off-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 flexible 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 / off-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 off-chain data access and other key oracle services. 3Chainlink services comprise a variety of decentralized services and functionality available through the network. They are offered by the numerous node operators composed into various oracle networks across the ecosystem.
Figure 2: Conceptual figure depicting on-chain / off-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 off-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 off-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 offer 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 specific 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 / off-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 unified 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 first 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 offchain computation and connectivity among various blockchains and existing off-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 different configurations to run in parallel; different DApps and users can navigate tradeoffs in underlying consensus choices according to their application requirements. DONs may be viewed in effect as layer-2 technologies. We expect that among other services, DONs will support the Transaction Execution Framework (TEF), which facilitates efficient integration of DONs and thus oracles with other high-performance layer-2 systems—e.g., rollups, systems which bundle transactions offchain to achieve performance improvements. We introduce the TEF in Section 6.
Figure 3: Conceptual figure showing ideal realization of a decentralized metalayer. For ease of development, a developer specifies a DApp, highlighted in pink, as a virtual application in a unified 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 offchain, rather than on chain. This shift in the main locus of computation reduces transaction latency and fees while boosting transaction throughput. Confidentiality: Blockchains provide unprecedented transparency for smart contracts and the applications they realize. But there is a basic tension between transparency and confidentiality. Today, for example, users’ decentralized exchange trans-
Figure 4: Conceptual figure 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’ effects—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’ financial 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 confidentiality protections. In this paper, we show how they will do so using three main approaches: • Confidentiality-preserving adapters: Two technologies with planned deployment in Chainlink’s networks, DECO [234] and Town Crier [233], enable oracle nodes to retrieve data from off-chain systems in ways that protect user privacy and data confidentiality. They will play a key role in the design of adapters for DONs. (See Section 3.6.2 for details on these two technologies.) • Confidential computation: DONs can simply conceal their computation from relying blockchains. Using secure multi-party computation and/or trusted execution environments, stronger confidentiality is also possible in which DON nodes compute over data into which they themselves do not have visibility.
• Support for confidential 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 confidentiality. 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 flow from external sources to a smart contract by means of confidentiality-preserving adapters and confidential computation in a DON. Figure 5: Conceptual diagram of confidentiality-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 confidentiality-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 confidential 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 confidential data will open up a whole range of applications. Among these are private decentralized (and centralized) finance, decentralized identity, credit-based on-chain lending, and more efficient 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-
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—effectively 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 benefit, FSS can also lower users’ network fees (e.g., gas costs). Briefly, 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 beneficial. 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 five 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.
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 figure 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 financial incentive to behave correctly. Staking, i.e., requiring nodes to provide deposits of LINK and slashing (confiscating) 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 different from staking in standalone blockchains. Staking in blockchains aims to prevent attacks on consensus. It has a different 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 unprofitable 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:
- 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., offers 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 fixed 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 specifics. 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, confidentiality 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.
Perkenalan
Blockchain oracles saat ini sering dipandang sebagai layanan terdesentralisasi dengan satu tujuan: untuk meneruskan data dari sumber daya off-chain ke blockchains. Namun ini adalah langkah singkat, mulai dari meneruskan data hingga menghitungnya, menyimpannya, atau mengirimkannya secara dua arah. Pengamatan ini membenarkan gagasan yang lebih luas tentang fungsi oracles. Begitu juga memenuhi kebutuhan layanan smart contracts yang semakin meningkat dan semakin beragam teknologi yang mengandalkan jaringan oracle. Singkatnya, oracle bisa dan perlu menjadi antarmuka dengan tujuan umum, dua arah, dan mendukung komputasi antara dan di antara sistem onchain dan off-chain. Peran Oracles dalam ekosistem blockchain adalah untuk meningkatkan kinerja, fungsionalitas, dan interoperabilitas smart contracts sehingga bisa membawa model kepercayaan dan transparansi baru ke berbagai industri. Transformasi ini akan terjadi melalui perluasan penggunaan smart contract hibrida, yang dapat digabungkan properti khusus blockchains dengan kemampuan unik sistem off-chain seperti oracle jaringan dan dengan demikian mencapai jangkauan dan kekuatan yang jauh lebih besar daripada sistem on-chain dalam isolasi. Dalam whitepaper ini, kami mengartikulasikan visi untuk apa yang kami sebut Chainlink 2.0, sebuah evolusi dari Chainlink melampaui konsepsi awalnya dalam whitepaper Chainlink asli [98]. Kami memperkirakan peran jaringan oracle akan semakin besar, salah satunya adalah mereka melengkapi dan menyempurnakan blockchain yang sudah ada dan yang baru dengan menyediakan konektivitas dan komputasi universal yang cepat, andal, dan menjaga kerahasiaan untuk perangkat hybrid smart contracts. Kami percaya bahwa jaringan oracle bahkan akan berkembang menjadi utilitas untuk mengekspor data tingkat blockchain berintegritas tinggi ke sistem di luar blockchain ekosistem. Saat ini, Chainlink node yang dijalankan oleh beragam entitas berkumpul di oracle jaringan untuk menyampaikan data ke smart contracts dalam apa yang dikenal sebagai laporan. Kita bisa melihatnya oracle node sebagai komite serupa dengan konsensus klasik blockchain [72], namun dengan tujuan mendukung blockchain yang sudah ada, dibandingkan menyediakan fungsionalitas yang berdiri sendiri. Dengan fungsi acak yang dapat diverifikasi (VRF) dan Pelaporan Off-Chain (OCR), Chainlink telah berkembang menuju kerangka kerja dan infrastruktur tujuan umum untuk menyediakan sumber daya komputasi yang smart contracts butuhkan untuk fungsionalitas tingkat lanjut. Landasan rencana kami untuk Chainlink 2.0 adalah apa yang kami sebut Oracle Terdesentralisasi Jaringan, atau disingkat DONs. Sejak kami memperkenalkan istilah “oracle jaringan” di whitepaper Chainlink asli [98], oracles telah mengembangkan fungsionalitas yang lebih kaya dan luasnya aplikasi. Dalam makalah ini, kami menawarkan definisi baru tentang istilah menurut untuk visi masa depan kami untuk ekosistem Chainlink. Dalam tampilan ini, DON adalah jaringan dikelola oleh komite yang terdiri dari Chainlink node. Berakar pada protokol konsensus, itu mendukung berbagai fungsi oracle yang tidak terbatas yang dipilih untuk diterapkan oleh panitia. Dengan demikian, DON bertindak sebagai lapisan abstraksi blockchain, menyediakan antarmuka ke sumber daya off-chain untuk smart contracts dan sistem lainnya. Ini juga menyediakan akses ke sumber daya komputasi off-chain yang sangat efisien namun terdesentralisasi. Secara umum, a DON mendukung operasi pada rantai utama. Tujuannya adalah untuk memungkinkan keamanan dan fleksibilitasble hybrid smart contracts, yang menggabungkan komputasi on-chain dan off-chain dengan koneksi ke sumber daya eksternal. Kami menekankan bahwa bahkan dengan penggunaan komite di DONs, Chainlink itu sendiri pada dasarnya tetap tanpa izin. DONs bertindak sebagai fondasi tanpa izin kerangka kerja di mana node dapat bersatu untuk mengimplementasikan jaringan oracle khusus rezim mereka sendiri untuk penyertaan node, yang mungkin diizinkan atau tanpa izin. Dengan DONs sebagai landasan, kami berencana untuk fokus pada Chainlink 2.0 pada kemajuan dalam tujuh area utama: hybrid smart contracts, mengabstraksikan kompleksitas, penskalaan, kerahasiaan, keadilan pesanan untuk transaksi, minimalisasi kepercayaan, dan keamanan berbasis insentif (kriptoekonomi). Dalam pengantar makalah ini, kami menyajikan gambaran umum tentang Desentralisasi Oracle Networks di Bagian 1.1 dan tujuh bidang inovasi utama kami di Bagian 1.2. Kami menjelaskan organisasi sisa makalah ini di Bagian 1.3. 1.1 Jaringan Oracle Terdesentralisasi Jaringan Oracle Terdesentralisasi dirancang untuk meningkatkan dan memperluas kemampuan dari smart contracts pada target blockchain atau rantai utama melalui fungsi yang tidak tersedia secara asli. Mereka melakukannya dengan menyediakan tiga sumber daya dasar yang terdapat di dalamnya sistem komputasi: jaringan, penyimpanan, dan komputasi. DON bertujuan untuk menawarkan sumber daya ini dengan sifat kerahasiaan, integritas, dan ketersediaan yang kuat,1 seperti serta akuntabilitas. DONs dibentuk oleh komite oracle node yang bekerja sama untuk memenuhi tujuan tertentu pekerjaan atau memilih untuk menjalin hubungan jangka panjang untuk memberikan layanan yang gigih kepada klien. DON dirancang dengan cara blockchain-agnostik. Mereka berjanji untuk melayani sebagai alat yang kuat dan fleksibel bagi pengembang aplikasi untuk menciptakan dukungan off-chain smart contracts mereka di rantai utama mana pun yang didukung. Dua jenis fungsi mewujudkan kemampuan DON: executable dan adaptor. Executable adalah program yang berjalan terus menerus dan terdesentralisasi di DON. Meskipun mereka tidak secara langsung menyimpan aset rantai utama, mereka memiliki manfaat penting, termasuk kinerja tinggi dan kemampuan untuk melakukan aktivitas rahasia. komputasi. Executable berjalan secara mandiri pada DON dan bekerja secara deterministik operasi. Mereka bekerja sama dengan adaptor yang menghubungkan DON ke sumber daya eksternal dan dapat dipanggil oleh executable. Adaptor, seperti yang kami bayangkan untuk DONs, adalah a generalisasi adaptor eksternal di Chainlink hari ini. Sementara adaptor yang ada biasanya hanya mengambil data dari sumber data, adaptor dapat beroperasi dua arah; di DONs, mereka juga dapat memanfaatkan komputasi gabungan sebanyak DON node untuk mencapai fitur tambahan, seperti mengenkripsi laporan untuk konsumsi yang menjaga privasi sebuah yang dapat dieksekusi. Untuk memberikan gambaran tentang operasi dasar DON, Gambar 1 menunjukkan secara konseptual bagaimana a DON mungkin digunakan untuk mengirim laporan ke blockchain dan dengan demikian mencapai fungsionalitas oracle tradisional yang sudah ada. DONs dapat memberikan banyak fitur tambahan, namun lebih dari itu 1 “Tiga serangkai CIA” dalam keamanan informasi [123, hal. 26, §2.3.5].jaringan Chainlink yang ada. Misalnya, dalam struktur umum Gambar 1, yang dapat dieksekusi dapat merekam data harga aset yang diambil di DON, menggunakan data tersebut untuk menghitung, misalnya, rata-rata tambahan untuk laporannya. Gambar 1: Gambar konseptual yang menunjukkan contoh bagaimana Jaringan Oracle Terdesentralisasi dapat mewujudkan fungsionalitas dasar oracle, yaitu menyampaikan data off-chain ke kontrak. Sebuah executable menggunakan adaptor untuk mengambil data off-chain, yang digunakan untuk menghitung, mengirimkan output melalui adaptor lain ke target blockchain. (Adaptor dimulai dengan kode di DON, diwakili oleh kotak kecil berwarna biru; panah menunjukkan arah aliran data untuk ini contoh tertentu.) Eksekusi juga dapat membaca dan menulis ke DON lokal penyimpanan untuk menjaga status dan/atau berkomunikasi dengan executable lainnya. Jaringan, komputasi, dan penyimpanan yang fleksibel dalam DONs, semuanya terwakili di sini, memungkinkan sejumlah hal baru aplikasi. Manfaat utama DON adalah kemampuannya untuk mem-bootstrap layanan blockchain baru. DONs adalah sarana dimana jaringan oracle yang ada dapat dengan cepat menjalankan aplikasi layanan yang saat ini memerlukan penciptaan jaringan yang dibangun khusus. Kami memberikan beberapa contoh penerapan tersebut di Bagian 4. Di Bagian 3, kami memberikan detail selengkapnya tentang DONs, yang menjelaskan kemampuannya dari segi antarmuka yang mereka hadirkan untuk pengembang dan pengguna. 1.2 Tujuh Tujuan Desain Utama Di sini kami meninjau secara singkat tujuh fokus utama evolusi yang disebutkan di atas Chainlink, yaitu:Hibrida smart contracts: Inti dari visi kami untuk Chainlink adalah gagasan tentang keamanan menggabungkan komponen on-chain dan off-chain dalam smart contracts. Kami mengacu pada kontrak mewujudkan ide ini sebagai smart contracts hybrid atau kontrak hybrid.2 Blockchain sedang dan akan terus memainkan dua peran penting dalam layanan terdesentralisasi ekosistem: Keduanya merupakan lokasi di mana kepemilikan mata uang kripto terwakili dan landasan yang kuat untuk layanan yang terdesentralisasi. Oleh karena itu, kontrak pintar harus direpresentasikan atau dieksekusi secara berantai, namun kemampuan on-chainnya sangat terbatas. Murni kode kontrak on-chain lambat, mahal, dan sempit, tidak dapat mengambil manfaat dari dunia nyata data dan berbagai fungsi yang secara inheren tidak dapat dicapai dalam rantai, termasuk berbagai bentuk komputasi rahasia, pembuatan keacakan (semu) yang aman terhadap manipulasi penambang / validator, dll. Oleh karena itu, agar smart contracts dapat mewujudkan potensi penuhnya, diperlukan smart contracts untuk dirancang dengan dua bagian: bagian on-chain (yang biasanya kami tunjukkan dengan SC) dan bagian off-chain, yang dapat dieksekusi berjalan pada DON (yang biasanya kami nyatakan dengan eksekutif). Tujuannya adalah untuk mencapai komposisi fungsionalitas on-chain yang aman dengan banyaknya layanan off-chain yang ingin disediakan oleh DONs. Bersama-sama, dua bagian membuat kontrak hibrida. Kami menyajikan ide tersebut secara konseptual pada Gambar 2. Hari ini, Chainlink layanan3 seperti data feed dan VRF diaktifkan jika tidak dapat dicapai smart contract aplikasi, mulai dari DeFi hingga NFT yang dihasilkan secara wajar hingga asuransi yang terdesentralisasi, sebagai langkah pertama menuju kerangka kerja yang lebih umum. Sebagai layanan Chainlink berkembang dan tumbuh lebih berkinerja sesuai dengan visi kami dalam whitepaper ini akankah kekuatan smart contract sistem di seluruh blockchains. Enam fokus utama kami yang lain dalam whitepaper ini dapat dipandang sebagai tindakan dalam layanan yang pertama, mencakup salah satu kontrak hibrida. Fokus ini melibatkan penghapusan yang terlihat kompleksitas dari kontrak hibrid, menciptakan layanan off-chain tambahan yang memungkinkan pembangunan kontrak hibrida yang semakin mumpuni, dan, dalam kasus minimalisasi kepercayaan, memperkuat properti keamanan yang dicapai oleh kontrak hibrida. Kami meninggalkan ide itu kontrak hibrida tersirat di sebagian besar makalah ini, namun kombinasi apa pun darinya Logika MAINCHAIN dengan DON dapat dipandang sebagai kontrak hibrid. Mengabstraksi kompleksitas: DONs dirancang untuk memanfaatkan desentralisasi sistem mudah bagi pengembang dan pengguna dengan mengabstraksikan mesin yang seringkali rumit di balik rangkaian layanan DONs yang kuat dan fleksibel. Layanan Chainlink yang ada sudah memiliki fitur ini. Misalnya, data feed di Chainlink saat ini menyajikan antarmuka onchain yang tidak mengharuskan pengembang untuk memikirkan detail tingkat protokol, seperti cara OCR menerapkan pelaporan konsensus di antara sejumlah perusahaan. 2Ide komposisi kontrak on-chain / off-chain telah muncul sebelumnya dalam berbagai kendala bentuk, misalnya, sistem lapisan-2, blockchains [80] berbasis TEE, dll. Tujuan kami adalah untuk mendukung dan menggeneralisasi pendekatan ini dan memastikan bahwa pendekatan tersebut dapat mencakup akses data off-chain dan oracle penting lainnya layanan. Layanan 3Chainlink terdiri dari berbagai layanan dan fungsi terdesentralisasi yang tersedia melalui jaringan. Mereka ditawarkan oleh banyak operator node yang terdiri dari berbagai jaringan oracle di seluruh ekosistem.Gambar 2: Gambar konseptual yang menggambarkan komposisi kontrak on-chain / off-chain. SEBUAH hybrid smart contract 3⃝terdiri dari dua komponen yang saling melengkapi: on-chain komponen SC 1⃝, berada di blockchain, dan komponen off-chain exec 2⃝yang dijalankan pada DON. DON juga berfungsi sebagai jembatan antara kedua komponen seperti menghubungkan kontrak hybrid dengan sumber daya off-chain seperti layanan web, dan lainnya blockchains, penyimpanan terdesentralisasi, dll. kumpulan node yang terdesentralisasi. DONs melangkah lebih jauh dalam arti memperluas berbagai layanan yang Chainlink dapat menawarkan lapisan abstraksi kepada pengembang menyertai antarmuka yang disederhanakan untuk layanan tingkat tinggi. Kami menyajikan beberapa contoh penerapan di Bagian 4 yang menyoroti pendekatan ini. Kami membayangkan perusahaan, misalnya, menggunakan DONs sebagai bentuk middleware yang aman untuk sambungkan sistem lama mereka ke blockchains. (Lihat Bagian 4.2.) Penggunaan DON ini menghilangkan kompleksitas dinamika blockchain secara umum (biaya, pengaturan ulang, dll.). Itu juga mengabstraksi fitur-fitur blockchain tertentu, sehingga memungkinkan perusahaan untuk menghubungkan sistem mereka yang ada ke rangkaian sistem blockchain yang semakin luas tanpa kebutuhan akan keahlian khusus dalam sistem ini atau, yang lebih umum, dalam pengembangan sistem yang terdesentralisasi. Pada akhirnya, ambisi kami adalah untuk mendorong tingkat abstraksi yang dicapai oleh Chainlink sampai pada penerapan apa yang kami sebut sebagai lapisan meta terdesentralisasi. Lapisan seperti itu akan mengabstraksikan perbedaan on-chain / off-chain untuk semua kelas pengembang dan pengguna DApps, memungkinkan pembuatan dan penggunaan layanan terdesentralisasi dengan lancar.Untuk menyederhanakan proses pengembangan, pengembang dapat menentukan fungsionalitas DApp di metalayer sebagai aplikasi virtual dalam model mesin terpadu. Mereka bisa kemudian gunakan kompiler metalayer terdesentralisasi untuk membuat instance DApp secara otomatis sebagai serangkaian fungsi terdesentralisasi yang saling beroperasi yang mencakup blockchains, DONs, dan layanan eksternal. (Salah satu layanan eksternal ini bisa berupa sistem perusahaan, sehingga metalayer berguna untuk aplikasi yang melibatkan sistem perusahaan lama.) Seperti itu kompilasi mirip dengan kompiler modern dan kit pengembangan perangkat lunak (SDK) mendukung pemrogram generalis dalam menggunakan potensi penuh perangkat keras heterogen arsitektur yang terdiri dari CPU tujuan umum dan perangkat keras khusus seperti GPU, akselerator pembelajaran mesin, atau kantong tepercaya. Gambar 3 menyajikan ide ini pada tingkat konseptual. Hybrid smart contracts adalah langkah pertama menuju visi ini dan konsep yang kami sebut kontrak meta. Kontrak meta adalah aplikasi yang dikodekan secara terdesentralisasi metalayer dan secara implisit mencakup logika on-chain (smart contracts), serta komputasi off-chain dan konektivitas antara berbagai blockchains dan off-chain yang ada layanan. Mengingat kebutuhan akan dukungan bahasa dan kompiler, model keamanan baru, dan harmonisasi konseptual dan teknis dari teknologi yang berbeda, namun, realisasinya dari metalayer terdesentralisasi yang sebenarnya adalah tujuan ambisius yang kami cita-citakan dalam jangka panjang cakrawala waktu. Meskipun demikian, ini merupakan model ideal yang berguna untuk diingat saat membaca makalah ini, tidak dirinci di sini, tetapi sesuatu yang kami rencanakan untuk menjadi fokus dalam pekerjaan kami di masa depan Chainlink. Penskalaan: Tujuan yang sangat penting dalam desain kami yang terus berkembang adalah memungkinkan Jaringan Chainlink untuk memenuhi kebutuhan penskalaan ekosistem blockchain yang terus meningkat. Dengan kemacetan jaringan menjadi masalah berulang dalam izin yang ada blockchains [86], desain blockchain yang baru dan lebih berperforma mulai digunakan, misalnya, [103, 120, 203], serta teknologi penskalaan lapisan-2 yang saling melengkapi, misalnya, [5, 12, 121, 141, 169, 186, 187]. Layanan Oracle harus mencapai latensi dan throughput yang memenuhi tuntutan kinerja sistem ini sekaligus meminimalkan biaya on-chain (misalnya, biaya bahan bakar) untuk operator kontrak dan pengguna biasa. Dengan DONs, Chainlink fungsionalitas bertujuan untuk melangkah lebih jauh dan memberikan kinerja yang cukup tinggi untuk sistem berbasis web murni. DONs memperoleh sebagian besar peningkatan kinerjanya dari penggunaan protokol konsensus yang cepat, berbasis komite, atau tanpa izin, yang digabungkan dengan blockchains mereka mendukung. Kami berharap banyak DON dengan konfigurasi berbeda dijalankan secara paralel; DApps yang berbeda dan pengguna dapat menavigasi trade-off dalam pilihan konsensus yang mendasarinya sesuai dengan persyaratan aplikasi mereka. DONs dapat dianggap sebagai teknologi lapisan-2. Kami mengharapkan itu di antara layanan lainnya, DONs akan mendukung Kerangka Eksekusi Transaksi (TEF), yang memfasilitasi integrasi yang efisien dari DONs dan dengan demikian oracles dengan kinerja tinggi lainnya sistem lapisan-2—misalnya, rollups, sistem yang menggabungkan transaksi secara off-chain untuk mencapai peningkatan kinerja. Kami memperkenalkan TEF di Bagian 6.
Gambar 3: Gambar konseptual yang menunjukkan realisasi ideal dari lapisan meta yang terdesentralisasi. Untuk kemudahan pengembangan, pengembang menentukan DApp, disorot dalam warna merah muda, sebagai virtual aplikasi dalam model mesin terpadu. Kompiler metalayer terdesentralisasi secara otomatis menghasilkan fungsi interoperasi yang sesuai: smart contracts (dilambangkan oleh SC), logika (dilambangkan dengan exec) pada DONs, adaptor yang terhubung ke layanan eksternal target, dan seterusnya, seperti yang ditunjukkan dalam sorotan kuning. Gambar 4 menunjukkan secara konseptual bagaimana DONs meningkatkan penskalaan blockchain (smart contract) dengan memusatkan transaksi dan oracle-pemrosesan laporan secara off-chain, bukan pada rantai. Pergeseran dalam lokus utama komputasi ini mengurangi latensi transaksi dan biaya sambil meningkatkan throughput transaksi. Kerahasiaan: Blockchain memberikan transparansi yang belum pernah ada sebelumnya untuk smart contracts dan penerapannya. Namun ada ketegangan mendasar antara transparansi dan kerahasiaan. Saat ini, misalnya, pertukaran desentralisasi penggunaGambar 4: Gambar konseptual yang menunjukkan bagaimana Jaringan Oracle Terdesentralisasi meningkatkan penskalaan blockchain yang diaktifkan smart contracts. Gambar A ⃝menunjukkan oracle konvensional arsitektur. Transaksi dikirim langsung ke blockchain, begitu pula laporan oracle. Jadi blockchain yang diberi tanda warna kuning merupakan lokus utama pemrosesan transaksi. Gambar B⃝menunjukkan penggunaan DON untuk mendukung kontrak di blockchain. Sebuah DON transaksi proses yang dapat dieksekusi bersama dengan data dari sistem eksternal dan seterusnya hasil—misalnya, transaksi gabungan atau perubahan status kontrak akibat dampak transaksi—ke blockchain. DON, yang disorot dengan warna kuning, adalah yang utama tempat pemrosesan transaksi. tindakan dicatat secara berantai, sehingga memudahkan untuk memantau perilaku pertukaran, tetapi juga membuat transaksi keuangan pengguna terlihat oleh publik. Demikian pula, data diteruskan ke smart kontrak tetap berantai. Hal ini membuat data tersebut mudah diaudit, namun bertindak sebagai disinsentif bagi penyedia data yang ingin memberikan smart contract dengan informasi sensitif atau data kepemilikan. Kami percaya bahwa jaringan oracle akan memainkan peran penting dalam mengkatalisasi generasi mendatang sistem yang menggabungkan transparansi bawaan blockchains dengan perlindungan kerahasiaan baru. Dalam makalah ini, kami menunjukkan bagaimana mereka akan melakukannya dengan menggunakan tiga pendekatan utama: • Adaptor yang menjaga kerahasiaan: Dua teknologi dengan penerapan terencana di jaringan Chainlink, DECO [234] dan Town Crier [233], aktifkan oracle node untuk mengambil data dari sistem off-chain dengan cara yang melindungi privasi dan data pengguna kerahasiaan. Mereka akan memainkan peran penting dalam desain adaptor untuk DONs. (Lihat Bagian 3.6.2 untuk rincian mengenai kedua teknologi ini.) • Perhitungan rahasia: DONs dapat dengan mudah menyembunyikan perhitungannya agar tidak mengandalkan blockchains. Menggunakan komputasi multi-pihak yang aman dan/atau lingkungan eksekusi tepercaya, kerahasiaan yang lebih kuat juga dimungkinkan di mana DON node menghitung data yang tidak dapat mereka lihat sendiri.
• Dukungan untuk sistem lapisan-2 rahasia: TEF dirancang untuk mendukung berbagai sistem lapisan-2, banyak di antaranya menggunakan bukti tanpa pengetahuan untuk memberikan berbagai bentuk kerahasiaan transaksi. Kami membahas pendekatan-pendekatan ini di Bagian 3 (dengan rincian tambahan di Bagian 6, Lampiran B.1, dan Lampiran B.2). Gambar 5 menyajikan pandangan konseptual tentang bagaimana data sensitif dapat mengalir dari sumber eksternal ke smart contract melalui adaptor yang menjaga kerahasiaan dan perhitungan rahasia dalam DON. Gambar 5: Diagram konseptual operasi menjaga kerahasiaan di DON di data sensitif (disorot dengan warna kuning). Data sumber sensitif (lingkaran hitam) di web server diekstraksi ke DON menggunakan adaptor yang menjaga kerahasiaan (garis biru, panah ganda). DON menerima data turunan (lingkaran berongga) dari adaptor ini— hasil penerapan suatu fungsi atau, misalnya, berbagi rahasia, ke sumber sensitif data. Eksekusi pada DON dapat menerapkan penghitungan rahasia pada data turunan untuk membuat laporan (lingkaran ganda), yang dikirimkan melalui adaptor ke blockchain. Kami percaya bahwa alat yang ampuh untuk menangani data rahasia akan membuka keseluruhannya berbagai aplikasi. Diantaranya adalah keuangan swasta yang terdesentralisasi (dan terpusat), identitas yang terdesentralisasi, pinjaman on-chain berbasis kredit, dan sistem yang lebih efisien dan efisien. protokol kenali pelanggan dan akreditasi yang mudah digunakan, seperti yang kita bahas di Bagian 4. Kewajaran pesanan untuk transaksi: Desain blockchain hari ini sedikit kotor rahasia umum: Mereka terpusat secara sementara. Penambang dan validator dapat memesan trans-tindakan apapun yang mereka pilih. Urutan transaksi juga dapat dimanipulasi oleh pengguna seperti fungsi dari biaya jaringan yang mereka bayarkan (misalnya, harga gas di Ethereum) dan beberapa sejauh mana dengan memanfaatkan koneksi jaringan yang cepat. Manipulasi seperti itu bisa, misalnya Misalnya saja dalam bentuk front-running, dimana aktor strategis seperti penambang mengamati transaksi pengguna dan memasukkan transaksi eksploitatifnya ke transaksi sebelumnya posisi di blok yang sama—secara efektif mencuri uang dari pengguna dengan memanfaatkan pengetahuan awal tentang transaksi pengguna. Misalnya, bot dapat melakukan pemesanan pembelian sebelum pengguna. Perusahaan kemudian dapat mengambil keuntungan dari kenaikan harga aset yang disebabkan oleh perdagangan pengguna. Dijalankan terlebih dahulu oleh beberapa bot yang merugikan pengguna biasa—sama dengan frekuensi tinggi perdagangan di Wall Street—sudah lazim dan terdokumentasi dengan baik [90], dan sebagainya serangan seperti [159] yang berjalan kembali dan peniruan transaksi otomatis [195]. Proposal untuk mensistematisasikan eksploitasi pesanan oleh para penambang bahkan telah muncul baru-baru ini [110]. Teknologi lapisan-2 seperti rollups tidak menyelesaikan masalah, namun hanya memusatkan kembali memesan, menempatkannya di tangan entitas yang menciptakan rollup. Salah satu tujuan kami adalah memperkenalkan Chainlink layanan yang disebut Fair Sequencing Layanan (FSS) [137]. FSS membantu smart contract desainer memastikan pemesanan yang adil untuk mereka transaksi dan menghindari serangan yang berjalan di depan, berjalan di belakang, dan serangan terkait terhadap transaksi pengguna serta jenis transaksi lainnya, seperti transmisi laporan oracle. FSS memungkinkan DON untuk mengimplementasikan ide-ide seperti gagasan keadilan ketertiban yang ketat dan sementara yang diperkenalkan di [144]. Sebagai manfaat tambahan, FSS juga dapat menurunkan jaringan pengguna biaya (misalnya, biaya bahan bakar). Singkatnya, di FSS, transaksi melewati DON, bukan disebarkan langsung ke target smart contract. DON memerintahkan transaksi dan kemudian meneruskannya mereka ke kontrak. Gambar 6: Contoh manfaat FSS. Gambar ⃝menunjukkan bagaimana seorang penambang, mengeksploitasinya kekuasaan terpusat untuk memesan transaksi, dapat menukar sepasang transaksi: transaksi 1⃝ tiba sebelum 2⃝, namun penambang malah mengurutkannya setelah 2⃝. Sebaliknya, Gambar B⃝menunjukkan bagaimana DON mendesentralisasikan proses pemesanan di antara DON node. Jika kuorum node yang jujur menerima 1⃝sebelum 2⃝, FSS menyebabkan 1⃝muncul sebelum 2⃝pada rantai— mencegah pemesanan ulang penambang dengan melampirkan nomor urut yang dapat ditegakkan kontrak. Gambar 6 membandingkan penambangan standar dengan FSS. Ini menunjukkan bagaimana dalam penambangan standar,proses pemesanan transaksi dipusatkan pada penambang dan karenanya tunduk pada manipulasi, seperti menyusun ulang sepasang transaksi sehubungan dengan kedatangannya kali. Sebaliknya, di FSS, prosesnya didesentralisasi di antara DON node. Dengan asumsi kuorum node yang jujur, FSS membantu menegakkan kebijakan seperti pemesanan sementara transaksi, mengurangi peluang manipulasi oleh penambang dan entitas lainnya. Selain itu, karena pengguna tidak perlu bersaing untuk mendapatkan pemesanan preferensial berdasarkan harga bahan bakar, mereka dapat membayar harga bahan bakar yang relatif rendah (sementara transaksi dari DON dapat dilakukan secara batch untuk penghematan gas). Minimalkan kepercayaan: Tujuan umum kami dalam desain DONs adalah untuk memfasilitasi lapisan dukungan yang dapat dipercaya untuk smart contracts dan sistem lain yang bergantung pada oracle melalui desentralisasi, alat kriptografi, dan jaminan ekonomi kripto. DON itu sendiri terdesentralisasi, dan pengguna dapat memilih dari DON mana pun yang tersedia mendukung rantai utama yang ingin mereka operasikan atau menghasilkan DON tambahan dengan komite node yang mereka percayai. Namun, untuk beberapa aplikasi, khususnya smart contracts, Chainlink pengguna mungkin pilihlah model kepercayaan yang memperlakukan rantai utama yang didukung oleh DON sebagai lebih dapat dipercaya daripada DON itu sendiri. Untuk pengguna seperti itu, kami sudah memiliki atau berencana untuk menggabungkannya ke dalam arsitektur jaringan Chainlink sejumlah mekanisme yang memungkinkan kontrak pada rantai utama untuk memperkuat jaminan keamanan yang diberikan oleh DONs, sementara di pada saat yang sama juga menerapkan perlindungan terhadap kemungkinan sumber data rusak seperti server web tempat DON memperoleh data. Kami menjelaskan mekanisme ini di Bagian 7. Mekanisme ini terbagi dalam lima judul utama: • Autentikasi sumber data: Alat yang memungkinkan penyedia data menandatangani secara digital data mereka dan dengan demikian memperkuat rantai pengawasan antara negara asal dan mengandalkan kontrak. • DON laporan minoritas: Bendera yang dikeluarkan oleh subset minoritas dari DON node yang mengamati penyimpangan mayoritas di DON. • Rel pengaman: Logika pada rantai utama yang mendeteksi kondisi anomali dan jeda atau menghentikan pelaksanaan kontrak (atau meminta remediasi lainnya). • Tata kelola yang minim kepercayaan: Penggunaan pembaruan yang dirilis secara bertahap untuk memfasilitasi inspeksi masyarakat, serta intervensi darurat yang terdesentralisasi untuk mempercepat respons terhadap kegagalan sistem. • Otentikasi entitas terdesentralisasi: Penggunaan infrastruktur kunci publik (PKI) untuk mengidentifikasi entitas di jaringan Chainlink. Gambar 7 menyajikan skema konseptual tujuan minimalisasi kepercayaan kami. Keamanan berbasis insentif (kriptoekonomi): Desentralisasi pembuatan laporan di seluruh oracle node membantu memastikan keamanan bahkan ketika beberapa node rusak.
Gambar 7: Penggambaran konseptual tujuan minimalisasi kepercayaan Chainlink, yaitu untuk meminimalkan kebutuhan pengguna akan perilaku yang benar dari DON dan sumber data seperti web server. Sorotan kuning pada gambar menunjukkan lokus minimalisasi kepercayaan: DON dan kumpulan server web individu atau minoritas. Sorotan merah muda menunjukkan komponen sistem yang sangat dapat dipercaya dengan asumsi: kontrak pada blockchain dan mayoritas server web, yaitu server web secara agregat. Namun, yang tidak kalah pentingnya adalah memastikan bahwa node memiliki insentif finansial untuk berperilaku benar. Staking, yaitu mengharuskan node untuk menyediakan deposit LINK dan pemotongan (menyita) simpanan ini jika terjadi perilaku buruk, akan memainkan peran penting dalam Chainlink. Ini adalah desain insentif penting yang telah digunakan di sejumlah blockchains, misalnya, [81, 103, 120, 204]. Namun, staking di Chainlink terlihat sangat berbeda dari staking di standalone blockchains. Staking di blockchains bertujuan untuk mencegah serangan terhadap konsensus. Ini memiliki tujuan yang berbeda di Chainlink: untuk memastikan pengiriman laporan oracle yang benar secara tepat waktu. Sistem staking yang dirancang dengan baik untuk jaringan oracle akan menghasilkan serangan seperti penyuapan tidak menguntungkan bagi musuh, bahkan ketika targetnya adalah smart contract dengan tinggi nilai moneter. Dalam makalah ini, kami menyajikan pendekatan umum untuk staking di Chainlink dengan tiga kunci inovasi:1. Model permusuhan yang kuat yang mencakup serangan-serangan yang diabaikan saat ini pendekatan. Salah satu contohnya adalah apa yang kita sebut suap prospektif. Ini adalah suatu bentuk penyuapan yang menentukan node mana yang menerima suap berdasarkan kondisi, misalnya, menawarkan jaminan suap terlebih dahulu ke node yang dipilih oleh mekanisme staking di acak untuk peran tertentu (seperti memicu pengambilan keputusan laporan). 2. Dampak staking super-linear, artinya secara informal bahwa agar berhasil, musuh harus memiliki anggaran $B lebih besar daripada gabungan simpanan seluruh oracle node. Lebih tepatnya, yang kami maksud adalah sebagai fungsi dari n, \(B(n) ≫\)dn di a jaringan n oracle node masing-masing dengan jumlah deposit tetap $d (lebih formalnya, \(B(n) is asymptotically larger in n than \)dn). Gambar 8 memberikan pandangan konseptual tentang properti ini. 3. Kerangka Insentif Implisit (IIF), sebuah model insentif yang telah kami rancang mencakup insentif yang dapat diukur secara empiris di luar yang disetorkan secara eksplisit staking dana, termasuk peluang biaya node di masa depan. IIF memperluas gagasan tentang mempertaruhkan di luar deposit node eksplisit. Gambar 8: Diagram konseptual yang menggambarkan penskalaan super-linear di Chainlink staking. Itu suap $B(n) yang dibutuhkan oleh musuh tumbuh lebih cepat di n dibandingkan gabungan simpanan $dn dari semua oracle node. Kami menunjukkan bagaimana dampak IIF dan super-linear staking bersama-sama menginduksi apa yang kita menyebut siklus baik keamanan ekonomi untuk jaringan oracle. Saat pengguna baru masuk
sistem, meningkatkan potensi pendapatan masa depan dari menjalankan Chainlink node, the penurunan biaya marjinal keamanan ekonomi bagi pengguna saat ini dan masa depan. Dalam rezim permintaan elastis, penurunan biaya ini memberi insentif kepada pengguna tambahan untuk memanfaatkannya jaringan, terus melanggengkan adopsi dalam siklus kebajikan yang berkelanjutan. Catatan: Meskipun whitepaper ini menguraikan elemen-elemen penting dari visi kami untuk evolusi Chainlink, whitepaper ini bersifat informal dan mencakup sedikit rincian teknis yang rinci. Kami berencana untuk melakukannya merilis makalah teknis yang berfokus pada fitur dan pendekatan tambahan seiring dengan perkembangannya. Lebih lanjut, penting untuk ditekankan bahwa banyak elemen dari visi yang disampaikan di sini (peningkatan skala, teknologi kerahasiaan, FSS, dll.) dapat dan akan terjadi diterapkan dalam bentuk awal bahkan sebelum DON tingkat lanjut menjadi fitur dasar Chainlink. 1.3 Organisasi Makalah ini Kami menyajikan model dan notasi keamanan kami di Bagian 2 dan menguraikan Desentralisasi Oracle Network API di Bagian 3. Di Bagian 4, kami menyajikan sejumlah contoh aplikasi yang DONs menyediakan platform penerapan yang menarik. Pembaca bisa pelajari sebagian besar konsep utama makalah ini dengan membaca hingga titik ini. Sisa makalah ini berisi rincian lebih lanjut. Kami menjelaskan Urutan yang Adil Layanan (FSS) di Bagian 5 dan Kerangka Eksekusi Transaksi (TEF) di Bagian 6. Kami menjelaskan pendekatan kami terhadap minimalisasi kepercayaan di Bagian 7. Kami mempertimbangkan beberapa persyaratan penerapan DON yang penting, yaitu peluncuran fitur secara bertahap, keanggotaan buku besar dinamis, dan akuntabilitas di Bagian 8. Terakhir, di Bagian 9, kami memberikan gambaran umum tentang pendekatan kami yang berkembang terhadap desain insentif. Kami menyimpulkan di Bagian 10. Untuk membantu pembaca yang memiliki pemahaman terbatas terhadap konsep-konsep dalam makalah ini, kami berikan glosarium di Lampiran A. Kami menyajikan detail lebih lanjut pada antarmuka DON dan fungsionalitas di Lampiran B dan sajikan beberapa contoh adaptor di Lampiran C. Dalam Lampiran D, kami menjelaskan primitif kriptografi untuk sumber data yang diminimalkan kepercayaan otentikasi disebut tanda tangan fungsional dan memperkenalkan varian baru yang disebut tanda tangan fungsional terdiskritisasi. Kami membahas beberapa pertimbangan yang ada di komite seleksi untuk DONs di Lampiran F.
Security Model and Goals
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 differ in terms of the types of services they provide, which can include, e.g., data feeds, Proof of Reserves, verifiable randomness, and so forth. Other differences 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 modified.
• 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 defined above. Similarly, ledger rules might permit modification 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., Hotstuff[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 finality realizes a ledger, inconsistency is typically abstracted away by disregarding insufficiently deep blocks or “pruning” [115]. 5In practice, some code bases, e.g., LibraBFT [205], a variant of Hotstuff, have currently adopted multi-signatures, rather than threshold signatures, trading offreduced 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 specified. 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 verification 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.
Model dan Sasaran Keamanan
Jaringan Oracle Terdesentralisasi adalah sistem terdistribusi berbeda yang kami harapkan akan demikian pada awalnya biasanya dilaksanakan—walaupun belum tentu—oleh sebuah komite yang berbasis protokol konsensus dan dijalankan oleh sekumpulan oracle node. DON dirancang terutama untuk menambah kemampuan smart contract pada rantai utama dengan oracle laporan dan layanan lainnya, namun dapat menyediakan layanan pendukung yang sama ke sistem nonblockchain lainnya, sehingga tidak perlu diasosiasikan dengan rantai utama tertentu.
Oleh karena itu, model dan properti yang kami pertimbangkan sebagian besar tidak bergantung pada penggunaannya aplikasi khusus dari DON. 2.1 Model Arsitektur Saat Ini Penting untuk ditekankan bahwa Chainlink saat ini bukanlah layanan monolitik, melainkan kerangka kerja tanpa izin yang memungkinkan peluncuran yang berbeda dan independen jaringan oracle node [77]. Jaringan memiliki kumpulan operator node yang heterogen dan desain. Mereka juga mungkin berbeda dalam hal jenis layanan yang mereka berikan, yang mungkin saja berbeda mencakup, misalnya, umpan data, Bukti Cadangan, keacakan yang dapat diverifikasi, dan sebagainya. Lainnya Perbedaannya dapat mencakup tingkat desentralisasi, ukuran jaringan, dan sebagainya nilai terkunci yang didukungnya, dan berbagai parameter tingkat layanan, seperti frekuensi data dan akurasi. Model tanpa izin Chainlink mendorong pertumbuhan ekosistem di mana penyedia layanan mengkhususkan diri pada layanan yang paling mampu mereka berikan kepada masyarakat. Ini Model ini kemungkinan besar akan menghasilkan biaya yang lebih rendah bagi pengguna dan kualitas layanan yang lebih tinggi dibandingkan model yang mengharuskan semua node dan jaringan untuk menyediakan berbagai layanan, sebuah pendekatan yang dapat dengan mudah beralih ke adopsi layanan yang paling sedikit mewakili seluruh sistem penyebut umum sumber daya yang tersedia untuk node. Seiring berkembangnya Chainlink menuju desain berbasis DON di Chainlink 2.0, kami terus melanjutkan mendukung model kerangka kerja terbuka dan tanpa izin, dengan tetap memperhatikan tujuan memberi pengguna berbagai pilihan layanan yang secara global menghasilkan kecocokan terbaik dengan persyaratan aplikasi tertentu. 2.2 Asumsi Konsensus Kami menggunakan istilah Jaringan Oracle Terdesentralisasi untuk mencakup fungsionalitas penuh sistem oracle yang kami jelaskan: baik struktur data yang dipelihara oleh oracle node maupun API inti berlapis di atasnya. Kami menggunakan istilah buku besar (huruf kecil), dilambangkan dengan L, yang berarti data yang mendasarinya struktur yang dikelola oleh DON dan digunakan untuk mendukung layanan tertentu yang disediakannya. Kami menekankan bahwa kerangka DON kami tidak memperlakukan L sebagai sistem yang berdiri sendiri a blockchain: Tujuannya adalah untuk mendukung blockchains dan sistem lainnya. Blockchain adalah, tentu saja, ada satu cara untuk mewujudkan buku besar yang dapat dipercaya, namun ada cara lain. Kami berharap DONs dalam banyak kasus untuk merealisasikan buku besar yang mendasarinya menggunakan Byzantine Fault Tolerant (BFT) sistem, yang jauh lebih tua dari blockchain seperti Bitcoin [174]. Kami menggunakan BFT-jenis notasi dan properti di seluruh makalah untuk kenyamanan, meskipun kami tekankan bahwa DONs dapat direalisasikan menggunakan protokol konsensus tanpa izin. Secara konseptual, buku besar L adalah papan buletin tempat data diurutkan secara linier. Kami memandang buku besar secara umum memiliki beberapa properti utama yang umumnya dianggap berasal darinya blockchains [115]. Buku besar adalah: • Hanya tambahan: Data, setelah ditambahkan, tidak dapat dihapus atau diubah.• Publik: Siapapun dapat membaca isinya, yang konsisten sepanjang waktu di dalamnya pandangan semua pengguna.4 • Tersedia: Buku besar selalu dapat ditulis dan dibaca oleh penulis yang berwenang oleh siapa pun pada waktu yang tepat. Properti alternatif dimungkinkan dalam buku besar untuk DON bila direalisasikan oleh a panitia. Misalnya, akses menulis buku besar mungkin dibatasi untuk pengguna tertentu, seperti mungkin akses baca untuk beberapa aplikasi, yaitu, buku besar tidak perlu bersifat publik seperti yang ditentukan di atas. Demikian pula, aturan buku besar mungkin mengizinkan modifikasi atau redaksi data. Kami tidak melakukannya namun secara eksplisit mempertimbangkan varian tersebut dalam makalah ini. Desain modular DONs dapat mendukung berbagai macam BFT modern protokol, misalnya, Hotstuff[231]. Pilihan yang tepat akan bergantung pada asumsi kepercayaan dan karakteristik jaringan di antara oracle node. DON pada prinsipnya bisa sebagai alternatif gunakan blockchain tanpa izin yang berkinerja tinggi untuk buku besarnya dalam perannya mendukung sistem lapisan-2 atau blockchain yang sama-sama dapat diskalakan. Demikian pula, hibridisasi juga dimungkinkan: DON pada prinsipnya dapat terdiri dari node yang validators dalam sistem yang sudah ada blockchain, misalnya, dalam sistem Proof-of-Stake di mana komite dipilih untuk melaksanakan transaksi, misalnya, [8, 81, 120, 146, 204]. Mode operasi khusus ini memerlukan hal itu node beroperasi dengan cara penggunaan ganda, yaitu beroperasi sebagai blockchain node dan DON node. (Lihat Bagian 8.2 untuk pembahasan mengenai teknik-teknik untuk menjamin kesinambungan perubahan komite dan Lampiran F untuk beberapa peringatan mengenai pemilihan komite acak.) Dalam praktiknya, dalam algoritme BFT modern, node menandatangani pesan secara digital di buku besar. Kami berasumsi untuk kemudahan bahwa L memiliki kunci publik terkait pkL dan isinya ditandatangani oleh kunci pribadi yang sesuai. Notasi umum ini berlaku bahkan ketika data di L ditandatangani menggunakan tanda tangan ambang batas.5 Tanda tangan ambang batas mudah digunakan, karena mereka mengaktifkan identitas tetap untuk DON bahkan dengan perubahan keanggotaan node yang menjalankannya. (Lihat Lampiran B.1.3.) Dengan demikian kita berasumsi bahwa skL dibagikan secara rahasia dengan cara (k, n)-ambang batas untuk beberapa parameter keamanan k, misalnya k = 2f + 1 dan n = 3f + 1, dimana f adalah jumlah node yang berpotensi rusak. (Dengan memilih k dalam hal ini dengan cara ini, kami memastikan bahwa node yang salah tidak dapat mempelajari skL atau melakukan penolakan layanan serangan mencegah penggunaannya.) Pesan pada L berbentuk M = (m, z), dimana m adalah string dan z unik nomor indeks berurutan. Jika memungkinkan, kami menulis pesan dalam bentuk m = ⟨Jenis Pesan : muatan⟩. Jenis pesan MessageType adalah gula sintaksis yang menunjukkan fungsi pesan tertentu. 4Dalam kasus di mana blockchain tanpa finalitas merealisasikan buku besar, inkonsistensi biasanya diabstraksikan pergi dengan mengabaikan blok yang tidak cukup dalam atau “pemangkasan” [115]. 5Dalam praktiknya, beberapa basis kode, misalnya LibraBFT [205], varian dari Hotstuff, saat ini telah mengadopsi tanda tangan multi-tanda tangan, bukan tanda tangan ambang batas, sehingga mengurangi kompleksitas komunikasi rekayasa yang lebih sederhana. Dengan sejumlah biaya tambahan, node oracle dapat menambahkan tanda tangan ambang batas ke pesan ditulis ke L meskipun protokol konsensus yang digunakan untuk L tidak menerapkannya.2.3 Notasi Kami menyatakan himpunan n oracle node yang menjalankan buku besar dengan O = {Oi}n saya=1. Seperti itu kumpulan node sering disebut komite. Untuk mempermudah, kita asumsikan bahwa himpunan oracles mengimplementasikan fungsionalitas DON, yaitu layanan di atas L, identik dengan yang mempertahankan L, tetapi keduanya bisa berbeda. Kita biarkan pki menunjukkan kunci publik dari pemain Oi, dan mainkan kunci pribadi yang sesuai. Kebanyakan algoritma BFT memerlukan setidaknya n = 3f + 1 node, dimana f adalah jumlah node yang berpotensi rusak; node yang tersisa jujur, dalam arti mengikuti protokol persis seperti yang ditentukan. Kami menyebut panitia O jujur jika memenuhi hal tersebut persyaratan, yaitu, memiliki lebih dari 2/3 fraksi node jujur. Kecuali sebaliknya dinyatakan, kami berasumsi bahwa O jujur (dan model korupsi yang statis). Kami menggunakan pkO / skO dapat dipertukarkan dengan pkL/skL, tergantung konteksnya. Kita misalkan σ = Sigpk[m] menunjukkan tanda tangan pada pesan m sehubungan dengan pk, yaitu menggunakan sk kunci pribadi yang sesuai. Misalkan verifikasi(pk, σ, m) →{salah, benar} menunjukkan algoritma verifikasi tanda tangan yang sesuai. (Kami membiarkan pembuatan kunci tersirat di seluruh makalah ini.) Kami menggunakan notasi S untuk menunjukkan sumber data dan S untuk menunjukkan himpunan lengkap sumber nS dalam konteks tertentu. Kami menunjukkan dengan MAINCHAIN kontrak pintar yang diaktifkan blockchain didukung oleh DON. Kami menggunakan istilah kontrak mengandalkan untuk menunjukkan kecerdasan apa pun kontrak di MAINCHAIN yang berkomunikasi dengan DON, dan menggunakan notasi SC untuk menunjukkan kontrak seperti itu. Secara umum kita berasumsi bahwa DON mendukung satu rantai utama MAINCHAIN, meskipun dapat mendukung beberapa rantai seperti itu, seperti yang kami tunjukkan pada contoh di Bagian 4. A DON dapat dan biasanya akan mendukung beberapa kontrak yang mengandalkan MAINCHAIN. (Sebagai disebutkan di atas, DON dapat mendukung layanan non-blockchain.) 2.4 Catatan tentang Model Kepercayaan Seperti disebutkan di atas, DONs dapat dibangun berdasarkan protokol konsensus berbasis komite, dan kami berharap mereka biasanya akan menggunakan protokol seperti itu. Ada banyak argumentasi kuat yang menyatakan hal tersebut salah satu dari dua alternatif, blockchains berbasis komite atau tanpa izin, menyediakan keamanan yang lebih kuat dari yang lain. Penting untuk menyadari bahwa keamanan berbasis komite vs. tanpa izin sistem desentralisasi tidak dapat dibandingkan. Mengompromikan PoW atau PoS blockchain melalui serangan 51% mengharuskan musuh memperoleh sumber daya mayoritas secara sementara dan berpotensi secara anonim, misalnya dengan menyewa hash listrik dalam sistem PoW. Seperti itu serangan dalam praktiknya telah berdampak pada beberapa blockchain [200, 34]. Sebaliknya, mengkompromikan sistem berbasis komite berarti merusak jumlah ambang batas (biasanya sepertiga) dari node-nodenya, dimana node-node tersebut mungkin diketahui publik, mempunyai sumber daya yang baik, dan entitas yang dapat dipercaya. Di sisi lain, sistem berbasis komite (serta “hibrida” tidak memiliki izin sistem yang mendukung komite) dapat mendukung lebih banyak fungsi daripada yang hanya dilakukan secara ketat.sistem tanpa misi. Ini termasuk kemampuan untuk menjaga rahasia yang terus-menerus, seperti penandatanganan dan/atau kunci enkripsi—salah satu kemungkinan dalam desain kami. Kami menekankan bahwa DON pada prinsipnya dapat dibangun berdasarkan komite atau protokol konsensus tanpa izin dan DON yang menerapkan pada akhirnya dapat memilih untuk mengadopsinya pendekatan mana pun. Memperkuat model kepercayaan: Fitur utama Chainlink saat ini adalah kemampuan pengguna untuk melakukannya pilih node berdasarkan catatan desentralisasi dari riwayat kinerjanya, seperti yang telah dibahas di Bagian 3.6.4. Mekanisme staking dan Kerangka Insentif Implisit yang kami perkenalkan di Bagian 9 bersama-sama merupakan rancangan mekanisme yang memiliki cakupan luas dan ketat kerangka kerja yang akan memberdayakan pengguna dengan kemampuan yang jauh lebih luas untuk mengukur keamanan DONs. Kerangka kerja yang sama ini juga akan memungkinkan DONs itu sendiri untuk menegakkan berbagai persyaratan keamanan pada node yang berpartisipasi dan memastikan operasi dalam model kepercayaan yang kuat. Dimungkinkan juga untuk menggunakan alat yang dijelaskan dalam makalah ini untuk DONs guna menerapkan persyaratan model kepercayaan khusus, seperti kepatuhan terhadap persyaratan peraturan. Untuk Misalnya, dengan menggunakan teknik yang dibahas di Bagian 4.3, node dapat menyajikan bukti karakteristik node-operator, misalnya wilayah operasi, yang dapat digunakan untuk membantu menegakkan kepatuhan terhadap, misalnya, Peraturan Perlindungan Data Umum (GDPR) Pasal 3 (“Cakupan Teritorial”) [105]. Kepatuhan seperti itu bisa jadi sulit untuk dilakukan bertemu dalam sistem desentralisasi [45]. Selain itu, di Bagian 7 kami membahas rencana untuk memperkuat ketahanan DONs melalui mekanisme minimalisasi kepercayaan pada rantai utama yang mereka dukung.
Decentralized Oracle Network Interface and Ca-
Decentralized Oracle Network Interface and Ca-
pabilities Here we briefly 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 off-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.
3.1 Networking Adapters are interfaces through which executables running on a DON can send and receive data from off-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 different 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 define how to send transactions to a blockchain and how to read blocks, individual transactions, or other state from it. An adapter can also be defined for a blockchain’s mempool. (See Section 3.5.) • Web servers: Adapters can define 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 define methods to read and write to storage services outside the DON, such as a decentralized file 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-specific 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 first 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 specifically 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 effectively 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 define 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 fires 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 first \(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 differs from a typical main chain contract in two essential ways: 1. Confidentiality: An executable can perform confidential 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 defined 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 defined 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 specifically supported services. A DON can additionally make use of such data in a confidential 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 efficient 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). Briefly, 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, confidential 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 efficiently. 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 first-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-configured 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 Off-Chain Reporting (OCR) Off-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 first 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 influence 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 different 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 off-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-defined interval of time. This is a liveness property. 3. Contract-based trust minimization: SC filters out potentially erroneous OCRgenerated reports, e.g., if their reported values deviate significantly 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 offchain (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 refinement 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 prefixed 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 Verifier, 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 confidentiality. A Prover may wish to redact or modify sensitive data before presenting it to a Verifier. Digital signatures are designed specifically to invalidate modified data, however. They thus prevent a Prover from making confidentiality-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 Verifier in a way that ensures integrity and confidentiality. The two systems preserve integrity in the sense that they ensure that data presented by the Prover to the Verifier originates authentically from the target server. They support confidentiality 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 modifications 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 differ in their trust models and implementations as we now briefly explain. DECO makes fundamental use of cryptographic protocols to achieve its integrity and confidentiality properties. While establishing a session with a target server using DECO, the Prover engages at the same time in an interactive protocol with the Verifier. This protocol enables the Prover to prove to the Verifier that it has received a given piece of data D from the server during its current session. The Prover can alternatively present the Verifier 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. Briefly, a TEE functions as a kind of black box that executes applications in a tamperproof and confidential 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 Verifier. In contrast, Town Crier enables a Prover to generate a publicly verifiable 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 off-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-fidelity 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 flexible 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 different 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. • Confidentiality: The ability to perform generalized computation in a DON enables computations on sensitive data to take place offchain, avoiding on-chain exposure. Additionally, using DECO or Town Crier, it is possible to achieve even stronger confidentiality, allowing report generation based on data that isn’t exposed even to DON nodes. See Section 4.3 and Section 4.5 for examples. Verifiable Random Functions (VRFs): Several types of DApps require a verifiably correct source of randomness to enable verification of their own fair operation. Non-Fungible Tokens (NFTs) are an example. The rarity of NFT features in Aavegotchi [23] and Axie Infinity [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 financial 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] offers a considerably more secure alternative. An oracle has an associated private / public key pair (sk, pk) whose private key is maintained offchain 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-specific 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 verifiable 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 offchain. More generally, DONs can offer 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 off-chain jobs, generally to trigger execution of relying smart contracts. Before the advent of Keepers, it was common for developers to operate such off-chain logic themselves, creating centralized points of failure (as well as considerable duplicated development effort). 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 financial 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 off-chain systems, permitting rapid development of secure, sophisticated functionality. Initiators initiate computation in executables, which themselves offer the full versatility of DONs, permitting the wide range of decentralized services we present in this paper for on-chain and off-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, filter, 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 off-chain identities through services such as Keybase [4], which bind the profile 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 fulfilled, 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 flat “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 offchain. 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 fine-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.
Antarmuka Jaringan Oracle Terdesentralisasi dan Ca-
kemampuan Di sini kami menguraikan secara singkat kemampuan DONs dalam hal sederhana namun kuat antarmuka yang dirancang untuk mereka wujudkan. Aplikasi pada DON terdiri dari executable dan adaptor. Yang dapat dieksekusi adalah sebuah program yang logika intinya adalah program deterministik, analog dengan smart contract. Sebuah executable juga memiliki sejumlah inisiator yang menyertainya, program yang memanggil entri poin dalam logika eksekusi ketika peristiwa yang telah ditentukan terjadi—misalnya, pada waktu tertentu (seperti tugas cron), ketika harga melewati ambang batas, dll.—seperti Keeper (lihat Bagian 3.6.3). Adaptor menyediakan antarmuka ke sumber daya off-chain dan dapat dipanggil oleh baik inisiator atau logika inti dalam executable. Karena perilaku mereka mungkin bergantung pada hal itu sumber daya eksternal, pemrakarsa dan adaptor mungkin berperilaku non-deterministik. Kami menjelaskan antarmuka pengembang DON dan fungsi executable dan adaptor dalam kaitannya dengan tiga sumber daya yang biasanya digunakan untuk mengkarakterisasi sistem komputasi: jaringan, komputasi, dan penyimpanan. Kami memberikan gambaran singkat tentang masing-masing hal ini sumber daya di bawah ini dan berikan rincian lebih lanjut di Lampiran B.
3.1 Jaringan Adaptor adalah antarmuka yang dapat digunakan oleh executable yang berjalan pada DON untuk mengirim dan menerima data dari sistem off-DON. Adaptor dapat dipandang sebagai generalisasi dari adaptor yang digunakan di Chainlink hari ini [20]. Adaptor mungkin bersifat dua arah—yaitu tidak bisa hanya menarik, tetapi mendorong data dari DON ke server web. Mereka mungkin juga memanfaatkan protokol terdistribusi serta fungsi kriptografi seperti multi-pihak yang aman komputasi. Gambar 9: Adaptor yang menghubungkan DON, dilambangkan DON1, dengan serangkaian sumber daya berbeda, termasuk DON lainnya, dilambangkan DON2, blockchain (rantai utama) dan rangkaiannya mempool, penyimpanan eksternal, server web, dan perangkat IoT (melalui server web). Contoh sumber daya eksternal yang dapat digunakan untuk membuat adaptor ditampilkan pada Gambar 9. Ini termasuk: • Blockchain: Adaptor dapat menentukan cara mengirim transaksi ke blockchain dan cara membaca blok, transaksi individu, atau keadaan lain darinya. Sebuah adaptor juga dapat didefinisikan untuk mempool blockchain. (Lihat Bagian 3.5.) • Server web: Adaptor dapat menentukan API yang dapat digunakan untuk mengambil data dari server web, termasuk sistem lama yang tidak diadaptasi secara khusus berinteraksi dengan DONs. Adaptor tersebut juga dapat menyertakan API untuk mengirim data server seperti itu. Server web yang terhubung dengan DON dapat berfungsi sebagai gerbang ke sumber daya tambahan, seperti perangkat Internet-of-Things (IoT).• Penyimpanan eksternal: Adaptor dapat menentukan metode untuk membaca dan menulis ke penyimpanan layanan di luar DON, seperti sistem file terdesentralisasi [40, 188] atau cloud penyimpanan. • DONs lainnya: Adaptor dapat mengambil dan mengirimkan data antara DONs. Kami berharap penerapan awal DONs akan mencakup serangkaian elemen penyusun adaptor untuk sumber daya eksternal yang umum digunakan dan selanjutnya akan memungkinkan DON-spesifik adaptor yang akan dipublikasikan oleh DON node. Saat smart contract pengembang menulis adaptor saat ini, kami berharap mereka akan membuat adaptor yang lebih kuat lagi dengan menggunakan teknologi canggih ini fungsionalitas. Kami berharap pada akhirnya pengguna dapat membuat adaptor baru di a cara tanpa izin. Beberapa adaptor harus dibangun sedemikian rupa sehingga menjamin persistensi dan ketersediaan sumber daya eksternal yang dikendalikan oleh DON. Misalnya, penyimpanan cloud mungkin memerlukan pemeliharaan akun layanan cloud. Selain itu, DON dapat berfungsi pengelolaan kunci privat yang terdesentralisasi atas nama pengguna (misalnya, [160]) dan/atau executable. Akibatnya, DON mampu mengendalikan sumber daya, seperti mata uang kripto, yang dapat digunakan, misalnya, untuk mengirim transaksi pada target blockchain. Lihat Lampiran B.1 untuk rincian lebih lanjut tentang adaptor DON, seperti Lampiran C untuk beberapa contoh adaptor. 3.2 Perhitungan Eksekusi adalah unit kode dasar pada DON. Yang dapat dieksekusi adalah pasangan exec = (logika, init). Di sini, logika adalah program deterministik dengan sejumlah entri yang ditentukan poin (logic1, logic2, . . . , logicℓ) dan init adalah sekumpulan inisiator yang sesuai (init1, init2, . . . , init). Untuk memastikan kemampuan audit penuh dari DON, logika yang dapat dieksekusi menggunakan buku besar yang mendasari L untuk semua input dan output. Jadi, misalnya, adaptor apa pun data yang berfungsi sebagai input ke executable harus disimpan terlebih dahulu di L. Pemrakarsa: Inisiator di Chainlink hari ini menyebabkan eksekusi pekerjaan yang bergantung pada peristiwa Chainlink simpul [21]. Inisiator di DONs berfungsi dengan cara yang hampir sama. Namun, inisiator DON secara khusus dikaitkan dengan executable. Seorang inisiator mungkin bergantung pada peristiwa atau keadaan eksternal, pada waktu saat ini, atau pada predikat pada keadaan DON. Dengan ketergantungan mereka pada peristiwa, tentu saja inisiator dapat berperilaku non-deterministik (seperti tentu saja adaptor). Inisiator dapat mengeksekusi dalam DON node individual sehingga tidak perlu bergantung pada adaptor. (Lihat Contoh 1 di bawah.) Inisiator adalah fitur penting yang membedakan executable dari smart contracts. Karena executable dapat dijalankan sebagai respons terhadap inisiator, maka executable dapat beroperasi secara efektif secara mandiri, tentu saja dengan perluasan kontrak hibrida yang menggabungkan kontrak yang dapat dieksekusi. Salah satu bentuk inisiator saat ini adalah Chainlink Keeper yang menyediakan transaksilayanan otomatisasi, memicu eksekusi smart contract—seperti likuidasi pinjaman tanpa jaminan dan eksekusi perdagangan limit-order—berdasarkan laporan oracle. Mudahnya, inisiator di DONs juga dapat dilihat sebagai cara untuk menentukan perjanjian layanan yang berlaku untuk executable, karena perjanjian tersebut mendefinisikan keadaan di bawah yang mana DON harus menyebutnya. Contoh berikut mengilustrasikan cara kerja inisiator dalam executable: Contoh 1 (Umpan harga yang dipicu oleh deviasi). smart contract SC mungkin memerlukan yang baru data harga pakan (lihat Bagian 3.6.3) setiap kali ada perubahan besar, misalnya 1%, pada nilai tukar antara sepasang aset, misalnya ETH-USD. Harga sensitif terhadap volatilitas feed didukung di Chainlink saat ini, namun ada baiknya kita melihat bagaimana feed tersebut dapat didukung direalisasikan pada DON melalui execfeed yang dapat dieksekusi. Execfeed yang dapat dieksekusi mempertahankan harga ETH-USD terbaru di L, di bentuk rangkaian ⟨HargaBaru : j, r⟩entri, dengan j adalah indeks yang ditambah dengan setiap pembaruan harga. Inisiator init1 menyebabkan setiap node Oi memantau harga ETH-USD saat ini penyimpangan minimal 1% dari harga yang disimpan terakhir r dengan indeks j. Setelah mendeteksi penyimpangan tersebut, Oi menulis pandangan terkininya tentang harga baru ke L menggunakan entri formulir ⟨PriceView : i, j + 1, ri⟩. Inisiator kedua dimulai ketika setidaknya ada k entri PriceView dengan harga baru nilai untuk indeks j + 1 yang dibuat oleh node berbeda telah terakumulasi di L. Kemudian, init2 memanggil logika titik masuk2 untuk menghitung median ρ dari k nilai tampilan harga baru yang valid dan menulis nilai baru ⟨NewPrice : j + 1, ρ⟩to L . (Secara operasional, node dapat bergiliran sebagai penulis yang ditunjuk.) Inisiator ketiga, init3, mengawasi entri NewPrice di L. Setiap kali ada laporan baru ⟨Harga Baru : j, r⟩muncul di sana, memanggil logika titik masuk3 yang mendorong (j, r) ke SC menggunakan adaptor. Seperti yang telah kami catat, executable memiliki kemampuan yang serupa dengan smart contract. Namun, selain kinerjanya yang lebih tinggi, kontrak ini berbeda dari kontrak rantai utama pada umumnya dalam dua cara penting: 1. Kerahasiaan: Sebuah executable dapat melakukan komputasi rahasia, yaitu, program rahasia dapat memproses masukan teks yang jelas, atau program yang diterbitkan dapat memproses data masukan rahasia, atau kombinasi keduanya. Dalam model sederhana, data rahasia bisa diakses oleh DON node, yang menyembunyikan hasil antara dan hanya mengungkapkan nilai yang diproses dan dibersihkan ke MAINCHAIN. Data sensitif juga dapat disembunyikan dari DONs itu sendiri: DONs dimaksudkan untuk mendukung pendekatan seperti itu sebagai komputasi multi-pihak, misalnya, [42, 157], dan lingkungan eksekusi tepercaya (TEEs) [84, 133, 152, 229] untuk tujuan ini.6 6Selain itu, menjaga kerahasiaan executable sehubungan dengan DON node juga dimungkinkan, meskipun hal ini hanya praktis saat ini untuk executable non-trivial yang menggunakan TEE.2. Peran pendukung: Sebuah executable dimaksudkan untuk mendukung smart contracts pada main rantai, daripada menggantinya. Sebuah executable memiliki beberapa keterbatasan yaitu a smart contract tidak: (a) Model kepercayaan: Sebuah executable beroperasi dalam model kepercayaan yang ditentukan oleh DON: Eksekusi yang benar bergantung pada perilaku jujur O. (A main namun, rantai dapat memberikan beberapa pagar pengaman terhadap DON penyimpangan, seperti dibahas di Bagian 7.3.) (b) Akses aset: DON dapat mengontrol akun di blockchain—dan dengan demikian mengontrol aset di dalamnya melalui adaptor. Tapi DON tidak bisa secara otoritatif mewakili aset yang dibuat pada rantai utama, misalnya Ether atau ERC20 tokens, karena rantai asal mereka menyimpan catatan resmi kepemilikan mereka. (c) Siklus Hidup: DON dapat dibuat dengan sengaja dengan masa hidup terbatas, seperti ditentukan oleh perjanjian tingkat layanan on-chain antara DONs dan pemilik mengandalkan kontrak. Sebaliknya, Blockchain dimaksudkan untuk berfungsi sebagai sistem arsip permanen. Lihat Lampiran B.2 untuk rincian lebih lanjut tentang perhitungan DON. 3.3 Penyimpanan Sebagai sistem berbasis komite, DON dapat menyimpan data dalam jumlah sedang secara terus-menerus di L dengan biaya yang jauh lebih rendah daripada blockchain tanpa izin. Selain itu, melalui adaptor, DONs dapat mereferensikan sistem desentralisasi eksternal untuk penyimpanan data, misalnya Filecoin [85], dan dengan demikian dapat menghubungkan sistem tersebut ke smart contracts. Opsi ini khususnya menarik untuk data massal sebagai cara untuk mengatasi masalah “penggembungan” yang meluas blockchain sistem. DONs dapat menyimpan data secara lokal atau eksternal untuk digunakan dalam layanan yang didukung secara khusus. DON juga dapat menggunakan data tersebut secara rahasia, komputasi pada data yang: (1) dibagikan secara rahasia di DON node atau dienkripsi di bawah kunci yang dikelola oleh DON node dengan cara yang sesuai untuk komputasi multi-pihak yang aman atau enkripsi sebagian atau seluruhnya homomorfik; atau (2) dilindungi menggunakan eksekusi tepercaya lingkungan. Kami berharap DONs akan mengadopsi model manajemen memori sederhana yang umum digunakan sistem kontrak pintar: Sebuah executable hanya dapat menulis ke memorinya sendiri. Dapat dieksekusi mungkin, bagaimanapun, membaca dari memori executable lainnya. Lihat Lampiran B.3 untuk rincian lebih lanjut tentang penyimpanan DON. 3.4 Kerangka Eksekusi Transaksi (TEF) DONs dimaksudkan untuk mendukung kontrak pada rantai utama MAINCHAIN (atau pada beberapa rantai utama). Kerangka Eksekusi Transaksi (TEF), dibahas secara rincidi Bagian 6, adalah pendekatan tujuan umum untuk pelaksanaan kontrak secara efisien SC melintasi MAINCHAIN dan DON. TEF dimaksudkan untuk mendukung FSS dan layer-2 teknologi—secara bersamaan, jika diinginkan. Memang kemungkinan besar akan berfungsi sebagai kendaraan utama untuk penggunaan FSS (dan oleh karena itu, kami tidak membahas FSS lebih lanjut di bagian ini). Singkatnya, di TEF kontrak target asli SC dirancang atau dikembangkan untuk MAINCHAIN difaktorkan ulang menjadi kontrak hibrid. Refactoring ini menghasilkan keduanya saling beroperasi bagian dari kontrak hybrid: kontrak MAINCHAIN SCa yang kami rujuk untuk kejelasan dalam konteks TEF sebagai kontrak jangkar dan eksekutif yang dapat dieksekusi pada DON. Itu kontrak SCa menjaga aset pengguna, melaksanakan transisi status otoritatif, dan juga menyediakan pagar pengaman (lihat Bagian 7.3) terhadap kegagalan di DON. Para eksekutif yang dapat dieksekusi mengurutkan transaksi dan menyediakan data oracle terkait untuk transaksi tersebut. Itu bisa dibundel transaksi untuk SCa dengan salah satu dari beberapa cara—misalnya, menggunakan berbasis validitas atau rollups yang optimis, eksekusi rahasia oleh DON, dll. Kami berharap dapat mengembangkan alat yang memudahkan pengembang untuk mempartisi kontrak SC ditulis dalam bahasa tingkat tinggi menjadi potongan-potongan logika MAINCHAIN dan DON, SCa dan masing-masing eksekutif, yang menulis dengan aman dan efisien. Menggunakan TEF untuk mengintegrasikan skema transaksi berkinerja tinggi dengan kinerja tinggi oracles merupakan bagian integral dari pendekatan penskalaan oracle kami. 3.5 Layanan Mempool Fitur lapisan aplikasi penting yang ingin kami terapkan pada DONs sebagai dukungan FSS dan TEF adalah Mempool Services (MS). MS dapat dipandang sebagai adaptor, tapi yang memiliki dukungan kelas satu. MS menyediakan dukungan untuk pemrosesan transaksi yang kompatibel dengan warisan. Dalam penggunaan ini, MS menyerap dari mempool rantai utama transaksi-transaksi yang dimaksudkan untuk kontrak target SC di RANTAI UTAMA. MS kemudian meneruskan transaksi ini ke executable di DON, di mana mereka diproses dengan cara yang diinginkan. Data MS dapat digunakan oleh DON untuk membuat transaksi yang kemudian dapat diteruskan langsung ke SC dari DON atau ke kontrak lain yang memanggil SC. Misalnya, DON dapat meneruskan transaksi dipanen melalui MS, atau dapat menggunakan data MS untuk menetapkan harga gas untuk transaksi yang dikirimkannya RANTAI UTAMA. Karena memonitor mempool, MS dapat memperoleh transaksi dari pengguna yang berinteraksi langsung dengan SC. Dengan demikian pengguna dapat terus melakukan transaksi menggunakan perangkat lunak lama, yaitu aplikasi yang tidak mengetahui keberadaan MS dan konfigurasi MS kontrak. (Dalam hal ini, SC harus diubah untuk mengabaikan transaksi asli dan hanya menerima yang diproses oleh MS, untuk menghindari pemrosesan ganda.) Untuk digunakan dengan kontrak target SC, MS dapat digunakan dengan FSS dan/atau TEF.3.6 Batu Loncatan: Kemampuan Chainlink yang Ada 3.6.1 Pelaporan Off-Chain (OCR) Pelaporan Off-Chain (OCR) [60] adalah mekanisme di Chainlink untuk oracle agregasi dan transmisi laporan ke SC kontrak yang mengandalkan. Baru-baru ini diterapkan dengan harga Chainlink jaringan umpan, ini mewakili langkah pertama menuju DONs penuh. Pada intinya, OCR adalah protokol BFT yang dirancang untuk beroperasi secara sinkron sebagian jaringan. Ini memastikan keaktifan dan kebenaran di hadapan f < n/3 secara sewenang-wenang node yang salah, menjamin properti siaran Bizantium yang andal, tetapi sebenarnya tidak protokol konsensus BFT yang lengkap. Node tidak menyimpan log pesan yang ada konsisten dalam arti mewakili buku besar yang identik dalam semua pandangannya, dan pemimpin protokol dapat mengelak tanpa melanggar keselamatan. OCR saat ini dirancang untuk jenis pesan tertentu: agregasi median (setidaknya 2f +1) nilai yang dilaporkan oleh node yang berpartisipasi. Ini memberikan jaminan penting laporan yang dihasilkannya untuk SC, disebut laporan yang dibuktikan: Nilai median dalam sebuah laporan yang dibuktikan laporan sama dengan atau terletak di antara nilai yang dilaporkan oleh dua node jujur. Properti ini adalah kondisi keamanan utama untuk OCR. Pemimpin mungkin mempunyai pengaruh terhadap median nilai dalam laporan yang dibuktikan, tetapi hanya tunduk pada kondisi kebenaran ini. OCR bisa diperluas ke jenis pesan yang mengumpulkan nilai dengan cara berbeda. Sementara tujuan keaktifan dan kebenaran jaringan Chainlink saat ini tidak memerlukannya OCR merupakan protokol konsensus yang lengkap, namun memerlukan OCR untuk menyediakan beberapa bentuk fungsi tambahan yang tidak ada dalam protokol BFT konvensional, terutama: 1. Laporan off-chain semua atau tidak sama sekali disiarkan: OCR memastikan bahwa laporan telah dibuktikan dibuat tersedia dengan cepat untuk semua node yang jujur atau tidak sama sekali. Ini adalah sebuah keadilan properti yang membantu memastikan bahwa node yang jujur memiliki peluang untuk berpartisipasi dalam transmisi laporan yang dibuktikan. 2. Transmisi yang andal: OCR memastikan, bahkan jika ada yang salah atau berbahaya node, bahwa semua laporan dan pesan OCR dikirimkan ke SC dalam jangka waktu tertentu, interval waktu yang telah ditentukan sebelumnya. Ini adalah properti keaktifan. 3. Minimalkan kepercayaan berbasis kontrak: SC memfilter laporan yang dihasilkan OCR yang berpotensi salah, misalnya, jika nilai yang dilaporkan menyimpang secara signifikan dari nilai lain. yang baru saja diterima. Hal ini merupakan bentuk penegakan kebenaran ekstra protokol. Ketiga properti ini akan memainkan peran alami dalam DONs. Siaran off-chain semua atau tidak sama sekali (DON) merupakan landasan penting untuk jaminan ekonomi kripto seputar transmisi yang andal, yang pada gilirannya merupakan properti adaptor yang penting. Percaya minimalisasi di SC adalah jenis pagar pembatas, seperti yang dibahas dalam Bagian 7.3. OCR juga memberikan dasar untuk penerapan operasional dan penyempurnaan protokol BFT di jaringan oracle Chainlink dan dengan demikian, seperti disebutkan di atas, merupakan jalan menuju fungsionalitas DONs.3.6.2 DECO dan Town Crier DECO [234] dan Town Crier [233] adalah sepasang teknologi terkait yang saat ini sedang dikembangkan dikembangkan di jaringan Chainlink. Sebagian besar server web saat ini memungkinkan pengguna untuk terhubung melalui saluran aman menggunakan protokol disebut Keamanan Lapisan Transportasi (TLS) [94]. (HTTPS menunjukkan varian HTTP itu diaktifkan dengan TLS, yaitu URL yang diawali dengan “https” menunjukkan penggunaan TLS untuk keamanan.) Namun, sebagian besar server yang mendukung TLS memiliki batasan penting: Server tidak menandatangani secara digital data. Akibatnya, pengguna atau Prover tidak dapat menampilkan data yang diterimanya dari server kepada pihak ketiga atau Pemverifikasi, seperti oracle atau smart contract, dengan cara yang menjamin keaslian datanya. Bahkan jika server menandatangani data secara digital, masih ada masalah kerahasiaan. Seorang Prover mungkin ingin menyunting atau mengubah data sensitif sebelum menyajikannya kepada a Pemverifikasi. Namun, tanda tangan digital dirancang khusus untuk membatalkan validitas data yang dimodifikasi. Dengan demikian, hal-hal tersebut mencegah Prover melakukan perubahan demi menjaga kerahasiaan ke data. (Lihat Bagian 7.1 untuk diskusi lebih lanjut.) DECO dan Town Crier dirancang untuk memungkinkan Prover memperoleh data dari web server dan menyajikannya kepada Verifikasi dengan cara yang menjamin integritas dan kerahasiaan. Kedua sistem menjaga integritas dalam arti memastikan bahwa data disajikan oleh Prover ke Verifier berasal secara asli dari server target. Mereka mendukung kerahasiaan dalam arti mengizinkan Prover untuk menyunting atau mengubah data (sambil tetap menjaga integritas). Fitur utama dari kedua sistem ini adalah bahwa keduanya tidak memerlukan modifikasi apa pun pada a server web sasaran. Mereka dapat beroperasi dengan server apa pun yang mendukung TLS. Faktanya, mereka transparan ke server: Dari sudut pandang server, Provernya transparan membangun koneksi biasa. Kedua sistem tersebut memiliki tujuan yang serupa, namun berbeda dalam model kepercayaan dan implementasinya seperti yang akan kami jelaskan secara singkat. DECO memanfaatkan protokol kriptografi secara mendasar untuk mencapai integritasnya dan sifat kerahasiaan. Saat membuat sesi dengan server target menggunakan DECO, Prover terlibat pada saat yang sama dalam protokol interaktif dengan Pemverifikasi. Protokol ini memungkinkan Pemeriksa membuktikan kepada Pemverifikasi bahwa ia telah menerimanya sepotong data D tertentu dari server selama sesi saat ini. Pepatah bisa sebagai alternatif, berikan kepada Pemverifikasi bukti tanpa pengetahuan tentang beberapa properti D dan dengan demikian tidak mengungkapkan D secara langsung. Dalam penggunaan DECO pada umumnya, pengguna atau satu node dapat mengekspor data D dari data pribadi sesi dengan server web ke semua node di DON. Alhasil, DON penuh bisa membuktikan keaslian D (atau fakta yang diturunkan dari D melalui bukti tanpa pengetahuan). Selain contoh aplikasi yang diberikan nanti di makalah ini, kemampuan ini juga bisa digunakan untuk memperkuat akses integritas tinggi ke sumber data dengan DON. Meski hanya satu simpul memiliki akses langsung ke sumber data—misalnya karena perjanjian eksklusif dengan penyedia data—masih mungkin bagi seluruh DON untuk membuktikan kebenarannyalaporan yang dikeluarkan oleh node itu. Town Crier mengandalkan penggunaan lingkungan eksekusi tepercaya (TEE) seperti Intel SGX. Singkatnya, TEE berfungsi sebagai semacam kotak hitam yang mengeksekusi aplikasi dalam a cara tamperproof dan rahasia. Pada prinsipnya, bahkan pemilik host yang mana TEE yang sedang berjalan tidak dapat (tanpa terdeteksi) mengubah aplikasi yang dilindungi TEE juga melihat status aplikasi, yang mungkin berisi data rahasia. Town Crier dapat mencapai semua fungsi DECO dan banyak lagi. DECO membatasi Prover untuk berinteraksi dengan satu Verifier. Sebaliknya, Town Crier mengaktifkan sebuah Prover untuk menghasilkan bukti yang dapat diverifikasi secara publik pada data D yang diambil dari server target, yaitu, bukti bahwa siapa pun, bahkan smart contract, dapat memverifikasi secara langsung. Town Crier bisa juga menyerap dan memanfaatkan rahasia dengan aman (misalnya, kredensial pengguna). Keterbatasan utama Town Crier adalah ketergantungannya pada TEEs. TEE produksi punya baru-baru ini terbukti memiliki sejumlah kerentanan serius, meskipun teknologi ini masih dalam tahap awal dan pasti akan matang. Lihat Lampiran B.2.1 dan B.2.2 untuk diskusi lebih lanjut tentang TEE. Untuk beberapa contoh penerapan DECO dan Town Crier, lihat Bagian 4.3, 4.5 dan 9.4.3 dan Lampiran C.1. 3.6.3 Layanan Chainlink On-Chain yang Ada Chainlink oracle jaringan menyediakan sejumlah layanan utama di berbagai blockchains dan sistem desentralisasi lainnya saat ini. Evolusi lebih lanjut seperti yang dijelaskan dalam whitepaper ini akan memberikan layanan-layanan yang ada dengan kemampuan tambahan dan mencapai. Tiga contohnya adalah: Umpan data: Saat ini, mayoritas Chainlink pengguna mengandalkan smart contracts penggunaan data feed. Ini adalah laporan tentang nilai terkini dari data penting menurut ke sumber off-chain yang otoritatif. Misalnya, feed harga adalah feed yang melaporkan harga aset—mata uang kripto, komoditas, valas, indeks, ekuitas, dll.—menurut pertukaran atau layanan agregasi data. Umpan-umpan seperti itu saat ini sudah membantu mengamankan miliaran dolar dolar dalam nilai on-chain melalui penggunaannya dalam sistem DeFi seperti Aave [147] dan Sintetis [208]. Contoh lain dari data feed Chainlink mencakup data cuaca asuransi tanaman parametrik [75] dan data pemilu [93], dan masih banyak lagi. Penerapan DONs dan teknologi lain yang dijelaskan dalam makalah ini akan meningkatkan penyediaan data feed di jaringan Chainlink dalam banyak hal, termasuk: • Penskalaan: OCR dan selanjutnya DON bertujuan untuk memungkinkan Chainlink layanan ditingkatkan secara dramatis di banyak blockchain yang mereka dukung. Misalnya saja yang kita harapkan bahwa DONs akan membantu meningkatkan jumlah data feed yang disediakan oleh node yang menggunakan Chainlink dari 100 hingga 1000 dan seterusnya. Penskalaan seperti itu akan membantu Chainlink ekosistem mencapai tujuannya untuk menyediakan data yang relevan dengan smart contract secara komprehensif dan memenuhi serta mengantisipasi kebutuhan saat ini dan masa depan.• Peningkatan keamanan: Dengan menyimpan laporan perantara, DONs akan menyimpan catatan perilaku node untuk pemantauan dan pengukuran kinerja dan akurasi dengan ketelitian tinggi, memungkinkan landasan empiris yang kuat untuk sistem reputasi untuk Chainlink node. FSS dan TEF akan memungkinkan penggabungan feed harga dengan data transaksi dengan cara yang fleksibel yang mencegah serangan seperti front-running. (Eksplisit) staking akan meningkatkan perlindungan keamanan kriptoekonomi yang ada umpan data. • Kelincahan feed: Seperti sistem blockchain-agnostik (bahkan, lebih luas lagi, sistem agnostik konsumen), DONs dapat memfasilitasi penyediaan feed data dalam jumlah yang banyak dari sistem yang mengandalkan. Satu DON dapat mendorong umpan tertentu secara bersamaan ke satu set dari blockchain yang berbeda, menghilangkan kebutuhan akan jaringan oracle per rantai dan memungkinkan penerapan cepat feed yang ada pada blockchain baru dan tambahan feed di blockchain yang saat ini dilayani. • Kerahasiaan: Kemampuan untuk melakukan komputasi umum dalam DON memungkinkan komputasi pada data sensitif dilakukan secara off-chain, menghindari on-chain paparan. Selain itu, dengan menggunakan DECO atau Town Crier, hal ini dapat dicapai kerahasiaan yang lebih kuat, memungkinkan pembuatan laporan berdasarkan data yang bukan data terkena bahkan ke DON node. Lihat Bagian 4.3 dan Bagian 4.5 untuk contohnya. Fungsi Acak yang Dapat Diverifikasi (VRF): Beberapa jenis DApps memerlukan sumber keacakan yang dapat diverifikasi untuk memungkinkan verifikasi pengoperasian yang adil. Token Non-Fungible (NFTs) adalah contohnya. Kelangkaan fitur NFT di Aavegotchi [23] dan Axie Infinity [35] ditentukan oleh Chainlink VRF, begitu pula distribusinya dari NFTs melalui pengundian berbasis tiket di Kartu Ether [102]; berbagai macam DApps game yang hasilnya diacak; dan instrumen keuangan yang tidak konvensional, misalnya permainan tabungan tanpa rugi seperti PoolTogether [89], yang mengalokasikan dana ke pemenang acak. Aplikasi blockchain dan non-blockchain lainnya juga memerlukan keamanan sumber keacakan, termasuk pemilihan komite dengan sistem desentralisasi dan pelaksanaan lotere. Meskipun blok hashes dapat berfungsi sebagai sumber keacakan yang tidak dapat diprediksi, blok tersebut rentan terhadap manipulasi oleh penambang yang bermusuhan (dan sampai batas tertentu oleh pengguna yang mengirimkan transaksi). Chainlink VRF [78] menawarkan alternatif yang jauh lebih aman. Sebuah oracle memiliki pasangan kunci privat/publik terkait (sk, pk) yang kunci privatnya dipertahankan secara off-chain dan pk kunci publiknya dipublikasikan. Untuk menampilkan nilai acak, it menerapkan sk pada benih yang tidak dapat diprediksi x yang dilengkapi dengan kontrak yang dapat diandalkan (misalnya, blok hash dan parameter khusus DApp) menggunakan fungsi F, menghasilkan y = Fsk(x) bersama dengan a bukti kebenarannya. (Lihat [180] untuk VRF yang tersedia di Chainlink.) Apa yang membuat VRF yang dapat diverifikasi adalah fakta bahwa dengan pengetahuan tentang pk, dimungkinkan untuk memeriksa kebenaran pembuktian dan juga y. Oleh karena itu, nilai y tidak dapat diprediksi oleh an musuh yang tidak dapat memprediksi x atau mempelajari sk dan tidak layak untuk dimanipulasi oleh layanan.Chainlink VRF dapat dipandang hanya sebagai salah satu dari serangkaian aplikasi yang melibatkan penyimpanan kunci pribadi secara offchain. Secara umum, DONs dapat menawarkan keamanan, penyimpanan terdesentralisasi dari kunci individual untuk aplikasi dan/atau pengguna, dan digabungkan kemampuan ini dengan komputasi umum. Hasilnya adalah sejumlah aplikasi, tentu saja yang beberapa contohnya kami berikan pada tulisan ini, termasuk manajemen kunci untuk Proof of Cadangan (lihat Bagian 4.1) dan untuk kredensial terdesentralisasi pengguna (dan data digital lainnya aset) (lihat Bagian 4.3). Penjaga: Chainlink Penjaga [87] memungkinkan pengembang menulis kode untuk desentralisasi eksekusi pekerjaan off-chain, umumnya untuk memicu eksekusi smart contracts. Sebelum munculnya Keeper, pengembang biasanya mengoperasikan off-chain seperti itu logika mereka sendiri, menciptakan titik-titik kegagalan yang terpusat (serta banyak upaya pembangunan yang diduplikasi). Penjaga malah menyediakan kerangka kerja yang mudah digunakan outsourcing yang terdesentralisasi pada operasi ini, memungkinkan siklus pengembangan yang lebih pendek dan jaminan kuat akan keaktifan dan properti keamanan lainnya. Penjaga dapat mendukung siapa pun dari berbagai macam tujuan pemicu, termasuk likuidasi pinjaman atau pelaksanaan transaksi keuangan, inisiasi airdrop atau pembayaran yang bergantung pada waktu dalam sistem dengan pemanenan hasil, dan sebagainya. Dalam kerangka DON, inisiator dapat dipandang sebagai generalisasi Penjaga dalam beberapa pengertian. Inisiator dapat menggunakan adaptor, dan dengan demikian dapat memanfaatkan a perpustakaan antarmuka yang termodulasi ke sistem on-chain dan off-chain, memungkinkan proses yang cepat pengembangan fungsionalitas yang aman dan canggih. Inisiator memulai komputasi di executable, yang menawarkan keserbagunaan penuh DONs, memungkinkan penggunaan yang luas berbagai layanan terdesentralisasi yang kami sajikan dalam makalah ini untuk aplikasi on-chain dan off-chain. 3.6.4 Reputasi Node / Riwayat Kinerja Ekosistem Chainlink yang ada secara asli mendokumentasikan riwayat kinerja menyumbangkan node pada rantai. Fitur ini telah memunculkan kumpulan sumber daya berorientasi reputasi yang menyerap, menyaring, dan memvisualisasikan data kinerja individu operator node dan data feed. Pengguna dapat mereferensikan sumber daya ini untuk mendapatkan informasi keputusan dalam pemilihan node dan untuk memantau pengoperasian jaringan yang ada. Kemampuan serupa akan membantu pengguna memilih DONs. Misalnya, pasar tanpa izin saat ini seperti market.link mengizinkan node operator untuk mencantumkan layanan oracle mereka dan membuktikan identitas off-chain mereka melalui layanan seperti Keybase [4], yang mengikat profil sebuah node di Chainlink ke nama domain dan akun media sosial pemilik yang ada. Selain itu, kinerja alat analisis, seperti yang tersedia di market.link dan reputasi.link, mengizinkan pengguna untuk melihat statistik kinerja historis masing-masing node, termasuk node mereka latensi respons rata-rata, penyimpangan nilai dalam laporan mereka dari nilai konsensus diteruskan pada rantai, pendapatan yang dihasilkan, pekerjaan yang terpenuhi, dan banyak lagi. Alat analisis ini juga memungkinkan pengguna melacak adopsi berbagai jaringan oracle oleh pengguna lain, suatu bentukdukungan implisit terhadap node yang mengamankan jaringan tersebut. Hasilnya adalah “jaring” yang datar kepercayaan” di mana, dengan menggunakan node tertentu, terciptalah aplikasi terdesentralisasi yang bernilai tinggi sinyal kepercayaan mereka pada node yang dapat diamati dan diperhitungkan oleh pengguna lain keputusan pemilihan node sendiri. Dengan DONs (dan awalnya dengan OCR) terjadi pergeseran dalam pemrosesan transaksi dan aktivitas kontrak secara lebih umum di luar rantai. Model terdesentralisasi untuk merekam node kinerja tetap dimungkinkan dalam DON itu sendiri. Memang performanya tinggi dan kapasitas data sebesar DONs memungkinkan pembuatan catatan dengan cara yang lebih detail cara dan juga untuk melakukan perhitungan terdesentralisasi pada catatan-catatan ini, menghasilkan ringkasan yang dapat dipercaya yang dapat digunakan oleh layanan reputasi dan diperiksa di RANTAI UTAMA. Meskipun ada kemungkinan bagi DON pada prinsipnya untuk salah menggambarkan perilaku node konstituen jika sebagian besar node rusak, kami mencatat bahwa kolektif kinerja DON itu sendiri dalam mengirimkan data on-chain terlihat di MAINCHAIN dan dengan demikian tidak dapat disalahartikan. Selain itu, kami berencana untuk mengeksplorasi mekanisme itu memberi insentif pada pelaporan internal yang akurat tentang perilaku node di DON. Misalnya, dengan melaporkan subkumpulan node berperforma tinggi yang paling cepat mengembalikan kontribusi data ke laporan yang disampaikan secara berantai, DON menciptakan insentif bagi node untuk menyatakan kesalahan laporan: Salah memasukkan node dalam subset ini berarti salah mengecualikan node yang seharusnya dimasukkan dan oleh karena itu memberikan sanksi yang tidak sah kepada mereka. Kegagalan pelaporan yang berulang-ulang oleh DON juga akan menciptakan insentif bagi node yang jujur untuk meninggalkan DON. Kompilasi sejarah kinerja yang akurat dan konsekuensinya secara terdesentralisasi kemampuan pengguna untuk mengidentifikasi node berkinerja tinggi dan untuk membangun operator node reputasi adalah ciri pembeda yang penting dari ekosistem Chainlink. Kami tunjukkan di Bagian 9 bagaimana kita dapat mempertimbangkannya sebagai bagian penting dari pendekatan yang ketat dan pandangan luas tentang keamanan ekonomi yang diberikan oleh DONs.
Decentralized Services Enabled by Decentralized
Decentralized Services Enabled by Decentralized
Oracle Networks To illustrate the versatility of DONs and how they enable a host of new services, we present five 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-specific 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) Confidentiality-preserving DeFi, that is, financial 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 different, 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 sufficiently high-probability confirmation, 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 difficult for individual enterprises to remain abreast of the full ecosystem. • Blockchain-specific development resources: For many organizations, hiring or incubating cutting-edge blockchain expertise is difficult, 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. • Confidentiality: Enterprises are leery of exposing their sensitive and proprietary data on chain. To address the first three of these difficulties, 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-specific 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 modification to their internally developed applications. To address the additional problem of confidentiality, 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 confidentiality-preserving API modifications discussed in Section 7.1.2 and a number of application-specific 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 Identifier (DID), a universal identifier 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 modification into confidentiality-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 benefit 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 identifier—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 identifiers for users (e.g., Social Security Numbers (SSNs)) into on-chain identifiers 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 financial 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 financial 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 financial institution’s broader AML policy, which also typically involves monitoring user behaviors and watching fund flows, 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 beneficial alternative in several respects, namely by: (1) Making the KYC process more efficient for users and financial institutions, because once a credential is obtained, it could be presented seamlessly to any financial institution; (2) Reducing fraud by reducing opportunities for identity theft through compromise of personally identifiable information (PII) and spoofing during video verification; and (3) Reducing the risk of PII compromise in financial institutions, as users retain control of their own data. Given the multi-billion-dollar penalties paid by financial institutions for AML compliance failures, and the many financial institutions spending millions of dollars annually on KYC, improvements could yield considerable savings for financial institutions and, by extension, for consumers [196]. While the traditional financial 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 financial 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 financial 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 confidentiality of sensitive information. Specifically, 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 offchain, 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 confidentiality-preserving credentials helpful in making lending decisions. For example, credentials can attest to a borrower’s possession of (off-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 qualifications [209, 210]. Current accreditation processes are cumbersome and inefficient, 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 financial services accounts that prove compliance with accreditation regulations, facilitating a more efficient 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 financial 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 financial status. 4.4 Priority Channels Priority channels are a useful new service that is easy to build using a DON. Their
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 specifically for miners to enable infrastructure services, such as oracles, governance functions for contracts, etc.—not for ordinary userlevel activities such as financial 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 Confidentiality-Preserving DeFi / Mixicles Today, DeFi applications [1] provide little to no confidentiality 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 different ways that can plug such gaps, helping complement the privacy assurances of other systems. For example, Mixicles, a confidentialitypreserving DeFi instrument proposed by Chainlink Labs researchers [135], can conceal the asset type backing a financial instrument, and fit 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 financial 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 prespecified 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.
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 confidentiality-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 confidentiality. 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 confidentiality 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].
Layanan Terdesentralisasi Diaktifkan oleh Terdesentralisasi
Jaringan Oracle Untuk mengilustrasikan keserbagunaan DON dan cara DON mengaktifkan sejumlah layanan baru, kami menyajikan lima contoh aplikasi berbasis DON di bagian ini dan menjelaskannya kontrak hibrida yang mewujudkannya: (1) Bukti Cadangan, suatu bentuk layanan lintas rantai; (2) Berinteraksi dengan sistem enterprise/legacy, yaitu menciptakan berbasis middleware lapisan abstraksi yang memfasilitasi pengembangan aplikasi blockchain dengan minimal blockchain kode atau keahlian khusus; (3) Identitas terdesentralisasi, alat yang memungkinkan pengguna untuk memperoleh dan mengelola dokumen identitas dan kredensial mereka sendiri; (4) Saluran prioritas, layanan yang memastikan penyertaan transaksi infrastruktur penting secara tepat waktu (misalnya, oracle laporan) pada blockchain; dan (5) Menjaga kerahasiaan DeFi, yaitu keuangan smart contracts yang menyembunyikan data sensitif pihak yang berpartisipasi. Di sini, kita
gunakan SC untuk menunjukkan bagian MAINCHAIN dari kontrak hibrida dan menjelaskan DON komponen secara terpisah atau dalam istilah exec yang dapat dieksekusi. 4.1 Bukti Cadangan Untuk banyak aplikasi, berguna untuk menyampaikan status antara atau di antara blockchains. SEBUAH Aplikasi populer dari layanan tersebut adalah pembungkusan mata uang kripto. Koin yang dibungkus seperti itu karena WBTC [15] menjadi aset populer di Keuangan Terdesentralisasi (DeFi). Mereka melibatkan penyimpanan aset pendukung yang "terbungkus" pada sumbernya blockchain MAINCHAIN(1) dan membuat token yang sesuai pada target blockchain MAINCHAIN(2) yang berbeda. Misalnya, WBTC adalah ERC20 token di Ethereum blockchain yang sesuai ke BTC di Bitcoin blockchain. Karena kontrak pada MAINCHAIN(2) tidak memiliki visibilitas langsung ke MAINCHAIN(1), mereka harus bergantung secara eksplisit atau implisit pada oracle untuk melaporkan simpanan yang dibungkus aset dalam smart contract, menghasilkan apa yang terkadang disebut Bukti Cadangan. Di WBTC [15], misalnya, kustodian BitGo memegang BTC dan menerbitkan WBTC, dengan Chainlink jaringan menyediakan Bukti Cadangan [76]. DON sendiri dapat memberikan Bukti Cadangan. Namun, dengan DON, hal itu mungkin dilakukan untuk melangkah lebih jauh. DON dapat mengelola rahasia dan, melalui penggunaan adaptor yang sesuai, dapat bertransaksi di blockchain mana pun yang diinginkan. Oleh karena itu, DON dapat bertindak sebagai salah satu di antara sejumlah kustodian—atau bahkan sebagai satu-satunya kustodian yang terdesentralisasi—untuk aset yang dibungkus. DONs dengan demikian dapat berfungsi sebagai platform untuk meningkatkan keamanan layanan yang ada yang menggunakan Bukti Cadangan. Misalnya, MAINCHAIN(1) adalah Bitcoin dan MAINCHAIN(2) adalah Ethereum. Di MAINCHAIN(2), kontrak SC menerbitkan tokens yang mewakili BTC yang dibungkus. DON mengontrol alamat BTC addr (1) DON. Untuk membungkus BTC, pengguna U mengirimkan X BTC dari tambahan(1) kamu untuk menambahkan(1) DON bersama dengan alamat MAINCHAIN(2)(2) kamu. Monitor DON tambahan(1) DON melalui adaptor ke MAINCHAIN(1). Saat mengamati deposit U, dengan konfirmasi probabilitas yang cukup tinggi, ia mengirimkan pesan ke SC melalui adaptor ke RANTAI UTAMA(2). Pesan ini menginstruksikan SC untuk mencetak X tokens untuk addr(2) kamu. Jika U melepaskan X tokens, hal sebaliknya akan terjadi. Namun, di MAINCHAIN(1), tambahan(1) DON mengirimkan X BTC ke alamat(1) U (atau ke alamat lain, jika diminta oleh pengguna). Tentu saja, protokol-protokol ini dapat diadaptasi untuk bekerja dengan bursa, bukan secara langsung dengan pengguna. 4.2 Berinteraksi dengan Sistem Perusahaan / Warisan DONs dapat berfungsi sebagai jembatan antara blockchains, seperti pada contoh Bukti Cadangan, namun tujuan lainnya adalah agar cadangan tersebut bertindak sebagai jembatan dua arah di antara keduanya blockchains dan sistem lama [176] atau sistem serupa blockchain seperti bank sentral mata uang digital [30]. Perusahaan menghadapi sejumlah tantangan dalam menghubungkan sistem dan sistem yang ada proses ke sistem desentralisasi, termasuk:• Ketangkasan Blockchain: Sistem Blockchain berubah dengan cepat. Suatu perusahaan mungkin menghadapi kemunculan baru yang cepat atau peningkatan popularitas blockchains pihak lawan ingin melakukan transaksi, tetapi perusahaan tidak memilikinya dukungan infrastruktur yang ada. Secara umum, dinamisme blockchains membuat sulit bagi masing-masing perusahaan untuk tetap mengikuti ekosistem secara keseluruhan. • Sumber daya pengembangan khusus Blockchain: Bagi banyak organisasi, merekrut atau menginkubasi keahlian blockchain yang mutakhir adalah hal yang sulit, terutama mengingat tantangan ketangkasan. • Manajemen kunci pribadi: Mengelola kunci pribadi untuk blockchains atau mata uang kripto memerlukan keahlian operasional yang berbeda dari keamanan siber tradisional praktek dan tidak tersedia untuk banyak perusahaan. • Kerahasiaan: Perusahaan enggan mengungkapkan hal-hal sensitif dan hak milik mereka data pada rantai. Untuk mengatasi tiga kesulitan pertama ini, pengembang cukup menggunakan DON sebagai lapisan middleware yang aman untuk memungkinkan sistem perusahaan membaca atau menulis blockchaindtk. DON dapat mengabstraksi pertimbangan teknis terperinci seperti dinamika gas, reorganisasi rantai, dan sebagainya, baik untuk pengembang maupun pengguna. Oleh menghadirkan antarmuka blockchain yang disederhanakan ke sistem perusahaan, dengan demikian DON dapat sangat menyederhanakan pengembangan aplikasi perusahaan yang sadar akan blockchain, menghilangkan beban perusahaan dalam memperoleh atau menginkubasi sumber daya pengembangan khusus blockchain. Penggunaan DONs seperti ini sangat menarik karena memungkinkan pengembang perusahaan untuk melakukannya membuat aplikasi kontrak pintar yang sebagian besar blockchain agnostik. Akibatnya, lebih besar kumpulan blockchain yang mana DON diinstrumentasikan untuk bertindak sebagai middleware, maka lebih besar kumpulan blockchain yang dapat diakses dengan mudah oleh pengguna perusahaan. Pengembang dapat mem-porting aplikasi dari blockchain yang ada ke yang baru dengan sedikit modifikasi ke aplikasi yang dikembangkan secara internal. Untuk mengatasi masalah tambahan kerahasiaan, pengembang dapat mengajukan banding ke alat yang kami perkenalkan dalam makalah ini dan diharapkan dapat diterapkan untuk mendukung aplikasi DON. Ini termasuk DECO dan Town Crier Bagian 3.6.2 serta menjaga kerahasiaan Modifikasi API dibahas di Bagian 7.1.2 dan sejumlah pendekatan khusus aplikasi yang dibahas di sisa bagian ini. Sistem DON ini dapat menyediakan pengesahan on-chain berintegritas tinggi tentang status sistem perusahaan tanpa mengungkapkannya data sumber perusahaan yang sensitif pada rantai. 4.3 Identitas Terdesentralisasi Identitas terdesentralisasi adalah istilah umum untuk gagasan bahwa pengguna harus dapat melakukannya memperoleh dan mengelola kredensial mereka sendiri, daripada mengandalkan pihak ketiga untuk melakukannya jadi. Kredensial yang terdesentralisasi adalah pengesahan terhadap atribut atau pernyataan pemegangnya,yang sering disebut klaim. Kredensial ditandatangani secara digital oleh entitas, sering disebut penerbit, yang secara resmi dapat mengaitkan klaim dengan pengguna. Dalam sebagian besar skema yang diusulkan, klaim dikaitkan dengan Pengidentifikasi Terdesentralisasi (DID), yaitu pengidentifikasi universal untuk pengguna tertentu. Kredensial terikat pada kunci publik yang kunci privatnya dimiliki pengguna. Dengan demikian, pengguna dapat membuktikan kepemilikan klaim menggunakan kunci pribadinya. Visioner sebagai identitas terdesentralisasi adalah skema yang ada dan yang diusulkan, misalnya [14, 92, 129, 216], memiliki tiga keterbatasan parah: • Kurangnya kompatibilitas warisan: Sistem identitas terdesentralisasi yang ada bergantung pada a komunitas otoritas, yang disebut penerbit, untuk menghasilkan kredensial DID. Karena layanan web yang ada umumnya tidak menandatangani data secara digital, penerbit harus diluncurkan sebagai sistem tujuan khusus. Karena tidak ada insentif untuk melakukan hal ini tanpa a ekosistem identitas yang terdesentralisasi, menimbulkan masalah ayam dan telur. Di tempat lain Dengan kata lain, tidak jelas bagaimana melakukan bootstrap pada ekosistem emiten. • Manajemen kunci yang tidak dapat diterapkan: Sistem identitas yang terdesentralisasi mengharuskan pengguna untuk melakukan hal tersebut mengelola kunci pribadi, sesuatu yang ditunjukkan oleh pengalaman dengan mata uang kripto menjadi tanggung jawab yang tidak bisa dijalankan. Diperkirakan sekitar 4.000.000 Bitcoin telah terjadi hilang selamanya karena kegagalan manajemen kunci [194], dan banyak pengguna menyimpannya aset kripto dengan bursa [193], sehingga merusak desentralisasi. • Kurangnya penolakan Sybil untuk menjaga privasi: Persyaratan keamanan dasar aplikasi seperti pemungutan suara, alokasi token yang adil selama token penjualan, dll. adalah bahwa pengguna tidak dapat menyatakan banyak identitas. Proposal identitas terdesentralisasi yang ada mengharuskan pengguna untuk mengungkapkan identitas dunia nyata mereka untuk mencapai hal tersebut Penolakan Sybil, sehingga merusak jaminan privasi yang penting. Masalah-masalah ini dapat diatasi dengan menggunakan kombinasi komite node melakukan komputasi terdistribusi dalam DON dan penggunaan alat seperti DECO atau Town Crier, seperti yang ditunjukkan dalam sistem bernama CanDID [160]. DECO atau Town Crier dengan desain dapat mengubah layanan web yang ada tanpa modifikasi menjadi penerbit kredensial yang menjaga kerahasiaan. Mereka mengaktifkan DON untuk mengekspor relevan data untuk tujuan ini menjadi kredensial sambil menyembunyikan data sensitif yang tidak seharusnya muncul dalam kredensial. Selain itu, untuk memfasilitasi pemulihan kunci bagi pengguna, sehingga mengatasi manajemen kunci masalahnya, DON dapat memungkinkan pengguna untuk menyimpan kunci pribadi dalam bentuk yang dibagikan secara rahasia. Pengguna bisa memulihkan kunci mereka dengan membuktikan ke node di DON—demikian pula, menggunakan Town Crier atau DECO—kemampuan untuk masuk ke akun dengan serangkaian penyedia web yang telah ditentukan (misalnya, Twitter, Google, Facebook). Keuntungan menggunakan Town Crier atau DECO, dibandingkan dengan OAUTH, adalah privasi pengguna. Kedua alat tersebut memungkinkan pengguna menghindari pengungkapan ke DON pengidentifikasi penyedia web—dari mana identitas dunia nyata sering kali dapat diperoleh. Terakhir, untuk memberikan perlawanan kepada Sybil, seperti yang ditunjukkan pada [160], DON dapat melakukan melakukan transformasi yang menjaga privasi dari pengidentifikasi dunia nyata yang unik bagi pengguna (misalnya, Nomor Jaminan Sosial (SSN)) ke dalam pengidentifikasi on-chain setelah pendaftaran pengguna.Sistem dengan demikian dapat mendeteksi registrasi duplikat tanpa data sensitif seperti SSN diungkapkan ke masing-masing DON node.7 DON dapat menyediakan layanan apa pun atas nama identitas desentralisasi eksternal sistem pada blockchains tanpa izin atau izin, misalnya, instance Hyperledger Indy [129]. Contoh aplikasi: KYC: Identitas yang terdesentralisasi menjanjikan sebagai sarana untuk mencapai tujuan tersebut merampingkan persyaratan untuk aplikasi keuangan di blockchains sambil meningkatkan pengguna privasi. Dua tantangan yang dapat diatasi adalah akreditasi dan kewajiban kepatuhan berdasarkan peraturan anti pencucian uang/kenali pelanggan Anda (AML/KYC). Peraturan AML di banyak negara mewajibkan lembaga keuangan (dan badan usaha lainnya) untuk menetapkan dan memverifikasi identitas individu dan badan usaha yang menjadi mitra mereka. mereka melakukan transaksi. KYC merupakan salah satu komponen lembaga keuangan kebijakan AML yang lebih luas, yang biasanya juga mencakup pemantauan perilaku pengguna dan pengawasan aliran dana. KYC biasanya melibatkan presentasi kredensial identitas pengguna dalam beberapa bentuk (misalnya, masuk ke formulir web online, memegang dokumen identitas di depan wajah pengguna dalam sesi video, dll.). Amankan pembuatan dan presentasi kredensial terdesentralisasi pada prinsipnya dapat menjadi alternatif yang bermanfaat dalam beberapa hal, yaitu dengan: (1) Pembuatan proses KYC lebih efisien bagi pengguna dan lembaga keuangan, karena sekaligus a kredensial diperoleh, maka dapat disajikan secara lancar ke lembaga keuangan mana pun; (2) Mengurangi penipuan dengan mengurangi peluang pencurian identitas melalui kompromi informasi pengidentifikasi pribadi (PII) dan pemalsuan selama verifikasi video; dan (3) Mengurangi risiko kompromi PII di lembaga keuangan, karena pengguna tetap memegang kendali dari data mereka sendiri. Mengingat denda miliaran dolar yang dibayarkan oleh lembaga keuangan atas kegagalan kepatuhan AML, dan banyaknya lembaga keuangan yang menghabiskan jutaan dolar setiap tahunnya untuk KYC, perbaikan dapat menghasilkan penghematan yang cukup besar bagi lembaga keuangan. dan, selanjutnya, untuk konsumen [196]. Sementara sektor keuangan tradisional berjalan lambat untuk mengadopsi alat kepatuhan baru, sistem DeFi semakin banyak yang menerapkannya [43]. Contoh penerapan: Pinjaman dengan jaminan rendah: Kebanyakan DeFi aplikasi itu pinjaman dukungan saat ini hanya berasal dari pinjaman yang dijamin sepenuhnya. Ini adalah pinjaman yang diberikan kepada peminjam yang menyetorkan aset mata uang kripto yang nilainya melebihi pinjaman. Baru-baru ini muncul minat terhadap apa yang umumnya disebut oleh komunitas DeFi sebagai pinjaman tanpa jaminan. Sebaliknya, ini adalah pinjaman yang memiliki agunan yang sesuai mempunyai nilai yang lebih kecil dari pokok pinjaman. Pinjaman dengan jaminan rendah menyerupai pinjaman yang sering diberikan oleh lembaga keuangan tradisional. Daripada mengandalkan atas jaminan yang dititipkan sebagai jaminan pelunasan pinjaman, mereka justru mendasarkan pemberian pinjaman keputusan tentang sejarah kredit peminjam. 7Transformasi ini bergantung pada fungsi pseudorandom terdistribusi (PRF).Pinjaman dengan jaminan rendah merupakan bagian pasar pinjaman DeFi yang baru lahir namun terus berkembang. Mereka bergantung pada mekanisme seperti yang digunakan oleh keuangan tradisional institusi, seperti kontrak hukum [91]. Persyaratan penting untuk pertumbuhan mereka akan menjadi kemampuan untuk memberikan data mengenai kelayakan kredit pengguna—faktor kunci dalam keputusan pemberian pinjaman konvensional—ke sistem DeFi dengan cara yang memberikan integritas yang kuat, yaitu, jaminan data yang benar. Sistem identitas terdesentralisasi yang mendukung DON akan memungkinkan calon peminjam untuk melakukannya menghasilkan kredensial dengan jaminan tinggi yang membuktikan kelayakan kredit mereka sambil menjaganya kerahasiaan informasi sensitif. Secara khusus, peminjam dapat menghasilkan dana ini kredensial berdasarkan catatan dari sumber online yang berwenang dan hanya mengekspos data yang dibuktikan oleh DON, tanpa memaparkan data lain yang berpotensi sensitif. Untuk Misalnya, peminjam dapat menghasilkan kredensial yang menunjukkan bahwa nilai kreditnya dengan a sekelompok biro kredit melebihi ambang batas tertentu (misalnya 750), tanpa mengungkapkannya skor tepat atau data lain apa pun dalam catatannya. Selain itu, jika diinginkan, kredensial tersebut dapat dibuat secara anonim, yaitu nama pengguna dapat diperlakukan sebagai data sensitif dan dirinya sendiri tidak terekspos ke oracle node atau dalam kredensial terdesentralisasinya. Kredensial sendiri dapat digunakan secara chain atau offchain, tergantung pada aplikasinya. Singkatnya, peminjam dapat memberikan informasi penting kepada pemberi pinjaman atas kreditnya sejarah dengan integritas yang kuat dan tanpa risiko pemaparan yang tidak perlu dan sensitif data. Peminjam juga dapat memberikan berbagai kredensial yang menjaga kerahasiaan lainnya membantu dalam membuat keputusan peminjaman. Misalnya, kredensial dapat membuktikan identitas peminjam kepemilikan aset (off-chain), seperti yang kami tunjukkan pada contoh berikutnya. Contoh permohonan: Akreditasi: Banyak yurisdiksi membatasi kelas investor yang dapat menjual sekuritas yang tidak terdaftar. Misalnya, di AS, SEC Peraturan D menetapkan bahwa untuk mendapatkan akreditasi bagi peluang penanaman modal tersebut, an individu harus memiliki kekayaan bersih $1 juta, memenuhi persyaratan pendapatan minimum tertentu, atau memiliki kualifikasi profesional tertentu [209, 210]. Akreditasi saat ini prosesnya rumit dan tidak efisien, seringkali memerlukan surat pengesahan akuntan, atau bukti serupa. Sistem identitas yang terdesentralisasi akan memungkinkan pengguna untuk menghasilkan kredensial akun layanan keuangan online yang ada yang membuktikan kepatuhan terhadap akreditasi peraturan, memfasilitasi proses KYC yang lebih efisien dan menjaga privasi. Itu Terlebih lagi, properti DECO dan Town Crier yang menjaga privasi akan mengizinkan hal ini kredensial yang harus dihasilkan dengan jaminan integritas yang kuat tanpa secara langsung mengungkapkan rincian status keuangan pengguna. Misalnya, pengguna dapat membuat kredensial membuktikan bahwa dia memiliki kekayaan bersih setidaknya $1 juta tanpa mengungkapkan tambahan apa pun informasi tentang status keuangannya. 4.4 Saluran Prioritas Saluran prioritas adalah layanan baru yang berguna dan mudah dibuat menggunakan DON. Mereka
tujuannya adalah untuk mengirimkan transaksi terpilih dan berprioritas tinggi secara tepat waktu di MAINCHAIN selama periode kemacetan jaringan. Saluran prioritas dapat dilihat sebagai salah satu bentuk kontrak berjangka pada ruang blok dan dengan demikian sebagai komoditas kripto, sebuah istilah yang diciptakan sebagai bagiannya dari Proyek Chicago [61, 136]. Saluran prioritas ditujukan secara khusus bagi para penambang untuk mengaktifkan layanan infrastruktur, seperti oracles, fungsi tata kelola untuk kontrak, dll.—bukan untuk aktivitas tingkat pengguna biasa seperti transaksi keuangan. Faktanya, seperti yang dirancang di sini, menjadi prioritas saluran yang diterapkan oleh kurang dari 100% kekuatan penambangan di jaringan saja bisa memberikan batasan yang longgar pada waktu pengiriman, mencegah penggunaannya karena sangat bergantung pada kecepatan tujuan seperti berlari ke depan. Gambar 10: Saluran prioritas adalah jaminan yang diberikan oleh penambang M—atau, lebih umum, a kumpulan penambang M—kepada pengguna U bahwa transaksinya τ akan ditambang dalam blok D penyertaan dalam mempool. SC kontrak dapat menggunakan pemantauan DON untuk menegakkan peraturan tersebut persyaratan layanan saluran. Saluran prioritas berbentuk kesepakatan antara penambang atau sekumpulan penambang (atau kumpulan penambangan) M yang menyediakan saluran dan pengguna U yang membayar biaya untuk akses. M setuju bahwa ketika U mengajukan transaksi τ ke mempool (dengan harga gas berapa pun,tetapi batas gas yang telah disepakati sebelumnya), M akan menempatkannya pada rantai di dalam blok D berikutnya.8 Idenya digambarkan secara skematis pada Gambar 10. Deskripsi kontrak saluran prioritas: Saluran prioritas dapat diwujudkan sebagai a hybrid smart contract kira-kira sebagai berikut. Kami membiarkan SC menunjukkan logika pada MAINCHAIN dan itu di DON oleh exec. SC menerima deposit/taruhan \(d from M and an advance payment \)p dari U. A DON executable exec memonitor mempool, memicu penempatan transaksi oleh U. Ini mengirimkan pesan sukses ke SC jika U mengirimkan transaksi yang ditambang oleh M cara yang tepat waktu dan pesan kegagalan jika terjadi kegagalan layanan. SC mengirimkan pembayaran $p ke M dengan pesan sukses dan mengirimkan semua sisa dana, termasuk $d, ke U jika menerima pesan kegagalan. Setelah penghentian berhasil, itu melepaskan deposit $d ke M. Penambang M tentu saja dapat menyediakan saluran prioritas secara bersamaan ke beberapa saluran pengguna dan dapat membuka saluran prioritas dengan U untuk sejumlah pesan yang telah disepakati sebelumnya. 4.5 Menjaga Kerahasiaan DeFi / Campuran Saat ini, DeFi aplikasi [1] memberikan sedikit atau bahkan tidak ada sama sekali kerahasiaan bagi pengguna: Semua transaksi terlihat secara berantai. Berbagai pendekatan berbasis nol pengetahuan, misalnya, [149, 217], dapat memberikan privasi transaksi, dan TEF cukup umum untuk mendukungnya. Tapi pendekatan-pendekatan ini tidak komprehensif, dan, misalnya, biasanya tidak menyembunyikan hal tersebut aset yang menjadi dasar transaksi. Serangkaian alat komputasi yang pada akhirnya ingin kami dukung dalam DONs akan memungkinkan privasi dalam sejumlah cara berbeda yang dapat menutup kesenjangan tersebut, membantu melengkapi jaminan privasi sistem lain. Misalnya, Mixicles, instrumen DeFi yang menjaga kerahasiaan yang diusulkan oleh Chainlink peneliti Labs [135], dapat menyembunyikan jenis aset yang mendukung instrumen keuangan, dan secara alami cocok dengan DON kerangka kerja. Mixicles paling mudah dijelaskan dalam hal penggunaannya untuk mewujudkan biner sederhana pilihan. Opsi biner adalah instrumen keuangan yang memiliki dua pengguna, yaitu kami lihat di sini untuk konsistensi dengan [135] sebagai pemain, bertaruh pada acara dengan dua kemungkinan hasil, misalnya, apakah suatu aset melebihi harga target pada waktu yang telah ditentukan. Contoh berikut mengilustrasikan gagasan tersebut. Contoh 2. Alice dan Bob adalah pihak dalam opsi biner berdasarkan nilai suatu aset disebut Token Gelembung Carol (CBT). Alice bertaruh bahwa CBT akan memiliki harga pasar sebesar minimal 250 USD pada waktu T = tengah hari tanggal 21 Juni 2025; Bob bertaruh sebaliknya. Setiap pemain menyetor 100 ETH dengan batas waktu yang telah ditentukan. Pemain dengan posisi menang menerima 200 ETH (yaitu, memperoleh 100 ETH). 8D tentu saja harus cukup besar untuk memastikan bahwa M dapat memenuhi probabilitas yang tinggi. Untuk Misalnya, jika M mengontrol 20% kekuatan penambangan di jaringan, ia mungkin memilih D = 100, memastikan probabilitas kegagalan sebesar ≈2 × 10−10, yaitu kurang dari satu dalam satu miliar.Mengingat jaringan O Chainlink oracle yang sudah ada, implementasi sistem cerdas dapat dilakukan dengan mudah. kontrak SC yang merealisasikan perjanjian pada Contoh 2. Kedua pemain masing-masing melakukan deposit 100 ETH di SC. Beberapa saat setelah T, permintaan q dikirim ke O meminta harga r CBT pada saat T.O mengirimkan laporan r harga tersebut kepada SC. SC kemudian mengirimkan uang ke Alice jika r ≥250 dan Bob jika tidak. Pendekatan ini, bagaimanapun, mengungkapkan r pada rantai—membuatnya menjadi mudah bagi pengamat untuk menyimpulkan aset yang mendasari opsi biner. Dalam terminologi Mixicles, akan sangat membantu jika memikirkan secara konseptual tentang hasilnya dari SC dalam bentuk Switch yang mentransmisikan nilai biner yang dihitung sebagai predikat beralih (r). Dalam contoh kita, switch(r) = 0 jika r ≥250; mengingat hasil ini, Alice menang. Jika tidak, switch(r) = 1 dan Bob menang. DON dapat mewujudkan Mixicle dasar sebagai kontrak hibrid dengan menjalankan executable exec yang menghitung switch(r) dan melaporkannya secara berantai ke SC. Kami menunjukkan konstruksi ini pada Gambar 11. Gambar 11: Diagram Mixicle dasar pada Contoh 2. Untuk memberikan kerahasiaan on-chain laporkan r, dan dengan demikian aset yang mendasari opsi biner, oracle dikirimkan ke kontrak SC melalui Switch hanya saklar nilai biner (r). Kami menentukan adaptor ConfSwitch di Lampiran C.3 yang memudahkan untuk mencapai hal ini gol dalam DON. Ide dasar di balik ConfSwitch cukup sederhana. Daripada melaporkan nilai r, ConfSwitch hanya melaporkan nilai saklar biner saklar (r). SC bisa dirancang untuk melakukan pembayaran yang benar berdasarkan switch(r) saja, dan switch(r) dengan sendirinya tidak mengungkapkan informasi tentang aset dasar—CBT dalam contoh kita. Selain itu, dengan menempatkan ciphertext pada (q, r) pada buku besar yang dienkripsi dengan pkaud, kunci publik dari seorang auditor, adaptor ConfSwitch menciptakan jejak audit yang menjaga kerahasiaan. Mixicle dasar yang kami pilih untuk kesederhanaan untuk dijelaskan di sini hanya menyembunyikannya aset dan bertaruh di belakang opsi biner dalam contoh kita. Mixicle lengkap [135] kaleng memberikan dua bentuk kerahasiaan. Ia menyembunyikan dari pengamat: (1) Peristiwa apa pemain bertaruh pada (yaitu, q dan r) tetapi juga (2) Pemain mana yang memenangkan taruhan. Karena Mixicles dieksekusi di MAINCHAIN, salah satu pemain harus melakukan relay switch(r) dari DON ke MAINCHAIN, atau exec yang dapat dieksekusi dapat dibuat
dipicu pada output oleh ConfSwitch dan memanggil adaptor lain untuk mengirim switch(r). RANTAI UTAMA. Jenis kerahasiaan yang ketiga dan halus juga patut dipertimbangkan. Dalam implementasi dasar ConfSwitch, O menjalankan adaptor di DON dan dengan demikian mempelajari aset—CBT dalam contoh kita—dan dengan demikian sifat dari opsi biner. Seperti yang dibahas pada Lampiran C.3, namun, DECO atau Town Crier juga dapat digunakan untuk bahkan menyembunyikan informasi ini dari O. Dalam kasus ini, O tidak mengetahui informasi lebih lanjut daripada pengamat publik SC. Untuk rincian lebih lanjut tentang Mixicles, kami merujuk pembaca ke [135].
Fair Sequencing Services
Fair Sequencing Services
One important service that we expect DONs will offer 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 benefit, 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 fits 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 benefit [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 affects 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 influence the order of those transactions that they commit themselves and exploit this to their advantage. The problem of undue influence 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 specified 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 first is monitoring of transactions. In FSS, oracle nodes in O both monitor the mempool of MAINCHAIN and (if desired) permit off-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 defined 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 benefits 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 specified 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 financial 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 flooding 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 exemplifies 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 off-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 different 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 first. 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 confirmed after a significant 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 affecting 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 difference 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 affected 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 finalized-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 flow outside the network. This represents a problem arising from deficiencies 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
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 different 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 flow 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 different approaches for FSS to monitor user transactions destined for a specific 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 specific 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 briefly discuss how existing DApps could be minimally modified 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 different 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-defined 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 benefits of decentralized transaction ordering, the target smart contract SC thus has to be designed to treat the DON as a “first-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 “buffered” by the smart contract for a fixed 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 “off-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 different 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 buffers 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 differ 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 different 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 different 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 first. 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 specific 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 first 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 first received by the DON (or the P2P network, in the case of a mempool-based FSS). In a decentralized system, however, different nodes may see transactions arrive in a different 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 conflicts 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 different deployment models, including synchronous, partially synchronous, and asynchronous network settings. Aequitas protocols impose significant 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 different 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 verifies that the opening satisfies 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 difficult 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 profitable. 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 verifiable 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 finally injects them into MAINCHAIN in the fixed 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 refined 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 difficulties. • 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 first 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 offer 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 significant 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 confidentiality. 5.4 Network-Layer Considerations So far, our description of FSS has mainly focused on the problem of enforcing that the finalized 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 efficacy 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 flooding 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 first 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 flooding a system with many transactions, a strategy observed in the wild as a way to perform effective 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 offer a possible approach to enriching transaction-ordering policies in a way that would limit opportunities for flooding attacks. For example, a token sale might permit only one transaction per registered user, where registration requires a proof of uniqueness of a national identifier, such as a Social Security Number. Such an approach isn’t foolproof, but may prove a useful policy to mitigate transactionflooding attacks.
Layanan Pengurutan yang Adil
Salah satu layanan penting yang kami harapkan akan ditawarkan oleh DONs yang memanfaatkan kemampuan jaringan, komputasi, dan penyimpanannya disebut Fair Sequencing Services (FSS). Meskipun FSS mungkin dipandang hanya sebagai aplikasi yang diwujudkan dalam kerangka DON, kami menyorotinya sebagai layanan yang kami yakini akan memiliki permintaan tinggi di seluruh dunia. blockchains, dan kami berharap jaringan Chainlink akan mendukung secara aktif. Ketika dijalankan di jaringan blockchain publik, banyak aplikasi DeFi saat ini mengungkapkan informasi yang dapat dimanfaatkan oleh pengguna untuk keuntungan mereka sendiri, serupa dengan jenis kebocoran orang dalam dan peluang manipulasi yang tersebar luas pasar [64, 155]. FSS malah membuka jalan menuju ekosistem DeFi yang adil. FSS membantu pengembang membangun kontrak DeFi yang terlindungi dari manipulasi pasar akibat kebocoran informasi. Mengingat masalah yang kami soroti di bawah ini, FSS adalah jawabannya sangat menarik untuk layanan lapisan-2 dan cocok dengan kerangka layanan tersebut yang kita bahas di Bagian 6. Tantangannya: Dalam sistem tanpa izin yang ada, transaksi diurutkan seluruhnya atas kebijaksanaan penambang. Dalam jaringan yang berizin, node validator mungkin digunakan kekuatan yang sama. Ini adalah bentuk sentralisasi sementara yang sebagian besar tidak diakui di negara ini jika tidak, sistem terdesentralisasi. Seorang penambang dapat (sementara) menyensor transaksinya keuntungan sendiri [171] atau susun ulang untuk memaksimalkan keuntungannya sendiri, sebuah gagasan yang disebut nilai yang dapat diekstraksi (minerextractable value/MEV) [90]. Istilah MEV sedikit menipu: Istilah ini tidak merujuk hanya untuk nilai yang dapat ditangkap oleh penambang: Beberapa MEV dapat ditangkap oleh pengguna biasa. Namun, karena penambang memiliki kekuatan yang lebih besar daripada pengguna biasa, MEV mewakili batas atas jumlah nilai yang dapat diperoleh entitas mana pun melalui penataan ulang permusuhan. dan penyisipan transaksi pelengkap. Bahkan ketika penambang memesan transaksi dengan sederhana berdasarkan biaya (gas), tanpa manipulasi, pengguna sendiri dapat memanipulasi harga gas untuk menguntungkan transaksi mereka dibandingkan transaksi yang kurang canggih. Daian dkk. [90] mendokumentasikan dan mengukur cara yang dilakukan bot (bukan penambang). keuntungan dinamika gas dengan cara yang merugikan pengguna sistem DeFi saat ini dan bagaimana caranya MEV bahkan mengancam stabilitas lapisan konsensus yang mendasarinya di blockchain. Contoh lain dari manipulasi urutan transaksi muncul secara teratur, misalnya, [50, 154].Metode pemrosesan transaksi baru seperti rollups adalah pendekatan yang sangat menjanjikan untuk masalah penskalaan blockchains throughput tinggi. Namun mereka tidak membahasnya masalah MEV. Sebaliknya, mereka mengalihkannya ke entitas yang menghasilkan rollup. Itu entitas, baik operator smart contract atau pengguna yang memberikan (zk-)rollup dengan bukti keabsahan, mempunyai kuasa untuk memerintahkan dan memasukkan transaksi. Dengan kata lain, rollups tukar MEV dengan REV: Nilai Rollup-Extractable. MEV mempengaruhi transaksi mendatang yang telah dikirimkan ke mempool tetapi belum berkomitmen pada rantai. Informasi tentang transaksi tersebut tersebar luas tersedia di jaringan. Penambang, validators, dan peserta jaringan biasa bisa oleh karena itu manfaatkan pengetahuan ini dan ciptakan transaksi yang bergantung. Selain itu, penambang dan validator dapat memengaruhi urutan transaksi yang mereka lakukan diri mereka sendiri dan memanfaatkannya untuk keuntungan mereka. Masalah pengaruh yang tidak semestinya dari para pemimpin terhadap tatanan transaksi berdasarkan konsensus protokol telah dikenal dalam literatur sejak tahun 1990an [71, 190], namun belum ada yang memuaskan. solusi telah direalisasikan dalam praktik sejauh ini [97]. Alasan utamanya adalah solusi-solusi yang diusulkan—setidaknya hingga saat ini—tidak dapat langsung diintegrasikan ke masyarakat blockchains, karena mereka mengandalkan konten transaksi yang tetap dirahasiakan hingga setelahnya pesanan mereka telah ditentukan. Ikhtisar Layanan Pengurutan Adil (FSS): DONs akan menyediakan alat untuk mendesentralisasikan pemesanan transaksi dan menerapkannya sesuai dengan kebijakan yang ditentukan oleh pihak yang mengandalkan pembuat kontrak, idealnya yang adil, dan tidak menguntungkan pihak-pihak yang menginginkannya memanipulasi pemesanan transaksi. Secara kolektif, alat-alat ini merupakan FSS. FSS mencakup tiga komponen. Yang pertama adalah pemantauan transaksi. Di FSS, oracle node di O memantau mempool MAINCHAIN dan (jika diinginkan) mengizinkan penyerahan transaksi off-chain melalui saluran khusus. Yang kedua adalah urutan transaksi. Node dalam transaksi pesanan O untuk kontrak yang mengandalkan sesuai dengan kebijakan yang ditentukan untuk kontrak itu. Yang ketiga adalah posting transaksi. Setelah transaksi diurutkan, node-node di O bersama-sama mengirimkan transaksi tersebut ke rantai utama. Manfaat potensial dari FSS meliputi: • Kewajaran pesanan: FSS mencakup alat untuk membantu pengembang memastikan transaksi tersebut masukan pada suatu kontrak tertentu diurutkan sedemikian rupa sehingga tidak menimbulkan ketidakadilan keuntungan bagi pengguna yang memiliki sumber daya yang baik dan/atau paham secara teknis. Kebijakan pemesanan dapat ditentukan untuk tujuan ini. • Pengurangan atau penghapusan kebocoran informasi: Dengan memastikan bahwa peserta jaringan tidak dapat memanfaatkan pengetahuan tentang transaksi yang akan datang, FSS dapat mengurangi atau menghilangkan serangan seperti front-running yang didasarkan pada informasi yang tersedia di jaringan sebelum transaksi dilakukan. Mencegah eksploitasi terhadap hal tersebut kebocoran memastikan bahwa transaksi permusuhan yang bergantung pada pending asli transaksi tidak dapat masuk ke buku besar sebelum transaksi awal dilakukan.• Mengurangi biaya transaksi: Dengan menghilangkan kebutuhan pemain akan kecepatan dalam mengirimkan transaksi mereka ke smart contract, FSS dapat sangat mengurangi biaya pemrosesan transaksi. • Urutan prioritas: SJK secara otomatis dapat memberikan prioritas khusus pada transaksi-transaksi penting memesan. Misalnya, untuk mencegah serangan terdepan terhadap oracle laporan, misalnya [79], FSS dapat memasukkan laporan oracle ke dalam aliran transaksi secara surut. Tujuan umum FSS di DONs adalah memberdayakan DeFi pencipta untuk mewujudkan keadilan sistem keuangan, yaitu sistem yang tidak menguntungkan pengguna (atau penambang) tertentu atas yang lain berdasarkan kecepatan, pengetahuan orang dalam, atau kemampuan untuk melakukan teknis manipulasi. Meskipun gagasan umum tentang keadilan masih sulit dipahami, dan keadilan yang sempurna tetap ada akal sehat apa pun tidak dapat dicapai, FSS bertujuan untuk menyediakan pengembang dengan kekuatan seperangkat alat sehingga mereka dapat menerapkan kebijakan yang membantu memenuhi tujuan desain mereka untuk DeFi. Kami mencatat bahwa tujuan utama FSS adalah bertindak sebagai layanan pengurutan yang adil RANTAI UTAMA yang menjadi target DON, beberapa dari keinginan keadilan yang sama dengan FSS jaminan juga dapat sesuai untuk protokol (terdesentralisasi) yang dijalankan di antara mereka DON pesta. Dengan demikian, FSS dapat dipandang lebih luas sebagai layanan yang disediakan oleh suatu subset dari DON node untuk mengurutkan secara wajar tidak hanya transaksi yang dikirim oleh pengguna MAINCHAIN tetapi juga transaksi (yaitu pesan) yang dibagikan di antara DON node lainnya. Di bagian ini, kami akan fokus terutama pada tujuan mengurutkan transaksi MAINCHAIN. Organisasi bagian: Di Bagian 5.1, kami menjelaskan dua aplikasi tingkat tinggi yang memotivasi desain FSS: mencegah laporan oracle yang berjalan di awal dan mencegah transaksi pengguna yang berjalan di depan. Kami kemudian memberikan rincian lebih lanjut tentang desain FSS di Bagian 5.2. Bagian 5.3 menjelaskan contoh-contoh jaminan dan sarana ketertiban yang adil untuk mencapainya. Terakhir, Bagian 5.4 dan Bagian 5.5 membahas ancaman tingkat jaringan terhadap kebijakan dan cara untuk mengatasinya, masing-masing untuk banjir jaringan dan Sybil serangan. 5.1 Masalah yang Berjalan di Depan Untuk menjelaskan tujuan dan desain FSS, kami menjelaskan dua bentuk umum front-running serangan dan keterbatasan solusi yang ada. Front-running mencontohkan sebuah kelas serangan pemesanan transaksi: Ada sejumlah serangan terkait seperti backrunning dan sandwiching (front-running plus back-running) [237] yang tidak kami bahas di sini, namun FSS juga membantu mengatasinya. 5.1.1 Oracle Terdepan Dalam peran tradisionalnya dalam menyediakan data off-chain ke blockchain aplikasi, oracles menjadi target alami untuk serangan terdepan.Pertimbangkan pola desain umum yang menggunakan oracle untuk memasok berbagai feed harga ke bursa on-chain: secara berkala (katakanlah setiap jam), oracle mengumpulkan data harga untuk aset yang berbeda dan mengirimkannya ke kontrak pertukaran. Transaksi data harga ini menghadirkan peluang arbitrase yang jelas: Misalnya, jika laporan oracle terbaru mencantumkan harga yang jauh lebih tinggi untuk beberapa aset, musuh dapat menjalankan laporan oracle terlebih dahulu ke membeli aset dan segera menjualnya kembali setelah laporan oracle diproses. Guncangan kecepatan dan penetapan harga yang berlaku surut: Solusi alami untuk masalah awal oracle adalah dengan memberikan prioritas khusus pada laporan oracle dibandingkan transaksi lainnya. Untuk misalnya, laporan oracle dapat dikirim dengan biaya tinggi untuk mendorong penambang agar memprosesnya mereka terlebih dahulu. Namun hal ini tidak akan mencegah terjadinya front-running jika peluang arbitrase tinggi, juga tidak dapat mencegah arbitrase yang dilakukan oleh para penambang itu sendiri. Oleh karena itu, beberapa bursa terpaksa menerapkan “speedbumps” kelas berat, seperti mengantri transaksi pengguna untuk sejumlah blok sebelum diproses. mereka, atau menyesuaikan harga secara surut ketika laporan oracle baru tiba. Kerugian dari solusi ini adalah menambah kompleksitas pada implementasi pertukaran, meningkatkan kebutuhan penyimpanan dan biaya transaksi, serta mengganggu pengalaman pengguna karena pertukaran aset hanya dikonfirmasi setelah jangka waktu yang signifikan. Membonceng: Sebelum beralih ke FSS, kita bahas piggybacking, cara yang cukup sederhana dan solusi elegan untuk masalah oracle yang sedang berjalan. Ini tidak berlaku untuk alamat Namun, berjalan paling depan dalam skenario lain. Singkatnya, alih-alih mengirimkan laporan secara berkala ke kontrak on-chain, oracles menerbitkan laporan bertanda tangan yang ditambahkan pengguna ke transaksi mereka saat membeli atau menjual aset on-chain. Pertukaran kemudian hanya memeriksa apakah laporan tersebut valid dan baru (misalnya, oracle dapat menandatangani rentang blok yang laporannya valid), dan mengekstrak umpan harga yang relevan darinya. Pendekatan sederhana ini memiliki sejumlah keunggulan dibandingkan “kecepatan” di atas. pendekatan: (1) Kontrak pertukaran tidak perlu mempertahankan status harga, yang seharusnya menyebabkan biaya transaksi lebih rendah; (2) Karena laporan oracle diposting secara berantai berdasarkan kebutuhan, oracles dapat menghasilkan pembaruan yang lebih sering (misalnya, setiap menit), sehingga meminimalkan peluang arbitrase dalam menjalankan laporan9; (3) Transaksi dapat divalidasi segera, karena mereka selalu menyertakan feed harga baru. Namun pendekatan ini tidak sempurna. Pertama, solusi membonceng ini mengedepankan tanggung jawab pengguna bursa untuk mengambil laporan oracle terkini dan melampirkannya ke transaksi. Kedua, meskipun membonceng meminimalkan peluang arbitrase, hal ini tidak bisa dilakukan sepenuhnya mencegahnya tanpa mempengaruhi keberlangsungan kontrak on-chain. Memang benar, jika sebuah Laporan oracle valid sampai beberapa blok nomor n, kemudian transaksi dikirimkan ke blok n + 1 akan memerlukan laporan baru yang valid. Karena keterlambatan yang melekat dalam penyebaran laporan dari oracles ke pengguna, laporan baru yang valid untuk blok n + 1 akan memiliki 9Arbitrase hanya bermanfaat jika perbedaan harga aset yang dapat dieksploitasi melebihi perbedaan yang ada biaya yang diperlukan untuk membeli dan menjual aset, misalnya aset yang dikumpulkan oleh penambang dan bursa.untuk dipublikasikan beberapa waktu sebelum blok n + 1 ditambang, katakanlah di blok n −k, dengan demikian membuat urutan k blok di mana terdapat peluang arbitrase berumur pendek. Kami sekarang jelaskan bagaimana FSS mengatasi keterbatasan ini. Memprioritaskan laporan oracle dengan FSS: FSS dapat mengatasi oracle yang berjalan di depan masalah dengan mengembangkan solusi dukungan di atas, tetapi mendorong solusi tambahan pekerjaan menambah transaksi dengan laporan oracle ke Jaringan Oracle Terdesentralisasi. Pada tingkat tinggi, node oracle mengumpulkan transaksi yang ditujukan untuk pertukaran on-chain, menyetujui feed harga real-time, dan memposting feed harga bersama dengan transaksi yang dikumpulkan ke kontrak rantai utama. Secara konseptual, pendekatan ini dapat dianggap sebagai a “pengelompokan transaksi yang ditambah data”, di mana oracle memastikan bahwa umpan harga selalu ditambahkan ke transaksi. Solusi FSS dapat diimplementasikan secara transparan kepada pengguna bursa, dan dengan perubahan minimal pada logika kontrak, seperti yang kami jelaskan secara lebih rinci di Bagian 5.2. Memastikan bahwa laporan oracle baru selalu diprioritaskan dibandingkan transaksi pengguna hanyalah salah satu contohnya kebijakan pemesanan yang dapat diadopsi dan ditegakkan oleh FSS. Kebijakan FSS untuk memastikan ketertiban keadilan dijelaskan secara lebih umum di Bagian 5.3. 5.1.2 Transaksi Pengguna yang Berjalan di Depan Kita sekarang beralih ke front-running dalam aplikasi generik, dimana metode pertahanan di atas tidak berfungsi. Permasalahannya dapat ditangkap secara luas melalui skenario berikut: Musuh melihat beberapa transaksi pengguna tx1 dikirim ke jaringan P2P dan menyuntikkannya transaksi lawannya sendiri tx2, sehingga tx2 diproses sebelum tx1 (misalnya dengan membayar biaya transaksi yang lebih tinggi). Misalnya, front-running seperti ini biasa terjadi di kalangan bot yang mengeksploitasi peluang arbitrase di sistem DeFi [90] dan telah memengaruhi pengguna berbagai aplikasi terdesentralisasi [101]. Menerapkan ketertiban yang adil di antara transaksi diproses pada blockchain mengatasi masalah ini. Lebih mendasar lagi, melihat detail tx1 terkadang bahkan tidak diperlukan dan pengetahuan tentang keberadaannya saja dapat memungkinkan musuh untuk menyerang tx1 melaluinya memiliki tx2 dan menipu pengguna yang tidak bersalah yang membuat tx1. Misalnya, pengguna mungkin diketahui memperdagangkan aset tertentu pada waktu yang teratur. Untuk mencegah serangan tersebut diperlukan mitigasi yang menghindari kebocoran metadata juga [62]. Beberapa solusi untuk masalah ini memang ada, namun hal ini menimbulkan masalah penundaan dan kegunaan. Dari pesanan jaringan hingga pesanan selesai dengan FSS: Peluang untuk menjadi yang terdepan muncul karena sistem yang ada tidak memiliki mekanisme untuk menjamin ketertiban transaksi muncul dalam rantai menghormati urutan peristiwa dan aliran informasi di luar jaringan. Hal ini menunjukkan masalah yang timbul dari kekurangan dalam implementasi aplikasi (misalnya, platform perdagangan) pada blockchain. Idealnya, seseorang akan melakukannya memastikan bahwa transaksi dilakukan pada blockchain dalam urutan yang sama seperti sebelumnya dibuat dan dikirim ke jaringan P2P blockchain. Namun sejak jaringan blockchain
didistribusikan, tidak ada pesanan seperti itu yang dapat ditangkap. Oleh karena itu FSS memperkenalkan mekanisme untuk menjaga terhadap pelanggaran keadilan, yang timbul hanya karena didistribusikan sifat jaringan blockchain. 5.2 Detail FSS Gambar 12: Mempool pesanan adil dengan dua jalur transaksi berbeda: langsung dan berbasis mempool. Gambar 12 menunjukkan skema umum FSS. Untuk memastikan keadilan, DON penyedia FSS harus mengganggu aliran transaksi saat memasuki MAINCHAIN. Penyesuaian pada klien, pada smart contract di MAINCHAIN, atau keduanya mungkin diperlukan. Pada tingkat tinggi, pemrosesan transaksi oleh FSS dapat dipecah menjadi tiga tahapan yang diuraikan sebagai berikut: (1) Pemantauan transaksi; (2) Urutan transaksi; dan (3) Posting transaksi. Bergantung pada metode pemesanan yang digunakan untuk pengurutan transaksi, langkah-langkah protokol tambahan diperlukan, seperti yang dijelaskan di bagian berikutnya. 5.2.1 Pemrosesan Transaksi Pemantauan transaksi: Kami membayangkan dua pendekatan berbeda untuk dipantau oleh FSS transaksi pengguna yang ditujukan untuk smart contract tertentu, langsung dan berbasis mempool: • Langsung: Pendekatan langsung secara konseptual paling sederhana, namun memerlukan perubahan klien pengguna sehingga transaksi dikirim langsung ke Oracle TerdesentralisasiNode jaringan, bukan ke node rantai utama. DON dikumpulkan transaksi pengguna ditujukan ke smart contract SC tertentu dan mengurutkannya berdasarkan pada beberapa kebijakan pemesanan. DON kemudian mengirimkan transaksi pesanan ke smart contract pada rantai utama. Beberapa mekanisme pemesanan juga memerlukan pendekatan langsung karena pengguna yang membuat transaksi harus secara kriptografis lindungi sebelum mengirimnya ke FSS. • Berbasis Mempool: Untuk memfasilitasi integrasi FSS dengan klien lama, DON dapat menggunakan Mempool Services (MS) untuk memantau mempool rantai utama dan mengumpulkannya transaksi. Penularan langsung kemungkinan besar merupakan penerapan pilihan bagi banyak kontrak, dan kami yakin hal ini cukup praktis dalam banyak kasus. Kami membahas secara singkat bagaimana DApps yang ada dapat dimodifikasi secara minimal untuk mendukung transmisi langsung sambil menjaga pengalaman pengguna yang baik. Kami menjelaskan pendekatan menggunakan Ethereum dan MetaMask [6] karena ini adalah pilihan paling populer saat ini, tapi teknik yang disebutkan harus diperluas ke rantai dan dompet lainnya. Ethereum baru-baru ini Proposal Perbaikan, “EIP-3085: Dompet menambahkan Ethereum metode RPC rantai” [100], akan memudahkan penargetan rantai Ethereum khusus (menggunakan ID RANTAI yang berbeda dari yaitu MAINCHAIN untuk mencegah serangan replay) dari MetaMask dan dompet berbasis browser lainnya. Setelah penerapan proposal ini, DApp ingin menggunakan DON hanya akan menambahkan satu panggilan metode ke front-end mereka untuk dapat mengirimkan secara langsung transaksi ke DON mana pun yang menampilkan API yang kompatibel dengan Ethereum. Sementara itu, “EIP-712: Ethereum mengetik data terstruktur hashing dan penandatanganan” [49] memberikan sedikit alternatif yang lebih terlibat tetapi sudah diterapkan secara luas, yang dapat digunakan oleh pengguna DApp MetaMask untuk menandatangani data terstruktur yang menentukan transaksi DON. DApp dapat mengirim ini menandatangani data terstruktur ke DON. Terakhir, kami mencatat bahwa pendekatan hibrid juga dimungkinkan. Misalnya warisan klien dapat terus mengirim transaksi ke mempool rantai utama, tetapi penting transaksi (misalnya, laporan oracle) dikirim ke DON node secara langsung (khususnya, kumpulan node yang menyediakan laporan oracle seperti pembaruan umpan harga dan kumpulan node asalkan FSS mungkin tumpang tindih atau identik). Urutan transaksi: Tujuan utama FSS adalah untuk menjamin bahwa transaksi pengguna diatur sesuai dengan kebijakan yang telah ditentukan sebelumnya. Sifat dari kebijakan ini akan bergantung pada kebutuhan aplikasi dan jenis pemesanan transaksi tidak adil yang dilakukannya bertujuan untuk mencegah. Karena FSS di DON mampu memproses data dan memelihara keadaan lokal, mereka mungkin menerapkan kebijakan pengurutan yang sewenang-wenang berdasarkan informasi yang ada tersedia di oracles. Kebijakan pemesanan tertentu dan implementasinya dibahas selanjutnya di Bagian 5.3.Postingan transaksi: Setelah mengumpulkan dan memesan transaksi pengguna, yang diterima langsung dari pengguna atau dikumpulkan dari mempool, DON mengirimkan transaksi ini ke rantai utama. Dengan demikian, interaksi DON dengan rantai utama tetap ada tunduk pada pemesanan transaksi (yang berpotensi tidak adil) yang diatur oleh penambang rantai utama. Untuk memanfaatkan manfaat pemesanan transaksi yang terdesentralisasi, targetnya cerdas kontrak SC dengan demikian harus dirancang untuk memperlakukan DON sebagai warga negara “kelas satu”. Kami membedakan dua pendekatan: • Kontrak khusus DON: Opsi desain paling sederhana adalah membuat rantai utama cerdas kontrak SC hanya menerima transaksi yang telah diproses oleh DON. Ini memastikan bahwa smart contract memproses transaksi sesuai urutan yang diusulkan oleh DON, namun secara de facto membatasi smart contract untuk beroperasi dalam sistem berbasis komite (yaitu, komite DON sekarang mempunyai kekuasaan yang berkelanjutan untuk menentukan pemesanan dan penyertaan transaksi). • Kontrak kelas ganda: Desain yang disukai dan lebih terperinci memiliki rantai utama yang cerdas kontrak SC menerima transaksi yang berasal dari DON dan dari warisan pengguna,10 tetapi menempatkan “kecepatan” tradisional pada transaksi yang tidak diproses oleh DON. Misalnya, transaksi dari DON dapat diproses segera, sedangkan transaksi lama akan “disangga” oleh smart contract untuk jangka waktu tertentu. Mekanisme standar lainnya untuk mencegah front-running seperti skema pengungkapan komitmen atau VDF [53] juga dapat diterapkan pada warisan transaksi. Hal ini memastikan bahwa transaksi yang dipesan DON benar-benar diproses perintah tersebut disetujui, tanpa memberikan DON wewenang yang tidak diinginkan untuk melakukan sensor transaksi. Karena penerapan pemesanan transaksi oleh FSS mengharuskan transaksi diagregasi secara “off-chain,” solusi ini secara alami dikombinasikan dengan teknik agregasi lain yang bertujuan untuk mengurangi biaya pemrosesan on-chain. Misalnya setelah mengumpulkan dan memesan transaksi, DON dapat mengirimkan transaksi ini ke rantai utama sebagai a satu “transaksi batch” (misalnya, rollup), sehingga mengurangi transaksi agregat biaya. Menegakkan perintah transaksi: Baik dalam desain DON saja atau kelas ganda, rantai utama smart contract SC dan DON harus dirancang bersama untuk menjamin bahwa pemesanan transaksi DON ditegakkan. Di sini juga, kami membayangkan hal yang berbeda pilihan desain: • Nomor urut: DON dapat menambahkan nomor urut ke setiap transaksi, dan mengirimkan transaksi ini ke mempool rantai utama. Yang utama 10Jika pemantauan transaksi DON didasarkan pada mempool, transaksi lama harus dapat dibedakan dari transaksi DON sehingga tidak dikumpulkan oleh DON, misalnya melalui tag khusus melekat dalam transaksi atau dengan menentukan harga gas tertentu, misalnya DON transaksi ada bensin harga di bawah ambang batas tertentu.rantai smart contract SC mengabaikan transaksi yang datang “di luar urutan.” Kami perhatikan bahwa dalam pengaturan ini, penambang rantai utama dapat memutuskan untuk mengabaikan DON pemesanan transaksi, sehingga menyebabkan transaksi gagal. Hal ini dimungkinkan dengan mempertahankan status (mahal) agar SC dapat menegakkan urutan transaksi yang benar analog dengan bagaimana TCP melakukan buffer terhadap paket yang rusak hingga paket hilang diterima. • Transaksi nonces: Untuk banyak blockchains, dan khususnya untuk Ethereum, Pendekatan penomoran urut di atas dapat memanfaatkan nonces transaksi bawaan menjadi menegakkan bahwa rantai utama smart contract SC memproses transaksi secara berurutan. Di sini, node DON mengirimkan transaksi ke rantai utama melalui satu akun rantai utama, dilindungi dengan kunci yang dibagikan di antara node DON. Akun itu transaksi nonce memastikan bahwa transaksi ditambang dan diproses dalam urutan yang benar. • Transaksi gabungan: DON dapat menggabungkan beberapa transaksi dalam rollup (atau dalam bundel yang mirip dengan rollup). Rantai utama smart contract harus ada dirancang untuk menangani transaksi agregat tersebut. • Gabungkan transaksi dengan proksi rantai utama: Di sini, DON juga mengelompokkan transaksi ke dalam satu “meta-transaksi” untuk rantai utama, namun bergantung pada proxy khusus smart contract untuk membongkar transaksi dan meneruskannya ke kontrak target SC. Teknik ini dapat berguna untuk kompatibilitas lama. Metatransaksi bertindak seperti rollup tetapi berbeda karena terdiri dari transaksi yang tidak terkompresi daftar transaksi yang diposting satu kali ke rantai utama. Desain terakhir memiliki keunggulan dalam mendukung transaksi pengguna secara lancar mereka sendiri diproksi melalui kontrak rantai utama sebelum mencapai target DON kontrak SC. Misalnya, pertimbangkan pengguna yang mengirim transaksi ke dompet tertentu kontrak, yang pada gilirannya mengirimkan transaksi internal ke SC. Menugaskan urutan nomor untuk transaksi seperti itu akan rumit, kecuali kontrak dompet penggunanya dirancang khusus untuk meneruskan nomor urut pada setiap transaksi internal SC. Demikian pula, transaksi internal tersebut tidak dapat dengan mudah digabungkan menjadi metatransaksi yang dikirim langsung ke SC. Kami mendiskusikan pertimbangan desain lebih lanjut untuk transaksi proxy seperti di bawah ini. 5.2.2 Atomisitas Transaksi Diskusi kita sejauh ini secara implisit mengasumsikan bahwa transaksi berinteraksi dengan satu transaksi on-chain smart contract (misalnya, pengguna mengirimkan permintaan pembelian ke bursa). Namun, di sistem seperti Ethereum, satu transaksi dapat terdiri dari beberapa transaksi internal, misalnya, satu smart contract yang memanggil fungsi dalam kontrak lain. Di bawah ini, kami menjelaskan dua strategi tingkat tinggi untuk mengurutkan transaksi “multi-kontrak”, sementara menjaga atomitas transaksi (yaitu, urutan tindakan yang ditentukan oleh semua transaksi dieksekusi dalam urutan yang benar, atau tidak dieksekusi sama sekali).Atomisitas yang kuat: Solusi paling sederhana adalah dengan menerapkan FSS, seperti dijelaskan di atas, langsung ke seluruh transaksi “multi-kontrak”. Artinya, pengguna mengirimkan transaksinya ke dalam jaringan dan FSS memantau, mengurutkan, dan memposting transaksi ini ke rantai utama. Pendekatan ini secara teknis sederhana, namun memiliki satu potensi keterbatasan: Jika pengguna transaksi berinteraksi dengan dua kontrak SC1 dan SC2 yang keduanya ingin dimanfaatkan secara adil layanan pengurutan, maka kebijakan pengurutan kedua kontrak ini harus konsisten. Artinya, diberikan dua transaksi berbeda tx1 dan tx2 yang masing-masing berinteraksi baik SC1 maupun SC2, kebijakan SC1 tidak boleh memerintahkan tx1 sebelum tx2 sedangkan kebijakan SC2 mengatur urutan sebaliknya. Untuk sebagian besar skenario yang menjadi perhatian, kami memperkirakan bahwa urutan kebijakan yang diadopsi oleh kontrak yang berbeda akan konsisten. Misalnya, SC1 dan SC2 mungkin ingin transaksi diurutkan berdasarkan perkiraan waktu kedatangannya di mempool, dan SC1 mungkin ingin laporan oracle tertentu selalu dikirimkan terlebih dahulu. Sebagai transaksi laporan oracle terakhir tidak berinteraksi dengan SC2, kebijakannya konsisten. Atomisitas lemah: Secara umum, FSS dapat diterapkan pada tingkat individu transaksi internal. Pertimbangkan transaksi dalam bentuk tx = { ˜txpre, ˜txSC, ˜txpost}, yang terdiri dari beberapa inisial transaksi ˜txpre, yang menghasilkan transaksi internal ˜txSC ke SC, yang pada gilirannya mengeluarkan transaksi internal ˜txpost. Kebijakan pengurutan SC mungkin menentukan caranya transaksi internal ˜txSC harus dipesan sehubungan dengan transaksi lain yang dikirim ke SC, tetapi biarkan urutan pengurutan untuk ˜txpre dan ˜txpost tetap terbuka. Mengingat hakikat pemrosesan transaksi dalam sistem seperti Ethereum, mengembangkan layanan pengurutan yang menargetkan transaksi internal tertentu tidaklah mudah. Dengan kontrak SC yang dirancang khusus, hal ini dapat diwujudkan sebagai berikut: 1. Transaksi tx dikirim ke jaringan dan ditambang (tanpa urutan apa pun dilakukan oleh FSS). ˜txpre awal dijalankan, dan memanggil ˜txSC. 2. SC tidak mengeksekusi ˜txSC dan kembali. 3. FSS memonitor transaksi internal ke SC, mengurutkannya, dan mempostingnya kembali ke SC (yaitu dengan mengirimkan transaksi ˜txSC langsung ke SC). 4. SC memproses transaksi ˜txSC yang diterima dari FSS, dan menerbitkan transaksi internal ˜txpost yang dihasilkan dari ˜txSC. Dengan pendekatan ini, transaksi tidak dieksekusi sepenuhnya secara atomik (yaitu, transaksi asli transaksi tx dipecah menjadi beberapa transaksi on-chain), tetapi urutannya transaksi internal dipertahankan. Solusi ini memerlukan sejumlah kendala desain. Misalnya, 'txpre tidak bisa asumsikan bahwa ˜txSC dan ˜txpost akan dieksekusi. Selain itu, SC harus dirancang sedemikian rupa mengeksekusi transaksi ˜txSC dan ˜txpost atas nama pengguna tertentu, meskipun demikiandikirim oleh FSS. Karena alasan ini, solusi “Strong Atomicity” lebih berbutir kasar di atas mungkin lebih disukai dalam praktiknya. Untuk menghormati ketergantungan yang lebih kompleks, yang melibatkan banyak transaksi dan transaksi internalnya masing-masing, dapat dimuat dalam penjadwal transaksi FSS fungsi rumit yang mirip dengan yang ditemukan pada manajer transaksi relasional manajer basis data. 5.3 Urutan Transaksi yang Adil Di sini kita membahas dua gagasan tentang keadilan dalam pengurutan transaksi dan penerapannya, yang dapat diwujudkan oleh FSS: keadilan ketertiban berdasarkan kebijakan diberlakukan oleh FSS dan pelestarian kausalitas yang aman, yang memerlukan metode kriptografi tambahan di FSS. Keadilan ketertiban: Keadilan ketertiban adalah gagasan keadilan sementara dalam protokol konsensus yang pertama kali diperkenalkan secara formal oleh Kelkar et al. [144]. Kelkar dkk. bertujuan untuk mencapai suatu bentuk kebijakan alami di mana transaksi berada diurutkan berdasarkan waktu pertama kali diterima oleh DON (atau jaringan P2P, dalam kasus FSS berbasis mempool). Namun, dalam sistem desentralisasi, hal ini berbeda node mungkin melihat transaksi tiba dalam urutan yang berbeda. Membangun ketertiban total pada semua transaksi adalah masalah yang diselesaikan oleh protokol konsensus yang mendasarinya RANTAI UTAMA. Kelkar dkk. [144] oleh karena itu perkenalkan gagasan yang lebih lemah dicapai dengan bantuan Jaringan Oracle Terdesentralisasi, yang disebut “keadilan urutan blok.” Ini mengelompokkan transaksi yang diterima DON selama interval waktu ke dalam a "blok" dan memasukkan semua transaksi blok secara bersamaan dan pada posisi yang sama (yaitu, tinggi) menjadi MAINCHAIN. Oleh karena itu, mereka diperintahkan bersama dan harus dapat dieksekusi secara paralel, tanpa menimbulkan konflik di antara mereka. Secara kasar, orderfairness kemudian menyatakan bahwa jika sebagian besar node melihat transaksi τ1 sebelum τ2, maka τ1 akan diurutkan sebelum atau di blok yang sama dengan τ2. Dengan memaksakan yang begitu kasar Dengan perincian pesanan transaksi, peluang terjadinya serangan front-running dan serangan terkait pesanan lainnya akan sangat berkurang. Kelkar dkk. mengusulkan keluarga protokol yang disebut Aequitas [144], yang alamatnya model penerapan yang berbeda, termasuk pengaturan jaringan sinkron, sinkron sebagian, dan asinkron. Protokol Aequitas membebankan overhead komunikasi yang signifikan dibandingkan dengan konsensus dasar BFT dan oleh karena itu tidak ideal untuk penggunaan praktis. Namun kami yakin akan muncul varian praktis dari Aequitas yang dapat digunakan untuk pengurutan transaksi di FSS dan aplikasi lainnya. Beberapa skema terkait telah telah diusulkan yang memiliki formalisme yang lebih sedikit dan sifat yang lebih lemah, misalnya, [36, 151, 236], tetapi kinerja praktisnya lebih baik. Skema ini dapat didukung di FSS juga. Perlu juga dicatat bahwa istilah “keadilan” muncul di tempat lain dalam blockchain sastra dengan arti yang berbeda, yaitu keadilan dalam arti memberikan kesempatan bagipenambang sebanding dengan sumber daya yang mereka berkomitmenkan [106, 181] atau dalam hal validators kesempatan yang sama [153]. Pelestarian kausalitas yang aman: Pendekatan yang paling dikenal luas untuk mencegah pelanggaran frontrunning dan pelanggaran pemesanan lainnya pada platform terdistribusi bergantung pada kriptografi teknik. Fitur umum mereka adalah menyembunyikan data transaksi itu sendiri, menunggu sampai urutan pada lapisan konsensus telah ditetapkan, dan untuk mengungkapkan data transaksi nanti untuk diproses. Ini menjaga urutan sebab akibat di antara transaksi-transaksi yang ada dieksekusi oleh blockchain. Gagasan keamanan dan protokol kriptografi yang relevan telah dikembangkan secara signifikan sebelum munculnya blockchains [71, 190]. Kondisi keamanan “input kausalitas” [190] dan “pelestarian kausalitas yang aman” [71, 97] mensyaratkan secara formal bahwa tidak ada informasi tentang suatu transaksi yang diketahui sebelum posisi transaksi ini dalam tatanan global ditentukan. Musuh tidak boleh dapat menyimpulkan informasi apa pun sampai saat itu, secara kriptografis rasa yang kuat. Seseorang dapat membedakan empat teknik kriptografi untuk mempertahankan kausalitas: • Protokol pengungkapan komitmen [29, 142, 145]: Daripada transaksi diumumkan yang jelas, hanya komitmen kriptografi terhadap transaksi yang disiarkan. Setelah semua transaksi yang dilakukan tetapi tersembunyi telah dipesan (di awal blockchain sistem di MAINCHAIN sendiri, tetapi di sini oleh FSS), pengirim harus membuka komitmen dan mengungkapkan data transaksi dalam interval waktu yang telah ditentukan. Jaringan kemudian memverifikasi bahwa pembukaan tersebut memenuhi komitmen sebelumnya. Itu asal muasal metode ini dimulai sebelum munculnya blockchains. Walaupun sederhana, pendekatan ini mempunyai banyak kelemahan dan tidak mudah diterapkan karena dua alasan. Pertama, karena hanya komitmen yang ada pada tingkat protokol pemesanan, maka semantik transaksi tidak dapat divalidasi selama konsensus. Perjalanan pulang pergi tambahan ke klien diperlukan. Namun, yang lebih parah adalah kemungkinan tidak adanya pembukaan pernah tiba, yang bisa berarti serangan penolakan layanan. Selain itu, itu sulit untuk menentukan apakah pembukaan tersebut valid secara konsisten dan terdistribusi cara karena semua peserta harus sepakat apakah pembukaan sudah tiba waktu. • Protokol pengungkapan komitmen dengan pemulihan tertunda [145]: Satu tantangan dengan Pendekatan commit-reveal adalah bahwa klien dapat melakukan transaksi secara spekulatif dan mengungkapkannya nanti hanya jika transaksi berikutnya menghasilkan keuntungan. SEBUAH Varian terbaru dari pendekatan commit-reveal meningkatkan ketahanan terhadap hal ini jenis perilaku buruk. Secara khusus, protokol TEX [145] mengatasi masalah ini menggunakan pendekatan cerdas di mana transaksi terenkripsi menyertakan kunci dekripsi dapat diperoleh dengan menghitung fungsi penundaan yang dapat diverifikasi (VDF) [53, 221]. Jika klien gagal mendekripsi transaksinya tepat waktu, orang lain dalam sistem akan mendekripsi itu atas namanya dengan memecahkan teka-teki kriptografi yang cukup sulit.• Enkripsi ambang batas [71, 190]: Metode ini mengeksploitasi yang dapat dilakukan oleh DON operasi kriptografi ambang batas. Asumsikan FSS memelihara enkripsi publik kunci pkO dan oracles berbagi kunci pribadi yang sesuai di antara mereka sendiri. Klien kemudian mengenkripsi transaksi di bawah pkO dan mengirimkannya ke FSS. perintah FSS transaksi di DON, lalu mendekripsinya, dan terakhir memasukkannya ke dalam RANTAI UTAMA dalam urutan tetap. Oleh karena itu enkripsi memastikan bahwa pemesanan dilakukan bukan berdasarkan isi transaksi, tetapi data itu sendiri tersedia kapan dibutuhkan. Metode ini awalnya diusulkan oleh Reiter dan Birman [190] dan kemudian disempurnakan oleh Cachin et al. [71], yang diintegrasikan dengan konsensus yang diizinkan protokol. Penelitian yang lebih baru telah mengeksplorasi penggunaan kriptografi ambang batas sebagai mekanisme tingkat konsensus untuk pesan umum [33, 97] dan untuk komputasi umum dengan data bersama [41]. Dibandingkan dengan protokol commit-reveal, enkripsi ambang batas mencegah serangan penolakan layanan sederhana (walaupun diperlukan kehati-hatian mengingat biaya komputasi dekripsi). Ini memungkinkan DON berjalan secara mandiri, dengan kecepatannya sendiri dan tanpa kecepatan menunggu tindakan klien selanjutnya. Transaksi dapat divalidasi segera setelah didekripsi. Selain itu, klien mengenkripsi semua transaksi dengan satu kunci untuk DON dan pola komunikasinya tetap sama seperti yang lain transaksi. Mengelola kunci ambang batas dengan aman dan dengan perubahan node Namun, O mungkin menimbulkan kesulitan tambahan. • Melakukan pembagian rahasia [97]: Daripada mengenkripsi data transaksi di bawah kunci yang dipegang oleh DON, klien juga dapat membagikannya secara rahasia untuk node di O. Menggunakan skema pembagian rahasia yang hibrid dan aman secara komputasi, transaksinya dienkripsi terlebih dahulu menggunakan sandi simetris dengan kunci acak. Hanya kunci simetris terkait yang dibagikan dan teks sandi dikirimkan ke DON. Klien harus mengirimkan satu key share ke setiap node di O menggunakan pesan terenkripsi secara terpisah. Langkah-langkah protokol lainnya sama dengan ambang batas enkripsi, kecuali data transaksi didekripsi dengan simetris algoritma setelah merekonstruksi kunci per transaksi dari bagiannya. Metode ini tidak memerlukan pengaturan atau pengelolaan sistem kriptografi kunci publik terkait dengan DON. Namun, klien harus mengetahui node di dalamnya HAI dan berkomunikasi dalam konteks yang aman dengan masing-masing dari mereka, di mana tempatnya beban tambahan pada klien. Meskipun metode kriptografi menawarkan perlindungan lengkap terhadap informasi bocor dari transaksi yang dikirimkan ke jaringan, mereka tidak menyembunyikan metadata. Untuk misalnya, alamat IP atau alamat Ethereum pengirim masih dapat digunakan musuh untuk melakukan serangan depan dan serangan lainnya. Berbagai peningkatan privasi teknik yang diterapkan pada lapisan jaringan, misalnya, [52, 95, 107], atau lapisan transaksi, misalnya, [13, 65], akan diperlukan untuk mencapai tujuan ini. Dampak dari suatu karya tertentu metadata, yaitu ke kontrak mana suatu transaksi dikirimkan, dapat (sebagian) disembunyikanmelalui multiplexing banyak kontrak pada DON yang sama. Penyembunyian kriptografi transaksi itu sendiri juga tidak mencegah prioritas transaksi yang dirusak DON node berkolusi dengan pengirim transaksi. Kausalitas yang aman sebagaimana dijamin oleh protokol kriptografi melengkapi jaminan ketertiban keadilan untuk kebijakan apa pun, dan kami bermaksud untuk mengeksplorasi kombinasi keduanya. metode, jika hal ini memungkinkan. Jika musuh tidak dapat memperoleh keuntungan yang signifikan mengamati metadata, protokol pelestarian kausalitas yang aman dapat digunakan bersamaan pendekatan pemesanan yang naif juga. Misalnya, node oracle dapat menulis transaksi ke L segera setelah mereka menerimanya, tanpa duplikasi. Transaksi kemudian akan terjadi diurutkan menurut penampilannya di L dan kemudian didekripsi. Kami juga berencana untuk mempertimbangkan penggunaan TEE sebagai cara untuk membantu menegakkan ketertiban yang adil; untuk Misalnya, Tesseract [44] mungkin dipandang mencapai bentuk keteraturan kausal, tapi satu diperkuat dengan kemampuan TEE dalam memproses transaksi dalam bentuk eksplisit sementara menjaga kerahasiaan mereka. 5.4 Pertimbangan Lapisan Jaringan Sejauh ini, uraian kami mengenai SJK terutama terfokus pada masalah penegakan hukum urutan transaksi yang diselesaikan cocok dengan urutan yang diamati dalam jaringan. Selanjutnya, kami mempertimbangkan masalah keadilan yang mungkin timbul pada lapisan jaringan itu sendiri. Pedagang frekuensi tinggi di pasar elektronik konvensional berinvestasi dalam jumlah besar sumber daya untuk mendapatkan kecepatan jaringan superior [64], dan pedagang di bursa mata uang kripto menunjukkan perilaku serupa [90]. Kecepatan jaringan memberikan keuntungan dalam hal keduanya mengamati transaksi pihak lain dan dalam menyampaikan transaksi pesaing. Salah satu pengobatan yang diterapkan dalam praktik dan dipopulerkan dalam buku Flash Boys [155] adalah "speed bump" pertama kali diperkenalkan di bursa IEX [128] dan kemudian di bursa lainnya pertukaran [179] (dengan hasil beragam [19]). Mekanisme ini memberlakukan penundaan (350 mikrodetik di IEX) pada akses ke pasar, dengan tujuan menetralisir keuntungan dalam kecepatan. Bukti empiris, mis. [128], mendukung keampuhannya dalam menurunkan perdagangan tertentu biaya untuk investor biasa. FSS dapat digunakan secara sederhana untuk mengimplementasikan asimetris speed bump—yang menunda transaksi masuk. Budish, Cramton, dan Shim [64] berpendapat bahwa eksploitasi keunggulan dalam kecepatan tidak dapat dihindari dalam pasar waktu berkelanjutan, dan mendukung perbaikan struktural dalam pasar waktu berkelanjutan bentuk pasar berbasis lelang batch. Namun pendekatan ini belum diterapkan secara luas di platform perdagangan yang ada. Sistem perdagangan konvensional bersifat terpusat, biasanya menerima transaksi melalui satu koneksi jaringan. Sebaliknya, dalam sistem desentralisasi, hal ini dimungkinkan mengamati penyebaran transaksi dari berbagai sudut pandang. Akibatnya, adalah mungkin untuk mengamati perilaku seperti banjir jaringan di jaringan P2P. Kami bermaksud untuk mengeksplorasi pendekatan lapisan jaringan terhadap FSS yang membantu pengembang menentukan kebijakan melarang perilaku jaringan yang tidak diinginkan tersebut.5.5 Kebijakan Kewajaran Tingkat Entitas Keadilan ketertiban dan kausalitas yang aman bertujuan untuk menegakkan ketertiban atas transaksi itu menghormati waktu ketika mereka dibuat dan pertama kali dikirimkan ke jaringan. Keterbatasan dari gagasan keadilan ini adalah bahwa hal itu tidak mencegah serangan yang dilakukan oleh musuh mendapatkan keuntungan dengan membanjiri sistem dengan banyak transaksi, sebuah strategi yang diamati di alam liar sebagai cara untuk melakukan sniping transaksi yang efektif dalam token penjualan [159] dan untuk menciptakan kemacetan yang mengakibatkan likuidasi posisi utang yang dijaminkan (CDP) [48]. Dengan kata lain, keadilan ketertiban menegakkan keadilan dalam kaitannya dengan transaksi, bukan pemain. Seperti yang ditunjukkan dalam sistem CanDID [160], dimungkinkan untuk menggunakan alat oracle seperti DECO atau Town Crier bersama dengan komite node (seperti DON) untuk mencapai berbagai bentuk perlawanan Sybil sekaligus melindungi privasi. Pengguna dapat mendaftarkan identitas dan memberikan bukti keunikannya tanpa mengungkapkan identitas dirinya. Kredensial yang tahan sybil menawarkan pendekatan yang mungkin untuk memperkaya pemesanan transaksi kebijakan dengan cara yang akan membatasi peluang serangan banjir. Misalnya, a token penjualan mungkin hanya mengizinkan satu transaksi per pengguna terdaftar, tempat pendaftaran memerlukan bukti keunikan tanda pengenal nasional, seperti Nomor Jaminan Sosial. Pendekatan seperti ini tidaklah mudah, namun bisa menjadi kebijakan yang berguna untuk memitigasi serangan banjir transaksi.
The DON Transaction-Execution Framework
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 off-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, off-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 verification: 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 off-chain component for order matching and an onchain component for clearing and settlement.
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 benefits: TEF carries three main benefits: • 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. • Confidentiality: The confidentiality 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, specifically 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 different handling: Within-contract transactions: Because it sidesteps the complications of gas dynamics, TEF provides SC more flexibility 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 confirmed 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 identifies 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 confirmed 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 confirm 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 beneficial front-running. Provided that \(\tau\) isn't mined before \(\tau'\) reaches the mempool, \(\tau'\) will precede \(\tau\), and \(\tau\) will effect 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 off-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 effecting 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, offering 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 different security guarantees, availability levels, and performance profiles. Briefly, storing state on the MAINCHAIN enables on-chain auditability and eliminates reliance on any party for state availability; on the other hand, storing state off-chain can reduce storage cost and improve throughput, at the cost of trusting storage providers (DON or third parties) for data availability. Of course, flexible 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 affects 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 confirmed on MAINCHAIN; and (3) The time for \(\tau_{\text{sync}}\) to take effect 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] Off-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 five 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 effected by a batch of transactions is computed off-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 differ in how SCa verifies state updates in \(\tau_{\text{sync}}\). The first, (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 verified the proof. Optimistic rollups do not include arguments of correctness, but have staking and challenge procedures that facilitate distributed verification 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 effect 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 inflict 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 confirmation is subtle and sometimes specific to the scheme, so that a thorough analysis is out of scope. For instance, certain schemes consider payment transactions as “trustless final” [109] before the state update is confirmed, 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 off-chain only and does not maintain all data on MAINCHAIN. Specifically, 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 off-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 benefit 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 specific 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 flexibility: These syncing options can be refined to provide more flexibility 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 significantly. • 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 offers 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.
Kerangka Kerja Eksekusi Transaksi DON
(DON-TEF) DONs akan memberikan oracle dan dukungan sumber daya terdesentralisasi untuk solusi lapisan-2 di dalamnya apa yang kami sebut Kerangka Eksekusi Transaksi Jaringan Oracle Terdesentralisasi (DONTEF) atau disingkat TEF. Saat ini, frekuensi pembaruan kontrak DeFi dibatasi oleh latensi rantai utama, misalnya, interval blok rata-rata 10-15 detik di Ethereum [104]—serta biaya mendorong data dalam jumlah besar secara berantai dan throughput komputasi/tx yang terbatas— memotivasi pendekatan penskalaan seperti sharding [148, 158, 232] dan eksekusi lapisan-2 [5, 12, 121, 141, 169, 186, 187]. Bahkan blockchains dengan waktu transaksi yang jauh lebih cepat, misalnya, [120], telah mengusulkan strategi penskalaan yang melibatkan komputasi off-chain [168]. TEF dimaksudkan untuk bertindak sebagai sumber daya lapisan-2 untuk sistem lapisan-1 / MAINCHAIN semacam itu. Menggunakan TEF, DONs dapat mendukung pembaruan yang lebih cepat dalam kontrak MAINCHAIN mempertahankan jaminan kepercayaan utama yang diberikan oleh rantai utama. TEF dapat mendukung salah satu dari sejumlah teknik dan paradigma eksekusi lapisan-2, termasuk rollups,11 rollups optimis, Validium, dll., serta model kepercayaan ambang batas di mana DON node mengeksekusi transaksi. TEF merupakan pelengkap FSS dan dimaksudkan untuk mendukungnya. Dengan kata lain, apapun aplikasi yang berjalan di TEF dapat menggunakan FSS. 11Sering disebut “zk-rollups,” merupakan istilah yang keliru karena tidak memerlukan bukti tanpa pengetahuan.
6.1 Ikhtisar TEF TEF adalah pola desain untuk konstruksi dan pelaksanaan hibrida yang berkinerja baik smart contract SC. Sesuai dengan ide utama di balik hybrid smart contracts, TEF melibatkan a dekomposisi SC menjadi dua bagian: (1) Apa yang dalam konteks TEF kita sebut sebagai jangkar kontrak SCa di MAINCHAIN dan (2) DON logika exect yang kita sebut TEF dapat dieksekusi. Kami menggunakan SC di sini untuk menunjukkan kontrak logis yang diterapkan oleh kombinasi SCa dan mengharapkan. (Seperti disebutkan di atas, kami berharap dapat mengembangkan alat kompiler untuk menguraikan a mengontrak SC secara otomatis ke dalam komponen ini.) Eksekusi TEF yang dapat dieksekusi adalah mesin yang memproses transaksi pengguna di SC. Itu dapat dijalankan dengan baik, karena dijalankan pada DON. Ini memiliki beberapa fungsi: • Penyerapan transaksi: exect menerima atau mengambil transaksi pengguna. Hal ini dapat dilakukan secara langsung, yaitu melalui penyerahan transaksi di DON, atau melalui MAINCHAIN mempool menggunakan MS. • Eksekusi transaksi cepat: memproses transaksi yang melibatkan aset di dalamnya SC. Ia melakukannya secara lokal, yaitu di DON. • Akses oracle / adaptor yang cepat dan murah: exect memiliki akses asli ke oracle laporan dan data adaptor lainnya yang menghasilkan, misalnya, aset yang lebih cepat, lebih murah, dan lebih akurat harga dari eksekusi MAINCHAIN. Selain itu, akses oracle off-chain berkurang biaya operasional oracle, maka biaya penggunaan sistem, dengan menghindari penyimpanan on-chain yang mahal. • Sinkronisasi: exect secara berkala mendorong pembaruan dari DON ke MAINCHAIN, memperbarui SCa. Kontrak jangkar adalah ujung depan MAINCHAIN SC. Sebagai komponen SC dengan tingkat kepercayaan yang lebih tinggi, komponen ini memiliki beberapa tujuan: • Penyimpanan aset: Dana pengguna disimpan, disimpan, dan ditarik dari SCa. • Sinkronisasi verifikasi: SCa dapat memverifikasi kebenaran pembaruan status saat dijalankan sinkronisasi, misalnya, SNARK yang dilampirkan ke rollups. • Pagar pembatas: SCa dapat mencakup ketentuan untuk melindungi terhadap korupsi atau kegagalan secara tepat. (Lihat Bagian 7 untuk rincian lebih lanjut.) Di TEF, dana pengguna disimpan di MAINCHAIN, artinya DON itu sendiri tidak bersifat hak asuh. Tergantung pada pilihan mekanisme sinkronisasi (lihat di bawah), pengguna mungkin memerlukannya untuk mempercayai DON hanya untuk laporan oracle yang akurat dan sinkronisasi tepat waktu dengan MAINCHAIN. Model kepercayaan yang dihasilkan sangat mirip dengan DEX berbasis buku pesanan, misalnya, [2], yang saat ini umumnya mencakup komponen off-chain untuk pencocokan pesanan dan komponen onchain untuk penyelesaian dan penyelesaian.Untuk menggunakan kosakata sistem pembayaran, orang mungkin menganggap exect sebagai komponennya SC bertanggung jawab untuk kliring, sedangkan SCa menangani penyelesaian. Lihat Gambar 13 untuk skemanya penggambaran TEF. Gambar 13: Skema TEF. Dalam contoh ini, transaksi melewati mempool dari MAINCHAIN melalui MS ke DON. Manfaat TEF: TEF membawa tiga manfaat utama: • Performa tinggi: SC mewarisi throughput DON yang jauh lebih tinggi dibandingkan MAINCHAIN untuk transaksi dan laporan oracle. Selain itu, exect dapat memproses transaksi lebih cepat dan merespons laporan oracle dengan lebih tepat waktu dibandingkan implementasi di MAINCHAIN saja. • Biaya lebih rendah: Proses sinkronisasi tidak terlalu sensitif terhadap waktu dibandingkan pemrosesan transaksi, dan transaksi dapat dikirim dari DON ke MAINCHAIN secara batch. Akibatnya, biaya on-chain per transaksi (misalnya biaya bahan bakar) dengan pendekatan ini jauh lebih rendah dibandingkan kontrak yang hanya berjalan di MAINCHAIN. • Kerahasiaan: Mekanisme kerahasiaan DON dapat dibawa ke menanggung SC.
Batasan TEF: Salah satu keterbatasan TEF adalah tidak mendukung proses instan penarikan, karena hanya terjadi di MAINCHAIN: Setelah mengirimkan permintaan penarikan bagi SCa, pengguna mungkin perlu menunggu hingga exect melakukan pembaruan status yang mencakup transaksi penarikan sebelum dapat disetujui. Kami membahas beberapa solusi parsial, namun, di Bagian 6.2. Keterbatasan lain dari TEF adalah tidak mendukung komposisi atom DeFi kontrak di MAINCHAIN, khususnya kemampuan untuk mengarahkan aset melalui beberapa DeFi kontrak dalam satu transaksi. TEF dapat, bagaimanapun, mendukung atomisitas tersebut DeFi kontrak berjalan pada DON yang sama. Kami juga membahas beberapa cara untuk mengatasi hal ini masalah di Bagian 6.2. 6.2 Perutean Transaksi Transaksi untuk SC dapat dikirim oleh pengguna langsung ke DON atau dapat disalurkan melalui mempool di MAINCHAIN (melalui FSS). Ada empat jenis transaksi yang berbeda, masing-masing diantaranya memerlukan penanganan yang berbeda: Transaksi dalam kontrak: Karena menghindari komplikasi dinamika gas, TEF memberi SC lebih banyak fleksibilitas dalam menangani transaksi dibandingkan dengan yang seharusnya. tersedia dalam kontrak lapisan-1. Misalnya, saat transaksi mempool di Ethereum dapat ditimpa oleh transaksi baru dengan harga gas yang lebih tinggi, SC dapat memperlakukan transaksi yang beroperasi pada aset dalam SC sebagai transaksi yang otoritatif segera setelah transaksi tersebut terlihat di mempool. Konsekuensinya, SC tidak perlu menunggu transaksi dikonfirmasi dalam satu blok, menghasilkan latensi yang sangat berkurang. Proksi: Pengguna mungkin ingin mengirim transaksi τ ke SC melalui kontrak dompet atau kontrak lain di MAINCHAIN. DON dapat melakukan simulasi eksekusi τ di MAINCHAIN untuk menentukan apakah menghasilkan transaksi lanjutan ke SC. Jika demikian, τ dapat diurutkan dengan transaksi lain untuk SC yang melakukan hal tersebut. Ada beberapa kemungkinan bagaimana DON mengidentifikasi transaksi tersebut: (1) DON dapat mensimulasikan semua transaksi di mempool (pendekatan yang mahal); (2) Kontrak tertentu atau jenis kontrak, misalnya dompet, dapat dicantumkan untuk dipantau oleh DON; atau (3) Pengguna bisa membubuhi keterangan transaksi untuk pemeriksaan DON. Masalah menjadi lebih rumit ketika satu transaksi berinteraksi dengan dua transaksi kontrak, SC1 dan SC2, keduanya menggunakan Layanan Pengurutan yang Adil dan memiliki kebijakan pemesanan yang tidak sesuai. DON mungkin, misalnya, mengurutkan τ paling lambat yang kompatibel dengan keduanya. Deposito: Transaksi yang menyetorkan aset MAINCHAIN ke SC perlu dikonfirmasi dalam satu blok sebelum SC dapat menganggapnya sah. Ketika mendeteksi penambangan a transaksi yang mengirimkan aset (misalnya, Ether) ke SCa, exect dapat langsung mengonfirmasinyadeposito. Misalnya, perusahaan dapat menerapkan harga yang dilaporkan oracle saat ini di DON ke aset. Penarikan: Seperti disebutkan di atas, batasan TEF adalah penarikan tidak selalu dapat dilakukan secara instan. Dalam model eksekusi tipe rollup, penarikan permintaan harus diurutkan dengan transaksi lain, yaitu digulung, agar aman diproses. Namun, ada beberapa solusi parsial terhadap keterbatasan ini. Jika DON dapat dengan cepat menghitung bukti validitas rollup hingga transaksi penarikan, kemudian mengamati transaksi pengguna τ di mempool exect dapat mengirimkan transaksi pembaruan status τ ′ untuk τ dengan harga bahan bakar yang lebih tinggi, semacam keuntungan yang berjalan di depan. Asalkan τ tidak ditambang sebelum τ ′ mencapai mempool, τ ′ akan mendahului τ, dan τ akan mempengaruhi penarikan yang disetujui. Dalam varian TEF yang DON diandalkan untuk menghitung pembaruan status (lihat varian penandatanganan ambang batas di bawah), DON sebagai alternatif dapat menentukan off-chain apakah τ harus disetujui mengingat keadaan SC pada saat pelaksanaannya. DON kemudian dapat mengirim transaksi τ ′ yang menyetujui penarikan τ—tanpa mempengaruhi penarikan penuh pembaruan negara. Jika pendekatan ini tidak memungkinkan, atau jika tidak berhasil, DON akan memulai transaksi τ ′ dapat mengirimkan dana kepada pengguna sebagai respons terhadap τ sehingga pengguna tidak memerlukannya memulai transaksi tambahan. 6.3 Sinkronisasi Eksekusi TEF secara berkala mendorong pembaruan dari DON ke MAINCHAIN, memperbarui status SCa dalam proses yang kami sebut sebagai sinkronisasi. Sinkronisasi mungkin dipertimbangkan sebagai propagasi transaksi layer-2 ke layer-1, sehingga TEF dapat menggunakan nomor mana pun teknik yang ada untuk tujuan ini, termasuk rollups [5, 12, 16, 69], optimis rollups [10, 11, 141], Validium [201], atau penandatanganan ambang batas dasar, misalnya ambang batas BLS, Schnorr, atau ECDSA [24, 54, 116, 202]. Pada prinsipnya, lingkungan eksekusi tepercaya juga dapat membuktikan kebenaran perubahan keadaan, sehingga menawarkan kinerja yang jauh lebih baik alternatif untuk rollups, tetapi dengan model kepercayaan yang bergantung pada perangkat keras. (Lihat, misalnya, [80].) Di bawah ini kami membandingkan opsi sinkronisasi ini sehubungan dengan tiga properti utama di TEF: • Ketersediaan data: Di mana status SC disimpan? Setidaknya ada tiga pilihan tersedia dalam TEF: di MAINCHAIN, di DON, atau di penyimpanan pihak ketiga penyedia seperti IPFS. Mereka mencapai jaminan keamanan dan ketersediaan yang berbeda tingkat, dan profil kinerja. Singkatnya, menyimpan status di MAINCHAIN memungkinkan kemampuan audit on-chain dan menghilangkan ketergantungan pada pihak mana pun atas ketersediaan negara; di sisi lain, penyimpanan negara secara off-chain dapat mengurangi dan meningkatkan biaya penyimpanan throughput, dengan biaya mempercayai penyedia penyimpanan (DON atau pihak ketiga) untuk ketersediaan data. Tentu saja, model fleksibel yang menggabungkan opsi-opsi ini juga demikian mungkin. Kami menunjukkan bentuk ketersediaan data yang diperlukan pada Tabel 1.• Jaminan kebenaran: Bagaimana SCa memastikan kebenaran pembaruan didorong oleh exect? Hal ini mempengaruhi beban komputasi pada exect dan SCa dan menyinkronkan latensi (lihat di bawah). • Latensi: Latensi sinkronisasi memiliki tiga faktor yang berkontribusi: (1) Waktu yang dibutuhkan misalnya untuk menghasilkan transaksi sinkronisasi τsync; (2) Waktu yang dibutuhkan untuk sinkronisasi untuk dikonfirmasi di MAINCHAIN; dan (3) Waktu untuk τsync mulai berlaku SCa. Di TEF, latensi sangat penting untuk penarikan (tetapi kurang penting untuk penarikan transaksi dalam kontrak) karena penarikan memerlukan (setidaknya parsial) sinkronisasi status. Sinkronisasi pilihan Data ketersediaan kebenaran jaminan Latensi Gabungan [5, 12, 16, 69] dalam rantai Bukti validitas Waktu yang dibutuhkan untuk menghasilkan bukti validitas (misalnya, menit dalam sistem saat ini) Validium [201] Off-rantai Bukti validitas Sama seperti di atas Optimis rollup [10, 11, 141] dalam rantai Bukti penipuan Durasi tantangan periode (misalnya, hari atau minggu) Penandatanganan ambang batas [24, 54, 116, 202] Fleksibel Tanda tangan ambang batas oleh DON Seketika Lingkungan eksekusi tepercaya [80] Fleksibel Berbasis perangkat keras pengesahan Seketika Tabel 1: Berbagai opsi sinkronisasi di TEF dan propertinya. Tabel 1 merangkum properti ini dalam lima opsi sinkronisasi utama di TEF. (Catatan bahwa kami tidak bermaksud membandingkan teknologi ini sebagai penskalaan lapisan-2 yang berdiri sendiri solusi. Untuk itu kami merujuk pembaca ke misalnya, [121].) Sekarang kita membahas setiap opsi sinkronisasi. Rollup: rollup [69] adalah protokol di mana transisi keadaan dipengaruhi oleh a kumpulan transaksi dihitung secara off-chain. Perubahan keadaan kemudian disebarkan ke RANTAI UTAMA. Untuk mengimplementasikan rollups, jangkar smart contract SCa menyimpan representasi ringkas Rstate (misalnya akar Merkle) dari keadaan sebenarnya. Untuk menyinkronkan, exect mengirimkan τsync = (T, R′ state) ke SCa dimana T adalah himpunan transaksi yang diproses sejak terakhir kalisinkronisasi dan R′ negara bagian adalah representasi kompak dari negara bagian baru yang dihitung dengan menerapkan transaksi di T ke keadaan sebelumnya Rstate. Ada dua varian populer yang berbeda dalam cara SCa memverifikasi pembaruan status di τsync. Yang pertama, (zk-)rollups, melampirkan argumen kebenaran yang ringkas, terkadang disebut bukti validitas, untuk transisi Rstate →R′ negara bagian. Untuk mengimplementasikan varian ini, exect menghitung dan menyerahkan bukti validitas (misalnya, bukti zk-SNARK) bersama dengan τsync, membuktikan bahwa R′ keadaan adalah hasil penerapan T pada keadaan SCa saat ini. Jangkar kontrak menerima pembaruan negara hanya setelah memverifikasi buktinya. rollup yang optimis tidak menyertakan argumen kebenaran, tetapi memiliki staking dan menantang prosedur yang memfasilitasi verifikasi terdistribusi transisi negara. Untuk ini Varian rollup, SCa untuk sementara menerima τsync dengan asumsi itu benar (karenanya optimisme) tapi τsync tidak berlaku sampai setelah periode tantangan, di mana pihak mana pun pemantauan MAINCHAIN dapat mengidentifikasi pembaruan status yang salah dan memberi tahu SCa untuk mengambil tindakan tindakan yang diperlukan (misalnya, mengembalikan status dan memberikan penalti jika diperlukan.) Kedua varian rollup mencapai ketersediaan data on-chain, saat transaksi diposting on-chain, dari mana keadaan penuh dapat dibangun. Latensi zk-rollups adalah didominasi oleh waktu yang diperlukan untuk menghasilkan bukti validitas, yang biasanya ada di urutan menit dalam sistem yang ada [16] dan kemungkinan akan mengalami peningkatan seiring berjalannya waktu. Sebaliknya, rollup yang optimis memiliki latensi yang lebih tinggi (misalnya, hari atau minggu) karena periode tantangan harus cukup lama agar bukti penipuan dapat berfungsi. Itu Implikasi dari konfirmasi yang lambat tidak kentara dan terkadang bersifat spesifik terhadap skema tersebut analisis menyeluruh berada di luar cakupan. Misalnya, skema tertentu mempertimbangkan pembayaran transaksi sebagai “final tanpa kepercayaan” [109] sebelum pembaruan status dikonfirmasi, karena a pengguna biasa dapat memverifikasi rollup jauh lebih cepat daripada MAINCHAIN. Validium: Validium adalah bentuk (zk-)rollup yang membuat data hanya tersedia secara off-chain dan tidak menyimpan semua data di MAINCHAIN. Secara khusus, exect hanya mengirimkan yang baru sebutkan dan buktinya tetapi bukan transaksi ke SCa. Dengan sinkronisasi gaya Validium, jalankan dan DON yang menjalankannya adalah satu-satunya pihak yang menyimpan status lengkap dan yang mengeksekusi transaksi. Seperti zk-rollups, latensi sinkronisasi didominasi oleh validitas waktu pembuatan bukti. Namun, tidak seperti zk-rollups, sinkronisasi gaya Validium mengurangi biaya penyimpanan dan meningkatkan throughput. Penandatanganan ambang batas oleh DON: Dengan asumsi ambang batas DON node adalah jujur, a Opsi sinkronisasi yang sederhana dan cepat adalah dengan meminta DON node secara kolektif menandatangani status baru. Pendekatan ini dapat mendukung ketersediaan data on-chain dan off-chain. Perhatikan bahwa jika pengguna memercayai DON untuk oracle pembaruan, mereka tidak perlu lebih memercayainya untuk menerima pembaruan status, karena sudah berada dalam model kepercayaan ambang batas. Manfaat lain dari penandatanganan ambang batas adalah latensi rendah. Dukungan untuk format tanda tangan transaksi baru sebagai diusulkan di EIP-2938 [70] dan dikenal sebagai abstraksi akun akan membuat ambang batas penandatanganan jauh lebih mudah untuk diterapkan, karena akan menghilangkan kebutuhan akan ambang batas ECDSA, yang melibatkan protokol yang jauh lebih kompleks (misalnya, [116, 117, 118])daripada alternatif seperti ambang batas tanda tangan Schnorr [202] atau BLS [55]. Lingkungan Eksekusi Tepercaya (TEE): TEE adalah lingkungan eksekusi terisolasi (biasanya diwujudkan oleh perangkat keras) yang bertujuan untuk memberikan perlindungan keamanan yang kuat untuk program yang berjalan di dalam. Beberapa TEE (misalnya, Intel SGX [84]) dapat menghasilkan bukti, dikenal sebagai pengesahan, bahwa keluaran dihitung dengan benar oleh program tertentu masukan tertentu12. Varian sinkronisasi TEF berbasis TEE dapat diimplementasikan oleh mengganti bukti di (zk-)rollups atau Validium dengan pengesahan TEE menggunakan teknik dari [80]. Dibandingkan dengan bukti tanpa pengetahuan yang digunakan di rollups dan Validium, TEE jauh lebih berguna. lebih berkinerja. Dibandingkan dengan penandatanganan ambang batas, TEE menghilangkan kerumitan menghasilkan ambang batas tanda tangan ECDSA karena pada prinsipnya hanya diperlukan satu TEE terlibat. Namun, penggunaan TEEs menimbulkan asumsi kepercayaan ekstra yang bergantung pada perangkat keras. Kita juga dapat menggabungkan TEE dengan penandatanganan ambang batas untuk menciptakan ketahanan terhadap kompromi sebagian kecil dari contoh TEE, meskipun ini merupakan tindakan perlindungan memperkenalkan kembali kompleksitas pembuatan tanda tangan ECDSA ambang batas. Fleksibilitas tambahan: Opsi sinkronisasi ini dapat disempurnakan untuk memberikan lebih banyak fleksibilitas dengan cara berikut. • Pemicu yang fleksibel: Aplikasi TEF dapat menentukan kondisi di mana sinkronisasi dipicu. Misalnya, sinkronisasi dapat berbasis batch, misalnya terjadi setelahnya setiap N transaksi, berdasarkan waktu, misalnya setiap 10 blok, atau berdasarkan peristiwa, misalnya terjadi setiap kali harga aset target bergerak secara signifikan. • Sinkronisasi parsial: Hal ini dimungkinkan dan dalam beberapa kasus diinginkan (misalnya, dengan rollups, sinkronisasi parsial dapat mengurangi latensi) dengan tujuan menyediakan sinkronisasi cepat dalam skala kecil sejumlah negara, melakukan sinkronisasi penuh mungkin hanya secara berkala. Misalnya, exect dapat menyetujui permintaan penarikan dengan memperbarui saldo pengguna di SCa tanpa memperbarui status MAINCHAIN. 6.4 Reorganisasi Reorganisasi Blockchain akibat ketidakstabilan jaringan atau bahkan dari serangan 51%. dapat menimbulkan ancaman terhadap integritas rantai utama. Dalam praktiknya, musuh telah menggunakannya mereka untuk melakukan serangan pembelanjaan ganda [34]. Sementara serangan terhadap rantai besar memang demikian sulit untuk dipasang, namun tetap layak untuk beberapa rantai [88]. Karena beroperasi secara independen dari MAINCHAIN, DON menawarkan hal yang menarik kemungkinan untuk mengamati dan memberikan beberapa perlindungan terhadap reorg yang terkait dengan serangan. Misalnya, DON dapat melaporkan ke kontrak yang mengandalkan SC di MAINCHAIN mengenai keberadaan fork pesaing dengan panjang ambang batas tertentu τ. DON juga bisa 12Rincian tambahan dapat ditemukan di Lampiran B.2.1. Mereka tidak dituntut untuk memahami.
memberikan bukti—baik dalam pengaturan PoW atau PoS—tentang keberadaan fork tersebut. Itu kontrak SC dapat menerapkan tindakan defensif yang sesuai, seperti menangguhkan eksekusi transaksi lebih lanjut untuk jangka waktu tertentu (misalnya, mengizinkan bursa memasukkan pembelanjaan ganda ke dalam daftar hitam aset). Perhatikan bahwa meskipun musuh melancarkan serangan 51%, ia mungkin berupaya melakukan sensor laporan dari DON, tindakan penanggulangan di SC adalah dengan mewajibkan laporan berkala dari DON untuk memproses transaksi (yaitu detak jantung) atau memerlukan laporan baru ke memvalidasi transaksi bernilai tinggi. Meskipun peringatan forking tersebut pada prinsipnya merupakan layanan umum yang dapat diberikan oleh DON untuk beberapa tujuan, rencana kami adalah menggabungkannya dengan TEF.
Trust Minimization
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 effort is trust minimization: We seek to reduce the adverse effects 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 certificates on public keys that can in principle serve to sign data, but they do not generally use these certificates 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
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 efforts 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 certificates, 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 flexibility 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 benefit from the experience and tools developed by the Chainlink community in adding digital signing capabilities to their existing suite of off-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 sufficient 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: • Confidentiality: 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 modification 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 affect 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 confidentiality of source data and to combine data from multiple sources securely. 7.1.2 Confidentiality Data sources may not anticipate and make available the full gamut of APIs desired by users. Specifically, users may wish to access pre-processed data to help ensure confidentiality. 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 sufficient 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 specification 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 specification G(X) to ensure that A′ is correctly interpreted. In the above example, G(X) defines the meaning of the Boolean value in A′ and thus that True signifies the subject of the attestation is over 18 years of age. We refer to flexible 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-specific 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]. Briefly, 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 sufficiently concise. For computationally intensive jobs where DON participants may have differing 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 final 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 identifies 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 configurations 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 diversification, 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 benefits it offers. 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 diversification. Failover clients do not increase the number of potential vectors of attack, as they are not deployed as mainline software. They offer clear benefits, 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 Off-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 field 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 sufficiently 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 flag, relayed to a dependent contract SC on-chain by \(O_{\text{minority}}\). SC can make use of this flag according to its own contract-specific 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 five sources report a price of \(500, while the other five 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 flag statistically significant 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 identified 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 buffer 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 off-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 flavor and complementary to the mechanisms we enumerate above. They too provide a form of on-chain monitoring and protection against potential failures in off-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 modification. We foresee two classes of governance mechanisms: evolutionary and emergency. Evolutionary governance: Many modifications 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 ratified by the community of a specific DON affected 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 differs 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 flexible 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 identification 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—specifically, through a digital signature in a so-called certificate. A hierarchical system of certificate authorities (CAs), whose toplevel root authorities are hardwired into popular browsers, helps ensure that certificates 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 difficult as tampering with the contract administering it and/or the underlying blockchain. (DNS, in contrast, has historically been vulnerable to spoofing, 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 off-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 benefits unavailable in off-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 notifications 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 effectively 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 certificates 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 final 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 specifies 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.
Minimisasi Kepercayaan
Sebagai sistem yang terdesentralisasi dengan partisipasi dari berbagai entitas yang heterogen, Jaringan Chainlink memberikan perlindungan yang kuat terhadap kegagalan dalam keaktifan (ketersediaan) dan keamanan (integritas laporan). Namun, sebagian besar sistem desentralisasi memiliki perbedaan sejauh mana komponen-komponen penyusunnya terdesentralisasi. Ini Hal ini berlaku bahkan pada sistem yang besar, dimana desentralisasi terbatas di kalangan penambang [32] dan perantara [51] telah lama hadir. Tujuan dari setiap upaya desentralisasi adalah minimalisasi kepercayaan: Kami berupaya untuk mengurangi dampak buruk dari korupsi atau kegagalan sistemik dalam jaringan Chainlink, meskipun demikian karena DON yang berbahaya. Prinsip panduan kami adalah Prinsip Hak Istimewa Terkecil [197]. Komponen sistem dan aktor dalam sistem harus memiliki hak istimewa yang dibatasi secara ketat untuk memungkinkan hanya keberhasilan penyelesaian peran yang ditugaskan kepada mereka. Di sini kami memaparkan beberapa mekanisme konkret yang dapat diterapkan oleh Chainlink dalam upayanya menuju minimalisasi kepercayaan yang semakin besar. Kami mengkarakterisasi mekanisme ini dalam istilah dari lokus, yaitu komponen sistem, di mana mereka di-root, ditunjukkan pada Gambar. 14. Kita alamat setiap lokus dalam subbagian masing-masing. 7.1 Otentikasi Sumber Data Model operasi saat ini untuk oracles dibatasi oleh fakta bahwa sedikit sumber data menandatangani secara digital data yang mereka hilangkan, sebagian besar karena TLS tidak menandatangani secara asli data. TLS memang menggunakan tanda tangan digital dalam protokol “jabat tangan” (untuk menetapkan kunci bersama antara server dan klien). Server yang mendukung HTTPS memiliki sertifikat pada kunci publik yang pada prinsipnya dapat berfungsi untuk menandatangani data, tetapi umumnya tidak digunakan sertifikat ini untuk mendukung penandatanganan data. Akibatnya, keamanan DON, sebagai di jaringan oracle saat ini, bergantung pada oracle node yang setia menyampaikan data dari suatu data sumber kontrak. Komponen penting jangka panjang dari visi kami untuk meminimalkan kepercayaan di Chainlink melibatkan autentikasi sumber data yang lebih kuat melalui dukungan alat dan standar untuk penandatanganan data. Penandatanganan data dapat membantu menegakkan jaminan integritas menyeluruh. Pada prinsipnya, jika suatu kontrak menerima sebagai masukan sepotong data D yang ditandatangani langsung oleh suatu data
Gambar 14: Lokasi mekanisme minimalisasi kepercayaan yang dibahas pada bagian ini. 1⃝Data sumber menyediakan data ke 2⃝DON, yang menyampaikan fungsi data ke dependen 3⃝smart contract. Selain itu, jaringan DON atau oracle mencakup 4⃝node manajemen smart contracts di MAINCHAIN untuk, misalnya, node kompensasi, penjaga rel, dan sebagainya. sumber, maka jaringan oracle tidak dapat diutak-atik D. Berbagai hal yang menggembirakan upaya untuk memungkinkan penandatanganan data telah muncul, termasuk OpenID Connect, yang dirancang terutama untuk otentikasi pengguna [9], TLS-N, sebuah proyek akademis yang bertujuan untuk itu memperpanjang TLS [191] dengan menggunakan kembali sertifikat TLS, dan Ekstensi Bukti TLS [63]. Meskipun OpenID Connect telah melihat beberapa adopsi, TLS Evidence Extensions dan TLS-N belum diadopsi. Cara potensial lain untuk autentikasi sumber data adalah dengan menggunakan milik penerbit Pertukaran HTTP yang ditandatangani (SXG) [230], yang dapat disimpan dalam cache di jaringan pengiriman konten sebagai bagian dari protokol Accelerated Mobile Pages (AMP) [225]. Browser seluler Chrome menampilkan konten dari SXG yang di-cache AMP seolah-olah konten tersebut disajikan domain jaringan milik penerbitnya, bukan domain server cache. Insentif pencitraan merek ini, ditambah dengan relatif mudahnya mengaktifkannya menggunakan layanan seperti URL Asli CloudFlare [83] dan amppackager Google [124], dapat menyebabkan penerapan SXG secara luas dalam konten berita yang di-cache, yang akan memungkinkan sistem yang sederhana dan tahan terhadap gangguan. cara bagi Chainlink oracles untuk memicu peristiwa yang layak diberitakan yang dilaporkan di SXG yang valid. Meskipun SXG yang di-cache AMP dari penerbit berita tidak akan berguna untuk tempo tinggi aplikasi seperti laporan data perdagangan, mereka bisa menjadi sumber yang aman untuk kustom kontrak yang berkaitan dengan peristiwa dunia nyata seperti cuaca ekstrem atau hasil pemilu. Kami percaya bahwa penerapan yang sederhana, alat yang matang, dan fleksibilitas akan sangat penting mempercepat penandatanganan sumber data. Mengaktifkan penyedia data untuk menggunakan Chainlink node sebagai front end API yang diautentikasi tampaknya merupakan pendekatan yang menjanjikan. Kami bermaksud untuk membuatpilihan bagi node untuk berfungsi dalam mode ini, dengan atau tanpa partisipasi dalam jaringan sebagai oracle sepenuhnya. Kami menyebut kemampuan ini sebagai asal data yang diautentikasi (LALU). Dengan menggunakan Chainlink node dengan ADO, sumber data akan mendapatkan keuntungan dari pengalaman dan alat yang dikembangkan komunitas Chainlink dalam menambahkan digital kemampuan penandatanganan ke rangkaian API off-chain yang ada. Haruskah mereka memilih lari node mereka sebagai oracles, mereka juga dapat membuka potensi aliran pendapatan baru dengan model yang sama dengan penyedia data yang ada, misalnya Kraken [28], Kaiko [140], dan lainnya, yang menjalankan Chainlink node untuk menjual data API secara berantai. 7.1.1 Keterbatasan Asal Data yang Diautentikasi Penandatanganan digital oleh sumber data, meskipun dapat membantu memperkuat autentikasi, tidaklah cukup untuk mencapai semua tujuan keamanan alami atau operasional dari oracle jaringan. Untuk memulainya, bagian data D tertentu masih harus disampaikan secara kuat dan tepat waktu cara dari sumber data ke smart contract atau konsumen data lainnya. Artinya, bahkan di dalam pengaturan ideal di mana semua data ditandatangani menggunakan kunci yang telah diprogram menjadi dependen kontrak, DON masih diperlukan untuk mengomunikasikan data secara andal dari sumber untuk kontrak. Selain itu, ada sejumlah kasus di mana kontrak atau oracle-data lainnya konsumen menginginkan akses ke keluaran terotentikasi dari berbagai fungsi yang dihitung sumber data karena dua alasan utama: • Kerahasiaan: API sumber data mungkin menyediakan data sensitif atau kepemilikan yang perlu disunting atau dibersihkan sebelum dapat dilihat publik secara berantai. Namun, modifikasi apa pun pada data yang ditandatangani akan membuat tanda tangan menjadi tidak valid. Letakkan yang lain cara, ADO naif dan sanitasi data tidak kompatibel. Kami tunjukkan pada Contoh 3 bagaimana keduanya dapat didamaikan melalui bentuk ADO yang ditingkatkan. • Kesalahan sumber data: Kesalahan dan kegagalan dapat mempengaruhi sumber data, dan tanda tangan digital tidak mengatasi masalah tersebut. Sejak awal [98], Chainlink telah sudah mencakup mekanisme untuk memperbaiki kesalahan tersebut: redundansi. Laporan yang dikeluarkan oleh jaringan oracle biasanya mewakili gabungan beberapa data sumber. Kami sekarang mendiskusikan skema yang sedang kami eksplorasi dalam pengaturan ADO untuk meningkatkan kerahasiaan sumber data dan menggabungkan data dari berbagai sumber dengan aman. 7.1.2 Kerahasiaan Sumber data mungkin tidak mengantisipasi dan menyediakan keseluruhan API yang diinginkan oleh pengguna. Secara khusus, pengguna mungkin ingin mengakses data yang telah diproses sebelumnya untuk membantu memastikan kerahasiaan. Contoh berikut menggambarkan masalahnya.Contoh 3. Alice ingin mendapatkan pernyataan kredensial identitas terdesentralisasi (DID). bahwa dia berusia di atas 18 tahun (dan dengan demikian, misalnya, dapat mengambil pinjaman). Untuk melakukan jadi, dia perlu membuktikan fakta tentang usianya kepada penerbit kredensial DID. Alice berharap dapat menggunakan data dari Departemen Kendaraan Bermotor (DMV) negara bagiannya situs web untuk tujuan tersebut. DMV memiliki catatan tanggal lahirnya dan akan mengeluarkan a pengesahan A yang ditandatangani secara digital dengan bentuk sebagai berikut: A = {Nama: Alice, DoB: 16/02/1999}. Dalam contoh ini, pengesahan A mungkin cukup bagi Alice untuk membuktikan DID penerbit kredensial bahwa dia berusia di atas 18 tahun. Tapi itu tidak perlu membocorkan informasi sensitif: milik Alice DoB yang tepat. Idealnya, yang diinginkan Alice dari DMV adalah tanda tangan di a pernyataan sederhana A′ bahwa “Alice berusia di atas 18 tahun.” Dengan kata lain, dia menginginkannya keluaran suatu fungsi G pada tanggal lahirnya X, dimana (secara informal), A′ = G(X) = Benar jika Tanggal Saat Ini −X ≥18 tahun; jika tidak, G(X) = Salah. Untuk menggeneralisasi, Alice ingin dapat meminta tanda tangan dari sumber data pengesahan A′ dalam bentuk: A′ = {Nama: Alice, Fungsi:G(X), Hasil: Benar}, di mana G(X) menunjukkan spesifikasi fungsi G dan masukannya X. Kita bayangkan bahwa pengguna harus dapat memberikan G(X) yang diinginkan sebagai masukan dengan permintaannya untuk a pengesahan yang sesuai A′. Perhatikan bahwa pengesahan sumber data A′ harus menyertakan spesifikasi G(X) hingga memastikan bahwa A′ ditafsirkan dengan benar. Dalam contoh di atas, G(X) mendefinisikan maknanya dari nilai Boolean dalam A′ dan dengan demikian True menandakan subjek pengesahan berusia di atas 18 tahun. Kami mengacu pada kueri fleksibel di mana pengguna dapat menentukan G(X) sebagai kueri fungsional. Untuk mendukung kasus penggunaan seperti itu di Contoh 3, serta yang melibatkan kueri langsung dari kontrak, kami bermaksud menyertakan dukungan untuk pertanyaan fungsional yang melibatkan fungsi sederhana G sebagai bagian dari ADO. 7.1.3 Menggabungkan Data Sumber Untuk mengurangi biaya on-chain, kontrak umumnya dirancang untuk menggunakan data gabungan dari berbagai sumber, seperti yang diilustrasikan pada contoh berikut. Contoh 4 (Medianisasi data harga). Untuk memberikan umpan harga, yaitu nilai satu aset (misalnya, ETH) sehubungan dengan yang lain (misalnya, USD), jaringan oracle umumnya akan memperoleh harga saat ini dari sejumlah sumber, seperti bursa. Jaringan oracle biasanya mengirimkan ke kontrak dependen SC median dari nilai-nilai ini. Dalam lingkungan dengan penandatanganan data, jaringan oracle yang berfungsi dengan benar diperoleh dari sumber data S = {S1, . . . , SnS} barisan nilai V = {v1, v2, . . . , vnS} dari nS sumber dengan tanda tangan spesifik sumber yang menyertainya Σ = {σ1, σ2, . . . , σnS}. Setelah memverifikasi tanda tangan, ia mengirimkan harga v = median(V ) ke SC.Sayangnya, tidak ada cara sederhana bagi jaringan oracle untuk mengirimkan median nilai v dalam Contoh 4 hingga SC bersama dengan bukti singkat σ∗bahwa v dihitung dengan benar atas input yang ditandatangani. Pendekatan yang naif adalah dengan menyandikan kunci publik semua sumber data nS di SC. Jaringan oracle kemudian akan menyampaikan (V, Σ) dan memungkinkan SC menghitung median V . Namun hal ini akan menghasilkan bukti σ dengan ukuran O(nS)—yakni, σ∗tidak akan ringkas. Hal ini juga akan menimbulkan biaya bahan bakar yang tinggi bagi SC, yang harus memverifikasi semua tanda tangan di dalamnya Σ. Sebaliknya, penggunaan SNARK memungkinkan bukti ringkas tentang kombinasi nilai sumber yang diautentikasi dengan benar. Ini mungkin bisa dilakukan dalam praktiknya, tetapi bebannya cukup tinggi biaya komputasi pada peribahasa, dan biaya bahan bakar yang agak tinggi pada rantai. Penggunaan Town Crier juga merupakan suatu kemungkinan, namun membutuhkan penggunaan TEE, yang tidak cocok untuk semua orang model kepercayaan pengguna. Konsep yang berguna untuk menyusun solusi terhadap masalah umum penandatanganan data gabungan dari sumber adalah alat kriptografi yang dikenal sebagai tanda tangan fungsional [59, 132]. Singkatnya, tanda tangan fungsional memungkinkan penandatangan untuk mendelegasikan kemampuan penandatanganan, sedemikian rupa penerima delegasi hanya dapat menandatangani pesan dalam rentang fungsi F yang dipilih oleh penandatangan. Kami tunjukkan di Lampiran D bagaimana batasan fungsional ini dapat berfungsi untuk membatasi rentang nilai laporan yang dikeluarkan oleh DON sebagai fungsi dari nilai yang ditandatangani oleh sumber data. Kami juga memperkenalkan primitif baru, yang disebut tanda tangan fungsional terdiskritisasi, yang mencakup persyaratan akurasi yang lebih longgar, namun berpotensi jauh lebih berkinerja. daripada pendekatan seperti SNARK. Masalah menggabungkan sumber data dengan cara yang mencakup otentikasi sumber keluaran juga berlaku untuk agregator data, misalnya, CoinCap, CoinMarketCap, CoinGecko, CryptoCompare, dll., yang memperoleh data dari berbagai bursa, yaitu mereka bobot berdasarkan volume, menggunakan metodologi yang dalam beberapa kasus dipublikasikan dan dalam kasus lain merupakan hak milik. Agregator yang ingin mempublikasikan nilai dengan otentikasi sumber menghadapi tantangan yang sama dengan kumpulan node yang digabungkan sumber data. 7.1.4 Pengolahan Data Sumber smart contract yang canggih cenderung bergantung pada statistik agregat khusus sumber data primer, seperti volatilitas dalam riwayat harga terkini pada banyak aset, atau teks dan foto dari berita tentang peristiwa terkait. Karena komputasi dan bandwidth relatif murah dalam DON, statistik ini— bahkan model pembelajaran mesin yang kompleks dengan banyak masukan—dapat diproses secara ekonomis, selama nilai keluaran apa pun yang ditujukan untuk blockchain cukup ringkas. Untuk pekerjaan yang intensif secara komputasi di mana DON pesertanya mungkin berbeda pandangan mengenai masukan yang kompleks, putaran komunikasi ekstra antara peserta DON mungkin diperlukan untuk menetapkan konsensus mengenai masukan sebelum menghitung hasilnya. Selama nilai akhir sepenuhnya ditentukan oleh masukan, setelah konsensus masukan tercapai, masing-masing pihak dapat dengan mudah menghitung nilainya dan menyebarkannya ke pihak lain.peserta dengan sebagian tanda tangan mereka, atau mengirimkannya ke agregator. 7.2 DON Minimisasi Kepercayaan Kami membayangkan dua cara utama untuk meminimalkan kepercayaan yang diberikan pada komponen DON: klien failover dan laporan minoritas. 7.2.1 Klien Kegagalan Model permusuhan dalam literatur kriptografi dan sistem terdistribusi biasanya pertimbangkan musuh yang mampu merusak (yaitu, membahayakan) subset node, misalnya, kurang dari sepertiga untuk banyak protokol BFT. Namun hal ini umumnya diamati, bahwa jika semua node menjalankan perangkat lunak yang sama, musuh yang mengidentifikasi eksploitasi fatal dapat melakukannya pada prinsipnya mengkompromikan semua node secara bersamaan. Pengaturan ini sering terjadi disebut sebagai monokultur perangkat lunak [47]. Berbagai usulan untuk mendiversifikasi perangkat lunak dan konfigurasi perangkat lunak secara otomatis telah diajukan untuk mengatasi masalah ini, misalnya, [47, 113]. Seperti disebutkan dalam [47], namun, keragaman perangkat lunak adalah masalah yang kompleks dan memerlukan pertimbangan yang cermat. Diversifikasi perangkat lunak, misalnya, dapat menghasilkan keamanan yang lebih buruk dibandingkan monokultur meningkatkan permukaan serangan sistem dan dengan demikian kemungkinan vektor serangannya melebihi manfaat keamanan yang ditawarkannya. Kami percaya bahwa dukungan untuk klien failover yang kuat—yaitu klien ke node mana dapat beralih ketika menghadapi peristiwa bencana—merupakan bentuk yang sangat menarik diversifikasi perangkat lunak. Klien failover tidak menambah jumlah vektor potensial serangan, karena mereka tidak digunakan sebagai perangkat lunak arus utama. Mereka menawarkan manfaat yang jelas, namun, sebagai garis pertahanan kedua. Kami bermaksud untuk mendukung klien failover dalam DONs sebagai cara utama untuk mengurangi ketergantungan mereka akan keamanan pada satu klien. Chainlink sudah memiliki sistem klien failover yang kuat. Pendekatan kami melibatkan pemeliharaan versi klien sebelumnya yang telah teruji pertempuran. Saat ini, misalnya, Chainlink node dengan Off-Chain Reporting (OCR) sebagai klien utamanya menyertakan dukungan untuk sistem FluxMonitor Chainlink sebelumnya jika diperlukan. Telah digunakan untuk beberapa orang kali ini, FluxMonitor telah menerima audit keamanan dan pengujian lapangan. Ini memberikan hal yang sama fungsionalitas seperti OCR, hanya dengan biaya lebih tinggi—biaya hanya dikeluarkan berdasarkan kebutuhan. 7.2.2 Laporan Minoritas Mengingat jumlah kelompok minoritas yang cukup besar Ominoritas—sebagian kecil dari simpul jujur yang mengamati penyimpangan yang dilakukan oleh mayoritas—akan bermanfaat jika kelompok tersebut menghasilkan minoritas laporan. Ini adalah laporan atau tanda paralel, yang diteruskan ke kontrak SC on-chain yang bergantung oleh Ominoritas. SC dapat menggunakan bendera ini sesuai dengan kebijakan khusus kontraknya sendiri. Misalnya, untuk kontrak yang mengutamakan keselamatan daripada keaktifan atau daya tanggap, laporan minoritas mungkin menyebabkan kontrak meminta laporan tambahan. dari DON lain, atau memicu pemutus arus (lihat bagian selanjutnya).Laporan dari kelompok minoritas dapat memainkan peranan penting bahkan ketika kelompok mayoritas jujur, karena skema agregasi laporan apa pun, meskipun menggunakan tanda tangan fungsional, harus dilakukan beroperasi dengan cara ambang batas, untuk memastikan ketahanan terhadap oracle atau kegagalan data. Di dengan kata lain, laporan yang valid harus dapat dihasilkan berdasarkan masukan dari kS < nS oracles, untuk beberapa ambang batas kS. Ini berarti DON yang rusak memiliki beberapa kebebasan dalam memanipulasi nilai laporan dengan memilih nilai kS yang diinginkan di antara nilai-nilai tersebut nS dilaporkan dalam V dengan set lengkap oracles, meskipun semua sumber jujur. Misalnya nS = 10 dan kS = 7 dalam sistem yang menggunakan fungsional tanda tangan untuk mengautentikasi perhitungan median di atas V untuk harga USD ETH. Misalkan lima sumber melaporkan harga \(500, while the other five report \)1000. Kemudian dengan memediasi 7 laporan terendah, DON dapat menghasilkan nilai valid v = $500, dan dengan memediasi nilai tertinggi, ia dapat menghasilkan v = $1000. Dengan menyempurnakan protokol DON sehingga semua node mengetahui data mana yang berada tersedia, dan data mana yang digunakan untuk membuat laporan, node dapat mendeteksi dan menandainya kecenderungan yang signifikan secara statistik untuk lebih menyukai satu set laporan dibandingkan yang lain, dan menghasilkan sebagai hasilnya, laporan minoritas. 7.3 Rel Penjaga Model kepercayaan kami untuk DONs memperlakukan MAINCHAIN sebagai keamanan yang lebih tinggi, hak istimewa yang lebih tinggi sistem dari DONs. (Meskipun model kepercayaan ini mungkin tidak selalu benar, model ini lebih mudah untuk mengadaptasi mekanisme yang dihasilkan pada situasi di mana DON adalah keamanan yang lebih tinggi platform daripada sebaliknya.) Oleh karena itu, strategi minimalisasi kepercayaan yang alami melibatkan penerapan mekanisme pemantauan dan pengamanan kegagalan di smart contracts—baik di front end MAINCHAIN untuk DON atau langsung dalam kontrak tanggungan SC. Kami menyebut mekanisme ini sebagai pagar pengaman, dan sebutkan beberapa hal terpenting di sini: • Pemutus sirkuit: SC dapat menjeda atau menghentikan pembaruan status sebagai fungsi dari salah satu karakteristik pembaruan status itu sendiri (misalnya, varian besar di seluruh sekuensial laporan) atau berdasarkan masukan lainnya. Misalnya, pemutus arus mungkin tersandung kasus di mana laporan oracle sangat bervariasi dari waktu ke waktu. Pemutus arus mungkin juga tersandung oleh laporan minoritas. Dengan demikian, pemutus sirkuit dapat mencegah DONs dari membuat laporan yang sangat salah. Pemutus sirkuit dapat memberikan waktu untuk mempertimbangkan intervensi tambahan atau dilatih. Salah satu intervensi tersebut adalah pintu keluar darurat. • Pintu keluar untuk melarikan diri: Dalam keadaan yang merugikan, seperti yang diidentifikasi oleh sekelompok penjaga, pemegang token komunitas, atau badan pengawas lainnya, sebuah kontrak dapat diperlukan fasilitas darurat terkadang disebut pintu keluar darurat [163]. Sebuah pintu keluar menyebabkan SC dimatikan dengan cara tertentu dan/atau berakhir tertunda dan mungkin transaksi masa depan. Misalnya, ia dapat mengembalikan dana yang disimpan kepada pengguna [17]),dapat mengakhiri ketentuan kontrak [162], atau dapat membatalkan transaksi yang tertunda dan/atau di masa depan [173]. Escape hatch dapat digunakan dalam semua jenis kontrak, tidak hanya salah satu yang bergantung pada DON, namun menarik sebagai penyangga potensial terhadap DON penyimpangan. • Failover: Dalam sistem di mana SC bergantung pada DON untuk layanan penting, SC dapat menyediakan mekanisme failover yang memastikan kelanjutan layanan bahkan dalam kasus DON kegagalan atau perilaku buruk. Misalnya, dalam TEF (Bagian 6), kontrak jangkar SCa dapat menyediakan antarmuka ganda di mana keduanya on-chain dan antarmuka eksekusi off-chain didukung untuk operasi penting tertentu (misalnya, penarikan), atau untuk transaksi biasa, dengan penundaan yang sesuai untuk mencegah DON transaksi berjalan di muka. Jika sumber data menandatangani data, pengguna dapat melakukannya juga memberikan laporan kepada SCa ketika DON gagal melakukannya. Bukti penipuan, seperti yang diusulkan untuk berbagai bentuk rollup optimis (lihat Bagian 6.3), memiliki rasa yang serupa dan saling melengkapi dengan mekanisme yang kami sebutkan di atas. Mereka juga menyediakan bentuk pemantauan dan perlindungan on-chain terhadap potensi kegagalan komponen sistem off-chain. 7.4 Tata Kelola yang Meminimalkan Kepercayaan Seperti semua sistem desentralisasi, jaringan Chainlink memerlukan mekanisme tata kelola untuk menyesuaikan parameter dari waktu ke waktu, merespons keadaan darurat, dan memandu evolusinya. Beberapa dari mekanisme ini saat ini berada di MAINCHAIN, dan mungkin akan terus berlanjut melakukannya bahkan dengan penerapan DONs. Salah satu contohnya adalah mekanisme pembayaran untuk oracle penyedia node (DON node). DON kontrak ujung depan di MAINCHAIN mengandung mekanisme tambahan, seperti rel pengaman, yang mungkin dikenakan secara berkala modifikasi. Kami memperkirakan ada dua jenis mekanisme tata kelola: evolusioner dan darurat. Tata kelola yang evolusioner: Banyak modifikasi pada ekosistem Chainlink adalah sedemikian rupa sehingga implementasinya tidak menjadi hal yang mendesak: Peningkatan kinerja, peningkatan fitur, peningkatan keamanan (tidak mendesak), dan sebagainya. Seiring dengan semakin banyaknya Chainlink yang bergerak ke arah lebih banyak peserta dalam tata kelolanya, kami memperkirakan akan banyak atau sebagian besar perubahan tersebut harus diratifikasi oleh komunitas tertentu DON yang terkena dampak oleh mereka perubahan. Untuk sementara, dan mungkin pada akhirnya sebagai mekanisme paralel, kami yakin bahwa gagasan tentang hak istimewa yang paling tidak bersifat sementara dapat menjadi sarana yang berguna dalam menerapkan tata kelola yang evolusioner. Sederhananya, idenya adalah agar perubahan diterapkan secara bertahap dan memastikan masyarakat mempunyai kesempatan untuk menanggapinya. Misalnya saja migrasi ke tempat baru Kontrak MAINCHAIN dapat dibatasi sehingga kontrak baru harus diterapkan setidaknya tiga puluh hari sebelum aktivasi.Tata kelola darurat: Kerentanan yang dapat dieksploitasi atau dieksploitasi di MAINCHAIN kontrak atau bentuk kegagalan kelangsungan hidup atau keselamatan lainnya mungkin memerlukan intervensi segera untuk memastikan dampak buruknya. Tujuan kami adalah untuk mendukung multisig mekanisme intervensi di mana, untuk memastikan terhadap penyimpangan yang dilakukan oleh organisasi mana pun, penandatangan akan tersebar di seluruh organisasi. Memastikan ketersediaan penanda tangan yang konsisten dan akses tepat waktu ke rantai komando yang sesuai untuk otorisasi keadaan darurat perubahan jelas memerlukan perencanaan operasional yang cermat dan peninjauan rutin. Ini tantangannya serupa dengan tantangan yang terlibat dalam pengujian respons insiden keamanan siber lainnya kemampuan [134], dengan kebutuhan serupa untuk mengatasi masalah umum seperti penurunan kewaspadaan [223]. Tata kelola DON berbeda dengan sistem desentralisasi pada umumnya tingkat potensi heterogenitas. Setiap DON mungkin memiliki sumber data, executable, persyaratan tingkat layanan yang berbeda seperti waktu aktif, dan pengguna. Jaringan Chainlink mekanisme tata kelola harus cukup fleksibel untuk mengakomodasi variasi tersebut tujuan dan parameter operasional. Kami secara aktif mengeksplorasi ide-ide desain dan merencanakannya mempublikasikan penelitian tentang topik ini di masa depan. 7.5 Infrastruktur Kunci Publik Dengan desentralisasi yang progresif maka diperlukan identifikasi yang kuat mengenai hal ini peserta jaringan, termasuk DON node. Secara khusus, Chainlink membutuhkan yang kuat Infrastruktur Kunci Publik (PKI). PKI adalah sistem yang mengikat kunci identitas. Untuk Misalnya, PKI mendasari sistem koneksi aman (TLS) Internet: Kapan Anda terhubung ke situs web melalui HTTPS (mis., https://www.chainlinklabs.com) dan a kunci muncul di browser Anda, itu berarti kunci publik pemilik domain memilikinya telah terikat pada pemiliknya oleh suatu otoritas—khususnya, melalui tanda tangan digital yang disebut sertifikat. Sistem hierarki otoritas sertifikat (CA), yang otoritas akar tingkat atasnya tertanam dalam browser populer, membantu memastikan bahwa sertifikat dikeluarkan hanya untuk pemilik sah domain. Kami berharap Chainlink pada akhirnya akan menggunakan layanan nama yang terdesentralisasi, awalnya Ethereum Name Service (ENS) [22], sebagai landasan PKI kita. Sebagai Sesuai dengan namanya, ENS dianalogikan dengan DNS, Domain Name System yang memetakan (dapat dibaca manusia) nama domain ke alamat IP di internet. Namun, ENS malah memetakan nama Ethereum yang dapat dibaca manusia ke alamat blockchain. Karena ENS beroperasi pada Ethereum blockchain, kecuali kompromi utama, merusaknya namespace pada prinsipnya sama sulitnya dengan merusak kontrak yang mengelolanya dan/atau blockchain yang mendasarinya. (DNS, sebaliknya, secara historis rentan untuk spoofing, pembajakan, dan serangan lainnya.) Kami telah mendaftarkan data.eth dengan ENS di mainnet Ethereum, dan bermaksud untuk melakukannya menetapkannya sebagai namespace root di mana identitas layanan data oracle dan entitas jaringan Chainlink lainnya berada. Domain di ENS bersifat hierarkis, artinya setiap domain dapat berisi referensi ke nama lain di bawahnya. Subdomain di ENS dapat berfungsi sebagai cara untuk mengatur danmendelegasikan kepercayaan. Peran utama data.eth adalah sebagai layanan direktori on-chain umpan data. Secara tradisional, pengembang dan pengguna oracles telah menggunakan sumber off-chain (misalnya, situs web seperti docs.chain.link atau data.chain.link, atau jejaring sosial seperti Twitter) untuk mempublikasikan dan mendapatkan oracle alamat data feed (seperti harga ETH-USD pakan). Dengan namespace root yang sangat tepercaya seperti data.eth, dimungkinkan untuk membuat pemetaan eth-usd.data.eth ke, misalnya, alamat smart contract dari agregator jaringan oracle on-chain untuk umpan harga ETH-USD. Ini akan terjadi buat jalur aman bagi siapa pun untuk merujuk ke blockchain sebagai sumber kebenaran umpan data dari pasangan harga/nama tersebut (ETH-USD). Konsekuensinya, penggunaan ENS seperti itu menyadari dua manfaat yang tidak tersedia di sumber data off-chain: • Keamanan yang kuat: Semua perubahan dan pembaruan pada domain dicatat secara permanen dan diamankan secara kriptografis, bukan alamat teks di situs web, yang mana tidak menikmati satu pun dari dua properti keamanan ini. • Propagasi on-chain otomatis: Pembaruan pada alamat dasar smart contract datafeed dapat memicu notifikasi yang disebarkan ke smart dependen kontrak dan dapat, misalnya, secara otomatis memperbarui kontrak yang bergantung padanya alamat baru.13 Namun, namespace seperti ENS tidak secara otomatis memvalidasi kepemilikan sah dari nama-nama yang ditegaskan. Jadi, misalnya, jika namespace menyertakan entri ⟨“Acme Oracle Node Co.”, tambahan⟩, kemudian pengguna memperoleh jaminan bahwa addr adalah milik penggugat nama Acme Oracle Node Co. Tanpa mekanisme tambahan seputar administrasi namespace, namun, ia tidak memperoleh jaminan bahwa nama tersebut adalah milik suatu entitas secara sah disebut Acme Oracle Node Co. dalam arti dunia nyata yang bermakna. Pendekatan kami terhadap validasi nama, yaitu memastikan kepemilikannya oleh entitas yang sesuai dan sah di dunia nyata, bergantung pada beberapa komponen. Hari ini, Chainlink Lab secara efektif bertindak sebagai CA untuk jaringan Chainlink. Sementara Chainlink Lab akan dilanjutkan untuk memvalidasi nama, PKI kita akan berkembang menjadi model yang lebih terdesentralisasi melalui dua cara: • Model web-of-trust: Model desentralisasi dari PKI yang hierarkis sering disebut sebagai web-of-trust.14 Varian-varian telah diusulkan sejak tahun 1990-an, misalnya, [98], dan sejumlah peneliti telah mengamati bahwa blockchains dapat memfasilitasi penggunaan gagasan tersebut, misalnya, [227] dengan mencatat sertifikat dalam sistem yang konsisten secara global buku besar. Kami sedang menjajaki varian model ini untuk memvalidasi identitas entitas di jaringan Chainlink dengan cara yang lebih terdesentralisasi. 13Kontrak yang bergantung secara opsional dapat mencakup penundaan yang telah ditentukan sebelumnya untuk memungkinkan inspeksi manual dan intervensi oleh administrator kontrak yang bergantung. 14Istilah yang diciptakan oleh Phil Zimmermann untuk PGP [238].• Tautan ke validasi data: Saat ini, sejumlah besar oracle data kinerja node terlihat secara on-chain, dan dengan demikian terikat secara arsip ke alamat node. Data tersebut dapat dipandang memperkaya identitas PKI dengan memberikan bukti sejarah partisipasinya (yang dapat diandalkan) dalam jaringan tersebut. Selain itu, alat untuk identitas terdesentralisasi berdasarkan node pengaktif DECO dan Town Crier [160] untuk mengumpulkan kredensial yang berasal dari data dunia nyata. Sebagai salah satu contoh saja, a operator node dapat melampirkan kredensial ke identitas PKI-nya yang membuktikan kepemilikan dari peringkat Dun dan Bradstreet. Bentuk validasi tambahan ini bisa suplemen staking dalam menciptakan jaminan keamanan jaringan. Node oracle dengan identitas dunia nyata yang mapan dapat dianggap memiliki kepentingan dalam suatu sistem yang berasal dari reputasinya. (Lihat Bagian 4.3 dan Bagian 9.6.3.) Persyaratan terakhir untuk Chainlink PKI adalah bootstrapping yang aman, yaitu, aman menerbitkan nama root untuk jaringan Chainlink, saat ini data.eth (secara analog untuk memasang kabel domain tingkat atas di browser). Dengan kata lain, bagaimana Chainlink pengguna tentukan bahwa data.eth memang merupakan domain tingkat teratas yang terkait dengan Chainlink proyek? Solusi untuk masalah ini untuk jaringan Chainlink memiliki banyak cabang dan mungkin melibatkan: • Menambahkan data TXT [224] ke data domain kami untuk chain.link yang menentukan data.eth sebagai domain root untuk ekosistem Chainlink. (Chainlink dengan demikian secara implisit memanfaatkan PKI untuk domain internet untuk memvalidasi domain root ENS-nya.) • Menautkan ke data.eth dari situs web Chainlink yang ada, misalnya, dari https://docs.chain.link. (Penggunaan PKI lainnya secara implisit untuk domain internet.) • Membuat penggunaan data.eth diketahui melalui berbagai dokumen, termasuk whitepaper ini. • Memposting data.eth secara publik di saluran media sosial kami, seperti Twitter, dan blog Chainlink [18]. • Menempatkan LINK dalam jumlah besar di bawah kendali alamat pendaftar yang sama sebagai data.eth.
DON Deployment Considerations
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 identifies 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 specific 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 effects, as recent flash-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 first 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 efficient 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 verifiable 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 benefit 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 fine-grained accountability mechanisms. For example, off-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 fine-grained way. We have additionally discussed approaches to building guard rails in Section 7.3 that address the contract-specific 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, specifically forking / equivocation and service-level agreement (SLA) failures, as we now explain. Forking / equivocation: Given sufficiently 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 specific oracle feeds, and can build on our work outlined in Section 9.
Enforcing service-level agreements: While DONs are not necessarily meant to run indefinitely, 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 fine-grained SLA failures, including errors in computation using executables (via, e.g., the mechanisms for proving correct off-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 Pertimbangan Penerapan
Meskipun bukan bagian dari desain inti kami, ada beberapa pertimbangan teknis yang penting dalam realisasi DONs yang layak mendapat perawatan di sini.
8.1 Pendekatan Peluncuran Makalah ini memaparkan visi ambisius tentang fungsionalitas Chainlink tingkat lanjut realisasinya akan membutuhkan solusi terhadap banyak tantangan yang ada di sepanjang jalan. Buku putih ini mengidentifikasi beberapa tantangan, namun tantangan yang tidak diantisipasi pasti akan muncul. Kami berencana untuk mengimplementasikan elemen-elemen visi ini secara bertahap selama bertahun-tahun jangka waktu yang lama. Harapan kami adalah DONs akan diluncurkan pada awalnya dukungan untuk komponen pra-bangun tertentu yang dibangun secara kolaboratif oleh tim di dalamnya Chainlink komunitas. Tujuannya adalah penggunaan DON yang lebih luas, misalnya kemampuan untuk meluncurkan executable sewenang-wenang, akan melihat dukungan di lain waktu. Salah satu alasan untuk berhati-hati adalah bahwa komposisi smart contract dapat menimbulkan efek samping yang kompleks, tidak diinginkan, dan berbahaya, seperti yang terjadi pada serangan berbasis pinjaman kilat baru-baru ini. misalnya ditunjukkan [127, 189]. Demikian pula komposisi smart contracts, adaptor, dan executable akan membutuhkan kehati-hatian yang ekstrim. Dalam penerapan awal DONs, kami berencana untuk hanya menyertakan sekumpulan executable dan adaptor yang telah dibuat sebelumnya dengan template. Hal ini akan memungkinkan studi tentang keamanan komposisi fungsi ini menggunakan metode formal [46, 170] dan pendekatan lainnya. Itu akan terjadi juga menyederhanakan penetapan harga: Penetapan harga fungsionalitas dapat ditetapkan oleh DON node berdasarkan perfungsionalitas, bukan melalui pengukuran umum, sebuah pendekatan yang diadopsi di, misalnya, [156]. Kami juga mengharapkan komunitas Chainlink untuk mengambil bagian dalam pembuatannya templat tambahan, menggabungkan berbagai adaptor dan executable menjadi lebih banyak layanan terdesentralisasi yang berguna yang dapat dijalankan oleh ratusan, bahkan ribuan orang DONdtk. Selain itu, pendekatan ini dapat membantu mencegah pembengkakan negara, yaitu kebutuhan akan DON node untuk mempertahankan jumlah status yang tidak bisa dijalankan dalam memori kerja. Masalah ini adalah sudah muncul dalam blockchains tanpa izin, yang memotivasi pendekatan seperti “stateless klien” (lihat, misalnya, [206]). Hal ini bisa menjadi lebih akut dalam sistem throughput yang lebih tinggi, sehingga memotivasi sebuah pendekatan di mana DON hanya menyebarkan executable dengan ukuran negara yang dioptimalkan. Seiring dengan berkembang dan matangnya DON serta mencakup pagar pengaman yang kuat, seperti yang dibahas di Bagian 7, mekanisme keamanan berbasis kriptoekonomi dan reputasi seperti yang dibahas di Bagian 9, dan fitur lain yang memberikan jaminan tingkat tinggi bagi pengguna DON, kami juga berharap untuk mengembangkan kerangka kerja dan alat untuk memfasilitasi peluncuran dan penggunaan yang lebih luas DONs oleh komunitas. Idealnya, alat ini akan mengaktifkan kumpulan operator node untuk berkumpul sebagai jaringan oracle dan meluncurkan DON mereka sendiri tanpa izin atau cara swalayan, artinya mereka dapat melakukannya secara sepihak. 8.2 Keanggotaan DON Dinamis Kumpulan node yang menjalankan DON tertentu dapat berubah seiring waktu. Ada dua pendekatan ke manajemen kunci untuk skL dengan keanggotaan dinamis di O. Yang pertama adalah memperbarui bagian skL yang dimiliki oleh node ketika terjadi perubahan keanggotaan, sambil menjaga pkL tidak berubah. Pendekatan ini, yang dieksplorasi dalam [41, 161, 198], mempunyai manfaat karena tidak mengharuskan pihak pengandal memperbarui pkL.Teknik klasik berbagi ulang saham, yang diperkenalkan pada [122], memberikan solusi sederhana dan cara yang efisien untuk mewujudkan pembaruan saham tersebut. Ini memungkinkan rahasia untuk ditransfer antara satu set node O(1) dan satu detik, kemungkinan berpotongan dengan satu O(2). Dalam hal ini pendekatan, setiap node O(1) saya melakukan (k(2), n(2)) pembagian rahasia dari bagian rahasianya node di O(2) untuk n(2) = |O(2)| dan ambang batas yang diinginkan (mungkin baru) k(2). Berbagai skema pembagian rahasia yang dapat diverifikasi (VSS) [108] dapat memberikan keamanan terhadap musuh yang secara aktif merusak node, yaitu memasukkan perilaku jahat ke dalam protokol. Teknik di [161] bertujuan untuk melakukannya sekaligus mengurangi kompleksitas dan penyediaan komunikasi ketahanan terhadap kegagalan dalam asumsi kekerasan kriptografi. Pendekatan kedua adalah memperbarui pkL kunci buku besar. Hal ini mempunyai manfaat ke depan keamanan: Kompromi pada saham lama pkL (yaitu, node komite sebelumnya) tidak akan dilakukan mengakibatkan kompromi pada kunci saat ini. Namun, pembaruan pada pkL memiliki dua kelemahan: (1) Data yang dienkripsi dengan pkL perlu dienkripsi ulang selama penyegaran kunci dan (2) Pembaruan penting perlu disebarkan kepada pihak-pihak yang mengandalkan. Kami bermaksud untuk mengeksplorasi kedua pendekatan tersebut, serta hibridisasi keduanya. 8.3 DON Akuntabilitas Seperti jaringan Chainlink oracle yang ada, DONs akan mencakup mekanisme akuntabilitas, yaitu mencatat, memantau, dan menegakkan perilaku node yang benar. DONs akan memilikinya kapasitas data yang jauh lebih besar dibandingkan banyak blockchain tanpa izin yang ada, terutama mengingat kemampuannya untuk terhubung ke penyimpanan eksternal yang terdesentralisasi. Akibatnya, mereka akan dapat mencatat riwayat kinerja node secara detail, sehingga memungkinkan mekanisme akuntabilitas yang lebih rinci. Misalnya, komputasi off-chain harga aset mungkin melibatkan masukan yang dibuang sebelum hasil median dikirimkan rantai. Dalam DON, hasil antara ini dapat dicatat. Perilaku buruk atau penyimpangan kinerja oleh masing-masing node di DON dapat diperbaiki atau dikenakan sanksi pada DON dengan cara yang halus. Kami juga telah membahas pendekatan untuk membangun pagar pembatas di Bagian 7.3 yang membahas dampak spesifik kontrak dari kegagalan sistemik. Namun, penting juga untuk memiliki mekanisme yang aman dari kegagalan untuk DONs itu sendiri, yaitu, perlindungan terhadap kegagalan DON yang sistemik dan berpotensi menimbulkan bencana, khususnya kegagalan forking / equivocation dan perjanjian tingkat layanan (SLA), seperti yang sekarang kami jelaskan. Forking / dalih: Mengingat cukup banyak node yang salah, DON dapat bercabang atau mengelak, menghasilkan dua blok atau rangkaian blok yang berbeda dan tidak konsisten di L. Namun, karena DON menandatangani isi L secara digital, dimungkinkan untuk memanfaatkan a rantai utama MAINCHAIN untuk mencegah dan/atau menghukum dalih. DON dapat secara berkala menyatakan pos pemeriksaan dari L dalam kontrak audit di MAINCHAIN. Jika keadaan masa depannya menyimpang dari keadaan yang diperiksa, pengguna/auditor dapat memberikan bukti kesalahan perilaku ini terhadap kontrak audit. Bukti tersebut dapat digunakan untuk menghasilkan peringatan atau menghukum DON node melalui pemotongan kontrak. Pendekatan terakhir ini memperkenalkan masalah desain insentif serupa dengan masalah feed oracle tertentu, dan dapat dikembangkan berdasarkan pekerjaan kami diuraikan dalam Bagian 9.Menegakkan perjanjian tingkat layanan: Meskipun DONs belum tentu dimaksudkan demikian berjalan tanpa batas waktu, penting bagi mereka untuk mematuhi perjanjian tingkat layanan (SLA) dengan penggunanya. Penegakan SLA dasar dimungkinkan pada rantai utama. Misalnya, Node DON mungkin berkomitmen untuk mempertahankan DON hingga tanggal tertentu, atau memberikan pemberitahuan terlebih dahulu mengenai penghentian layanan (misalnya, pemberitahuan tiga bulan sebelumnya). Sebuah kontrak aktif MAINCHAIN dapat menyediakan penegakan SLA ekonomi kripto dasar. Misalnya, kontrak SLA dapat memangkas dana yang disetorkan DON jika pos pemeriksaan tidak disediakan pada interval yang diperlukan. Pengguna dapat menyetor dana dan menantang DON untuk membuktikan bahwa pos pemeriksaan dengan benar mewakili urutan blok yang valid (dengan cara tertentu analog dengan, mis. [141]). Tentu saja, produksi blok tidak sama dengan transaksi pemrosesan, namun kontrak SLA juga dapat berfungsi untuk menegakkan yang terakhir. Misalnya, di Jika versi FSS yang kompatibel dengan versi lama di mana transaksi diambil dari mempool (lihat Bagian 5.2), transaksi pada akhirnya ditambang dan ditempatkan dalam rantai. Seorang pengguna dapat membuktikan DON penyimpangan dengan melengkapi kontrak SLA dengan transaksi yang telah ditambang tetapi tidak dikirimkan oleh DON untuk diproses sesuai kontrak target dalam interval waktu yang sesuai.15 Hal ini juga memungkinkan untuk membuktikan keberadaan dan memberikan sanksi pada SLA yang lebih rinci kegagalan, termasuk kesalahan dalam komputasi menggunakan executable (melalui, misalnya, mekanisme untuk membuktikan kebenaran transaksi negara off-chain yang diuraikan dalam Bagian 6.3) atau kegagalan untuk dijalankan executable berdasarkan inisiator yang terlihat di DON, kegagalan menyampaikan data di DON ke RANTAI UTAMA tepat waktu, dan lain sebagainya.
Economics and Cryptoeconomics
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, differs 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 difference 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., off-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 financial 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 financial 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 (specifically, 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 confidence in Bitcoin, depressing its value, and consequently eroding the value of their collective capital investments in mining infrastructure [150]. The Chainlink network benefits 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 benefit of maintaining confidence 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 reflects 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 benefit 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 offagainst 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 financial utility—to behave honestly. Put another way, the goal is to maximize the financial resources required for an adversary to attack the network successfully. By formulating a staking protocol with mathematically well defined 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 confidence 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 effect 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 briefly describe other potential effects 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 financial incentives. The adversary may derive financial resources prospectively from successfully tampering with an oracle report, e.g., offer to share the resulting profit 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 offers bribes to oracles whose identities are determined after the fact (e.g., offers 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 first 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 first 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) specifies 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 confiscating the deposits of faulty nodes. Our staking system designs involve two tiers: the first, default tier, and the second, backstop tier. The first 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 first 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-specified 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 first tier. Additionally, as discussed in Section 9.4.3, DECO or Town Crier can serve as powerful tools to help ensure efficient 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 benefit 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 first-tier system. Watchdog priority results in super-linear staking impact in the following way: if the first-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 offer 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 fields 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 codifies sets of actions available to participants in the game, known as players. A game also specifies the payoffs 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 payoffby 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-specific form of MD that leverages cryptographic techniques to create desirable equilibria within decentralized systems. Bribery and collusion create significant challenges throughout the field of MD. Almost all mechanisms break in the presence of collusion, defined 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) payoffs. 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 payoffof 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 payoffis the reward specified 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 offer 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, specifically first-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 defined to be honest if they follow the protocol even when it is not in their financial 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 first-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 financial incentives, choosing actions that result in an expected financial gain. For example, if a node is offered 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— specifically 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 first-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 briefly 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 confiscates part or all of the stake of oracle nodes that generate reports identified by the second-tier system as incorrect. Oracle nodes are thus deterred from misbehaving by the resulting financial penalty. This approach is similar in flavor 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-defined 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 fixed (parameterizable) budget, denoted by $B. The adversary can communicate individually and confidentially with each oracle in the network, and can secretly offer 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 fixed (if potentially large) budget $B. We further assume that the adversary does not control communication in the oracle network, specifically that it cannot substantially delay traffic between first-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) Offer bribes to any desired nodes, with guaranteed payment contingent on outcomes specified by the adversary, as described above. While we don’t offer 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 final outcome is computed as an aggregate of these reports to be used by a consuming smart contract. The briber’s aim is for the final outcome to be incorrect, i.e., false. • Unconditional briber: Briber offers bribe $b to any oracle that reports false. • Probabilistic briber: Briber offers bribe $b with some probability q to any oracle that reports false.
• false-outcome conditioned briber: Briber offers bribe $b to any oracle that reports false provided that the final outcome is false. • No-alert-conditioned briber: Briber offers bribe $b to any oracle that reports false as long as no alert is raised. • p-plus-epsilon Briber: Briber offers bribe $b to any oracle that reports false as long as the majority of oracles do not report false. • Prospective briber: Briber offers 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 profit larger than its expenditure. Thus for our adversarial model and proposed staking mechanism, $B may be viewed as a measure of the potential profit 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 offers a sufficient 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 confirmation time for reports. We therefore briefly
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 first 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 briefly 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 simplified sketch of the two-tiered construction we intend to build. Most of our focus will be on describing the first-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 first 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 first-tier mechanism outputs the majority value output by nodes as the final 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 fixed per-round payment $p, which is much smaller than $d. • Partial agreement: It is possible that some nodes are offline 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 confirms that the output of the
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. first-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 first-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 specifically 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 significantly 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 (first-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 effective than increasing $d, of course, and can have a dramatic effect: 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 offered 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 profit 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 significantly more costly than normal operation of the first 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 configuration 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., first 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 first-tier network, and may adjudicate faults across multiple first-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 first-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 first-tier nodes. Any first-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 first 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 firsttier. 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 offers complete flexibility 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 first-tier nodes that intentionally produce incorrect reports and honest first-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 first-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 first-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 inefficient, escalating rounds of voting to address such challenges. Using DECO or Town Crier, however, a first tier node can prove correct behavior to second-tier nodes. (See Section 3.6.2 for details on the two systems.) Specifically, if the second tier node identifies a first-tier node as having output a faulty report value ˜r, the first-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 first-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 financial 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 offer 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 first-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 efficient manner using smart contracts. As a simple example, a parametric insurance contract SCins can compensate policyholders automatically if our incentive mechanism’s second tier identifies an error in a report generated in the first 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 conflicting reports for SC, where r1 is signed by the first 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 first 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, traffic 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 first identified 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 identified 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 briefly 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 (effective) 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 briefly 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. Different Chainlink users may wish to use the IIF in different ways, e.g., giving different weighting to different 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 confidentiality-preserving DeFi. Fees in the Chainlink network support node operators’ costs for, e.g., running servers, acquiring necessary data licenses, and maintaining a global staffto 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 off-chain data) establish a high-trust record of a node’s history, enabling computation of FFO in a transparent, empirically driven manner. A simple, first-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 falsified service volumes.
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 definitive 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 benefit 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 different 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 off chain, such as Off-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 specifically to monitor, validate, and record data relating to off-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 verifiable 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 benefit 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 identified 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 fixed 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 flow of additional stake into the network to secure it at a higher rate. Specifically, 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 effect 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 financial 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.
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⃝. Specifically, 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 efficiency as service volumes increase—and network effects—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 sufficient 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 exemplifies larger patterns of growth that the Chainlink network can help bring about in an on-chain economy for decentralized services.
Ekonomi dan Kriptoekonomi
Agar jaringan Chainlink dapat mencapai keamanan yang kuat dalam model kepercayaan yang terdesentralisasi, sangat penting bahwa node secara kolektif menunjukkan perilaku yang benar, artinya mereka patuh sebagian besar waktunya tepat untuk protokol DON. Pada bagian ini, kita membahas pendekatan untuk membantu menegakkan perilaku tersebut melalui insentif ekonomi, alias ekonomi kripto insentif. Insentif ini terbagi dalam dua kategori: eksplisit dan implisit, terealisasi masing-masing melalui staking dan peluang biaya masa depan (FFO). Mempertaruhkan: Staking di Chainlink, seperti pada sistem blockchain lainnya, melibatkan peserta jaringan, yaitu node oracle, yang menyetorkan dana terkunci dalam bentuk LINK tokens. Ini dana, yang juga kami sebut sebagai taruhan atau taruhan eksplisit adalah insentif eksplisit. Mereka dapat disita jika node mengalami kegagalan atau penyimpangan. Dalam konteks blockchain, prosedur ini sering disebut pemotongan. Namun, staking sebanyak oracle node di Chainlink, berbeda secara mendasar dari staking oleh validators dalam blockchains tanpa izin. Validator dapat berperilaku buruk dengan mengelak atau memerintahkan transaksi secara berlawanan. Protokol konsensus yang mendasari dalam a 15Karena pengguna dapat mengganti transaksi di mempool, diperlukan kehati-hatian untuk memastikan korespondensi yang benar antara transaksi yang ditambang dan DON yang dikirimkan.Namun, blockchain tanpa izin menggunakan aturan validasi blok yang tegas dan primitif kriptografi untuk mencegah validators menghasilkan blok yang tidak valid. Sebaliknya, perlindungan terprogram tidak dapat mencegah pembuatan jaringan oracle yang curang laporan tidak valid. Alasannya adalah perbedaan utama antara kedua jenis sistem: validasi transaksi di blockchains adalah properti konsistensi internal, sedangkan kebenarannya dari oracle laporan pada blockchain adalah properti eksternal, yaitu data off-chain. Kami telah merancang mekanisme staking awal untuk Chainlink berbasis jaringan pada protokol interaktif di antara oracle node yang mungkin menggunakan data eksternal. Ini Mekanisme ini menciptakan insentif finansial untuk perilaku yang benar dengan menggunakan imbalan yang jelas dan hukuman (tebasan). Karena mekanismenya ekonomis, maka dirancang untuk mencegah node korupsi oleh musuh yang menggunakan sumber daya keuangan untuk merusak node melalui penyuapan. (Musuh seperti itu sangat umum, dan meluas, misalnya, ke node yang bekerja sama mengambil nilai dari perilaku buruk kolektif mereka.) Mekanisme Chainlink staking yang kami rancang memiliki beberapa kekuatan dan novel fitur.16 Fitur utama tersebut adalah dampak staking super-linear (khususnya, kuadrat). Musuh harus memiliki sumber daya yang jauh melebihi dana yang disimpan oleh node untuk menumbangkan mekanisme tersebut. Mekanisme staking kami juga memberikan perlindungan terhadap musuh yang lebih kuat daripada yang dipertimbangkan sebelumnya dalam sistem serupa, yaitu musuh yang dapat memberikan suap yang mengkondisikan perilaku node di masa depan. Selain itu, kami mendiskusikan bagaimana alat Chainlink seperti DECO dapat membantu memperkuat staking kami mekanisme dengan memfasilitasi keputusan yang benar jika terjadi perilaku node yang salah. Peluang biaya masa depan (FFO): blockchains tanpa izin—dari kedua PoW dan variasi PoS—saat ini sangat bergantung pada apa yang kami sebut sebagai insentif implisit. Ini adalah insentif ekonomi untuk perilaku jujur yang tidak berasal dari imbalan yang jelas, namun dari partisipasi platform itu sendiri. Misalnya, komunitas penambang Bitcoin diberi insentif agar tidak melancarkan serangan 51% karena berisiko merusak kepercayaan terhadap perusahaan. Bitcoin, menurunkan nilainya, dan akibatnya mengikis nilai kolektifnya penanaman modal pada infrastruktur pertambangan [150]. Jaringan Chainlink mendapat manfaat dari insentif implisit serupa yang kami rujuk sebagai peluang biaya masa depan (FFO). Node Oracle dengan riwayat kinerja yang kuat atau reputasi menarik biaya dari pengguna. Perilaku buruk oleh node oracle membahayakan masa depan pembayaran biaya dan dengan demikian menghukum node dengan biaya peluang dalam hal potensi pendapatan yang diperoleh melalui partisipasi dalam jaringan. Dengan analogi dengan taruhan eksplisit, FFO dapat dipandang sebagai bentuk pertaruhan implisit, sebuah insentif untuk perilaku jujur berasal dari manfaat bersama dalam menjaga kepercayaan pada platform di mana Bisnis operator node bergantung, misalnya, pada kinerja dan reputasi positif dari node tersebut jaringan. Insentif ini melekat namun tidak secara eksplisit dinyatakan dalam jaringan Chainlink protokol. Pada Bitcoin, mempertahankan nilai operasi penambangan seperti yang disebutkan di atas 16Mekanisme staking yang kami jelaskan di sini saat ini hanya bertujuan untuk menegakkan penyampaian laporan yang benar oleh oracle jaringan. Kami berharap di masa depan pekerjaan dapat memperluasnya untuk memastikan pelaksanaan yang benar dari banyak hal fungsi lain yang akan disediakan oleh DONs.juga dapat dipandang sebagai bentuk kepemilikan implisit. Kami menekankan bahwa FFO sudah ada di Chainlink dan membantu mengamankan jaringan hari ini. Kontribusi utama kami dalam pengembangan lebih lanjut Chainlink adalah pendekatan yang berprinsip dan didorong secara empiris untuk mengevaluasi insentif implisit seperti FFO melalui apa yang kami sebut Kerangka Insentif Implisit (IIF). Untuk memperkirakan jumlah seperti peluang biaya node di masa depan, IIF akan terus memanfaatkan hal ini secara komprehensif data kinerja dan pembayaran yang dikumpulkan oleh jaringan Chainlink. Perkiraan seperti itu akan mengaktifkan parameterisasi sistem staking berbasis IIF yang mencerminkan insentif node dengan akurasi lebih tinggi dibandingkan model heuristik dan/atau statis saat ini. Jadi, untuk meringkas, dua insentif ekonomi utama untuk simpul oracle yang benar perilaku dalam jaringan Chainlink yang sedang berkembang adalah: • Staking (taruhan yang disimpan) o Insentif eksplisit • Peluang biaya masa depan (FFO) o Insentif implisit Kedua bentuk insentif ini saling melengkapi. Node Oracle bisa secara bersamaan berpartisipasi dalam protokol Chainlink staking, nikmati aliran pendapatan berkelanjutan dari pengguna, dan secara kolektif mendapatkan manfaat dari perilaku baik mereka yang berkelanjutan. Demikian kedua insentif tersebut berkontribusi pada keamanan ekonomi kripto yang disediakan oleh jaringan oracle. Selain itu, kedua insentif tersebut dapat saling memperkuat dan/atau saling bertentangan. Misalnya, operator oracle baru tanpa riwayat kinerja dan aliran pendapatan dapat mempertaruhkan a LINK dalam jumlah besar sebagai jaminan perilaku jujur, sehingga menarik pengguna dan biaya. Sebaliknya, operator oracle yang mapan memiliki waktu yang panjang dan relatif bebas kesalahan riwayat kinerja dapat membebankan biaya besar dari basis pengguna yang besar dan karenanya bergantung lebih menekankan pada FFO-nya sebagai bentuk insentif implisit. Secara umum, pendekatan yang kami pertimbangkan di sini bertujuan untuk sejumlah oracle-jaringan sumber daya untuk menciptakan insentif ekonomi sebesar mungkin di Chainlink secara rasional agen—yaitu, node yang memaksimalkan utilitas finansialnya—untuk berperilaku jujur. Letakkan yang lain Dengan cara ini, tujuannya adalah untuk memaksimalkan sumber daya finansial yang dibutuhkan musuh untuk menyerang jaringan berhasil. Dengan merumuskan protokol staking dengan baik secara matematis mendefinisikan keamanan ekonomi dan juga menggunakan IIF, kami bertujuan untuk mengukur kekuatan insentif Chainlink seakurat mungkin. Pembuat kontrak yang mengandalkan akan melakukannya kemudian dapat menentukan dengan keyakinan yang kuat apakah jaringan oracle bertemu tingkat keamanan kriptoekonomi yang diperlukan. Siklus baik keamanan ekonomi: Insentif yang kita bahas di bagian ini, staking dan FFO, mempunyai dampak lebih dari sekadar memperkuat keamanan DONdtk. Mereka berjanji untuk mendorong apa yang kita sebut sebagai siklus keamanan ekonomi yang baik. Dampak staking yang sangat linier (dan skala ekonomi lainnya) mengakibatkan operasional menjadi lebih rendah biaya seiring dengan meningkatnya keamanan DON. Biaya yang lebih rendah menarik pengguna tambahan ke DON,meningkatkan pembayaran biaya. Kenaikan pembayaran biaya terus mendorong pertumbuhan jaringan, yang melanggengkan siklus yang baik. Kami percaya bahwa siklus baik keamanan ekonomi hanyalah salah satu contoh dari skala ekonomi dan efek jaringan antara lain yang akan kita bahas nanti di bagian ini. Organisasi bagian: Staking menghadirkan tantangan teknis dan konseptual yang penting yang mana kami telah merancang mekanisme dengan fitur-fitur baru. Oleh karena itu, staking akan terjadi fokus utama kami di bagian ini. Kami memberikan gambaran umum tentang pendekatan staking yang kami perkenalkan dalam makalah ini di Bagian 9.1, diikuti dengan pembahasan mendetail di Bagian 9.2 hingga 9.5. Kami menyajikan IFF di Bagian 9.6. Kami menyajikan tampilan ringkasan Chainlink insentif jaringan di Bagian 9.7. Di Bagian 9.8, kami membahas siklus baik keamanan ekonomi yang dapat dihasilkan oleh pendekatan staking yang kami usulkan ke jaringan oracle. Terakhir, kami uraikan secara singkat potensi lainnya efek mendorong pertumbuhan jaringan Chainlink di Bagian 9.9. 9.1 Ikhtisar Taruhan Desain mekanisme staking yang kami perkenalkan di sini, seperti disebutkan di atas, melibatkan protokol interaktif di antara oracle node yang memungkinkan penyelesaian ketidakkonsistenan dalam pelaporan data eksternal. Staking bertujuan untuk memastikan perilaku jujur dari node oracle yang rasional. Oleh karena itu kita dapat memodelkan musuh yang menyerang protokol staking sebagai a penyuap: Strategi musuh adalah merusak oracle node dengan menggunakan insentif finansial. Musuh dapat memperoleh sumber daya finansial secara prospektif dari upaya perusakan yang berhasil dengan laporan oracle, misalnya, menawarkan untuk membagi keuntungan yang dihasilkan dengan node yang rusak. Kami menargetkan desain mekanisme staking secara bersamaan pada dua tujuan ambisius: 1. Melawan musuh yang kuat: Mekanisme staking dirancang untuk melindungi oracle jaringan melawan sekelompok besar musuh yang mampu melakukan tindakan yang kompleks, strategi suap bersyarat, termasuk suap prospektif, yang menawarkan suap kepada oracles yang identitasnya ditentukan setelah kejadian tersebut (misalnya, menawarkan suap kepada oracles dipilih secara acak untuk peringatan prioritas tinggi). Sedangkan desain oracle lainnya telah mempertimbangkan serangkaian serangan sempit tanpa kemampuan penuh yang realistis musuh, sepanjang pengetahuan kami mekanisme permusuhan yang kami perkenalkan Inilah yang pertama kali secara eksplisit membahas serangkaian strategi dan pertunjukan suap resistensi dalam model ini. Model kami mengasumsikan bahwa ada node selain penyerang rasional secara ekonomi (bukan jujur), dan kami berasumsi adanya a sumber kebenaran yang sangat mahal untuk penggunaan umum tetapi tersedia jika terjadi perbedaan pendapat (dibahas lebih lanjut di bawah). 2. Mencapai dampak staking super-linier: Tujuan kami adalah memastikan bahwa jaringan oracle terdiri dari laporan agen yang rasional sejujurnya bahkan di hadapan penyerang dengan anggaran yang super-lineardalam total saham yang disimpan oleh seluruh jaringan. Dalam sistem staking yang ada, jika masing-masing dari n node mempertaruhkan $d, penyerang dapat mengeluarkan suap yang kredibel yang diminta bahwa node berperilaku tidak jujur dengan imbalan pembayaran sedikit lebih dari \(d to each node, using a total budget of about \)dn. Ini sudah merupakan standar yang tinggi penyerang harus memiliki anggaran yang likuid berdasarkan urutan simpanan gabungan semua pemangku kepentingan dalam jaringan. Tujuan kami adalah tingkat keamanan ekonomi yang lebih kuat daripada rintangan yang sudah besar ini. Kami bertujuan untuk merancang sistem staking pertama yang dapat mencapai keamanan bagi penyerang umum dengan anggaran super-linear di n. Meskipun pertimbangan praktis mungkin memberikan dampak yang lebih kecil, seperti yang kita bahas di bawah ini, desain awal kami mencapai kebutuhan anggaran yang berlawanan lebih besar dari $dn2/2, yaitu, menskalakan kuadrat dalam n, membuat suap menjadi tidak praktis bahkan ketika node hanya melakukan staking dalam jumlah sedang. Untuk mencapai kedua tujuan ini memerlukan kombinasi desain insentif yang inovatif dan kriptografi. Ide-ide kunci: Pendekatan staking kami bergantung pada gagasan yang kami sebut sebagai prioritas pengawas. Laporan yang dihasilkan oleh jaringan Chainlink oracle dan dikirim ke kontrak yang mengandalkan (misalnya, harga aset) dikumpulkan dari masing-masing laporan yang disumbangkan oleh node yang berpartisipasi (misalnya, dengan mengambil median). Biasanya perjanjian tingkat layanan (SLA) menentukan batas deviasi yang dapat diterima untuk laporan, yaitu seberapa jauh laporan node dapat melakukannya menyimpang dari laporan agregat dan seberapa jauh agregat tersebut diperbolehkan menyimpang dari nilai sebenarnya untuk dianggap benar. Dalam sistem staking kami, untuk putaran pelaporan tertentu, setiap node oracle dapat bertindak sebagai pengawas untuk memberikan peringatan jika mereka yakin bahwa laporan agregat tersebut tidak benar. Di masing-masing putaran pelaporan, setiap node oracle diberi prioritas publik yang menentukan urutan peringatannya (jika ada) akan diproses. Mekanisme kami bertujuan untuk mendapatkan imbalan konsentrasi, yang berarti bahwa pengawas dengan prioritas tertinggi untuk meningkatkan kewaspadaan berhak mendapatkan seluruh imbalan yang dihasilkan dengan menyita simpanan node yang salah. Desain sistem staking kami melibatkan dua tingkatan: yang pertama, tingkat default, dan yang kedua, tingkat penghalang. Tingkat pertama adalah jaringan oracle itu sendiri, yang terdiri dari n node. (Untuk kesederhanaan, kami berasumsi n ganjil.) Jika mayoritas node melaporkan nilai yang salah, pengawas di tingkat pertama diberi insentif yang kuat untuk meningkatkan kewaspadaan. Jika peringatan dimunculkan, pelaporan Keputusan jaringan kemudian ditingkatkan ke tingkat kedua—sistem berbiaya tinggi dan memiliki keandalan maksimum yang dapat ditentukan oleh pengguna dalam perjanjian tingkat layanan jaringan. Ini bisa berupa sistem yang, misalnya, hanya terdiri dari node-node yang kuat skor keandalan historis, atau skor yang memiliki urutan besarnya lebih dari oracles tingkat pertama. Selain itu, sebagaimana dibahas dalam Bagian 9.4.3, DECO atau Town Crier dapat berfungsi sebagai alat yang ampuh untuk membantu memastikan keputusan yang efisien dan konklusif di tingkat kedua. Untuk mempermudah, kami berasumsi bahwa sistem lapis kedua ini menghasilkan laporan yang benar nilai. Meskipun mungkin terlihat menarik jika hanya mengandalkan tingkat kedua untuk menghasilkan semua laporan, manfaat dari desain kami adalah secara konsisten mencapai sifat keamanansistem lapis kedua sambil hanya membayar biaya operasional, dalam kasus tertentu, dari sistem tersebut sistem tingkat pertama. Prioritas pengawas menghasilkan dampak staking super-linear dengan cara berikut: jika jaringan oracle tingkat pertama mengeluarkan hasil yang salah dan sejumlah node pengawas waspada, mekanisme insentif staking memberikan penghargaan kepada pengawas dengan prioritas tertinggi lebih dari $dn/2 diambil dari simpanan node (mayoritas) yang berperilaku buruk. Itu Oleh karena itu, imbalan total terkonsentrasi di tangan pengawas tunggal ini menentukan jumlah minimum yang harus dijanjikan oleh musuh kepada calon pengawas memberi insentif agar tidak memperingatkan. Karena mekanisme kami memastikan bahwa setiap oracle mendapatkan kesempatan untuk bertindak sebagai pengawas jika pengawas dengan prioritas lebih tinggi telah menerima suap (dan memilih untuk tidak waspada), oleh karena itu pihak lawan harus menawarkan suap lebih dari itu $dn/2 ke setiap node untuk mencegah peringatan apa pun dimunculkan. Karena ada n node, maka anggaran yang diperlukan musuh agar suap berhasil berjumlah lebih dari $dn2/2, yang mana adalah kuadrat dalam jumlah n node dalam jaringan. 9.2 Latar Belakang Pendekatan kami terhadap staking mengacu pada penelitian di bidang teori dan mekanisme permainan desain (MD) (untuk referensi buku teks, lihat [177]). Teori permainan adalah secara matematis studi formal tentang interaksi strategis. Dalam konteks ini, permainan adalah salah satu contohnya sebuah interaksi, biasanya di dunia nyata, yang mengkodifikasi serangkaian tindakan yang tersedia peserta dalam permainan, yang dikenal sebagai pemain. Sebuah permainan juga menentukan pembayaran yang diperoleh oleh masing-masing pemain—hadiah yang bergantung pada tindakan yang dipilih pemain dan tindakan pemain lain. Mungkin contoh paling terkenal dari permainan yang dipelajari dalam permainan teorinya adalah Dilema Narapidana [178]. Para ahli teori permainan umumnya bertujuan untuk memahami keseimbangan atau keseimbangan (jika ada) yang direpresentasikan dalam permainan tertentu. Keseimbangan adalah serangkaian strategi (satu untuk setiap pemain) sedemikian rupa sehingga tidak ada satu pemain pun yang dapat memperoleh strategi yang lebih tinggi membayar dengan secara sepihak menyimpang dari strateginya. Sedangkan desain mekanisme adalah ilmu merancang insentif sedemikian rupa keseimbangan suatu interaksi (dan permainan terkaitnya) mempunyai beberapa sifat yang diinginkan. MD dapat dipandang sebagai kebalikan dari teori permainan: Pertanyaan kanonik dalam permainan teorinya adalah, “dengan adanya insentif dan model, keseimbangan seperti apa yang akan terjadi?” Di MD, itu Pertanyaannya adalah, “insentif apa yang akan menghasilkan permainan dengan keseimbangan yang diinginkan?” Tujuan umum dari perancang mekanisme adalah untuk menciptakan mekanisme yang ‘kompatibel dengan insentif’, yang berarti bahwa peserta dalam mekanisme tersebut (misalnya, lelang atau informasi lainnya) sistem elisitasi [228]) diberi insentif untuk melaporkan kebenaran mengenai beberapa hal (misalnya, bagaimana seberapa besar mereka menghargai barang tertentu). Lelang Vickrey (harga kedua) mungkin adalah yang terbaik mekanisme yang paling dikenal dan kompatibel dengan insentif, di mana peserta mengajukan penawaran tertutup untuk suatu barang dan penawar tertinggi memenangkan barang tersebut tetapi membayar harga tertinggi kedua [214]. Cryptoeconomics adalah bentuk MD khusus domain yang memanfaatkan kriptografi teknik untuk menciptakan keseimbangan yang diinginkan dalam sistem desentralisasi. Suap dan kolusi menciptakan tantangan yang signifikan di seluruh bidang MD. Hampir semua mekanisme rusak jika terjadi kolusi, yang didefinisikan sebagai kontrak sampingan antaraantara pihak-pihak yang berpartisipasi dalam suatu mekanisme [125, 130]. Penyuapan, dimana pihak eksternal memberikan insentif baru, menghadirkan masalah yang lebih sulit daripada kolusi; kolusi dapat dipandang sebagai kasus khusus suap antar hewan buruan peserta. Sistem Blockchain sering kali dapat dikonseptualisasikan sebagai permainan dengan imbalan moneter (berbasis mata uang kripto). Contoh sederhananya adalah penambangan Proof-of-Work: penambang memiliki ruang tindakan di mana mereka dapat memilih hashrate yang akan digunakan untuk menambang blok. Imbalan penambangan adalah imbalan negatif yang dijamin (biaya listrik dan peralatan) ditambah stokastik imbalan positif (subsidi penambangan) yang bergantung pada jumlah penambang aktif lainnya [106, 172] dan biaya transaksi. oracle crowdsourced seperti SchellingCoin [68] adalah contoh lain: ruang tindakan adalah kumpulan kemungkinan laporan yang dapat dikirim oleh oracle, sementara imbalannya adalah imbalan yang ditentukan oleh mekanisme oracle, misalnya, pembayaran mungkin bergantung tentang seberapa dekat laporan oracle dengan median laporan lainnya [26, 68, 119, 185]. Permainan Blockchain menawarkan peluang besar untuk serangan kolusi dan penyuapan; memang, smart contracts bahkan dapat memfasilitasi serangan tersebut [96, 165]. Mungkin yang paling terkenal serangan suap terhadap crowdsourcing oracles adalah serangan p-plus-epsilon [67]. Serangan ini muncul dalam konteks mekanisme mirip SchellingCoin di mana pemain mengirimkan laporan bernilai boolean (yaitu, salah atau benar) dan diberi hadiah p jika mereka setuju dengan pengajuan mayoritas. Dalam serangan p-plus-epsilon, penyerang secara kredibel berjanji untuk, misalnya, membayar pengguna $p + ϵ untuk memberikan suara salah jika dan hanya jika mayoritas yang diajukan benar. Hasilnya adalah keseimbangan, di mana semua pemain diberi insentif untuk melaporkan kebohongan terlepas dari apa yang dilakukan pemain lain; akibatnya, penyuap dapat menginduksi node melalui janji suap untuk melaporkan kebohongan tanpa benar-benar membayar suap tersebut (!). Namun, eksplorasi strategi penyuap lainnya dalam konteks oracle—dan khususnya oracle yang tidak dilakukan secara crowdsourcing—masih terbatas pada strategi adversarial yang cukup lemah. model. Misalnya, dalam konteks PoW, para peneliti telah mempelajari kontingen hasil suap, yaitu suap yang dibayarkan hanya jika pesan target berhasil disensor dan tidak muncul dalam satu blok, terlepas dari tindakan masing-masing penambang [96, 165]. Dalam kasus ini dari oracles, namun, selain serangan p-plus-epsilon, kami hanya mengetahui pekerjaan di model suap yang sangat terbatas di mana penyuap mengirimkan suap dengan syarat tindakan individu pemain, bukan pada hasil yang dihasilkan. Di sini kami membuat sketsa rancangan mekanisme perolehan informasi yang tetap bersifat insentif kompatibel bahkan dalam model permusuhan yang kuat, seperti yang dijelaskan dalam sub-bagian berikutnya. 9.3 Asumsi Pemodelan Di subbagian ini, kami menjelaskan bagaimana kami memodelkan perilaku dan kemampuan pemain sistem kami, khususnya node oracle tingkat pertama, node di tingkat kedua (penghakiman) lapisan, dan musuh.9.3.1 Model Insentif Tingkat Pertama: Aktor Rasional Banyak sistem blockchain mengandalkan keamanan pada asumsi sejumlah kejujuran node yang berpartisipasi. Node didefinisikan jujur jika mereka mengikuti protokol ketika hal tersebut bukan merupakan kepentingan finansial mereka. Biasanya sistem Proof-of-Work sejujurnya membutuhkan sebagian besar kekuatan hash, sejujurnya sistem Proof-of-Stake biasanya memerlukan 2/3 atau lebih dari seluruh pasak yang berpartisipasi, dan bahkan sistem lapisan-2 seperti Arbitrum [141] memerlukan setidaknya satu peserta yang jujur. Dalam pemodelan mekanisme staking, kami membuat asumsi yang jauh lebih lemah. (Menjadi jelas, asumsi yang lebih lemah berarti properti keamanan yang lebih kuat dan oleh karena itu lebih disukai.) Kami berasumsi bahwa musuh telah melakukan korupsi, yaitu kontrol, beberapa (minoritas) sebagian kecil dari node oracle tingkat pertama. Kami memodelkan node yang tersisa bukan sebagai agen yang jujur, tetapi sebagai pemaksimal utilitas yang diharapkan secara rasional. Node-node ini bertindak sepenuhnya berdasarkan insentif finansial yang mementingkan diri sendiri, memilih tindakan yang menghasilkan finansial yang diharapkan keuntungan. Misalnya, jika sebuah node ditawari suap yang lebih besar daripada imbalan yang dihasilkannya perilaku jujur, ia akan menerima suap. Catatan tentang node musuh: Sesuai dengan model kepercayaan yang umum untuk sistem desentralisasi, kami berasumsi bahwa semua node bersifat rasional, yaitu berupaya untuk memaksimalkan pendapatan bersih, daripada dikendalikan oleh musuh jahat. Namun klaim kami— khususnya dampak staking super-linier atau kuadratik—tetap tanpa gejala bahwa himpunan node yang dikontrol secara musuh paling banyak (1/2 −c)n, untuk beberapa positif konstan c. 9.3.2 Model Ajudikasi Tingkat Kedua: Kebenaran Berdasarkan Asumsi Ingatlah bahwa fitur penting dari mekanisme staking kami yang membantu mencapai keamanan melawan simpul rasional adalah sistem tingkat kedua. Dalam mekanisme staking yang kami usulkan, oracle mana pun dapat memunculkan peringatan yang menunjukkan bahwa ia yakin keluaran dari mekanisme tersebut salah. Peringatan menghasilkan kepercayaan yang tinggi sistem tingkat kedua mengaktifkan dan melaporkan hasil yang benar. Jadi, pemodelan kunci Persyaratan untuk pendekatan kami adalah penilaian yang benar, yaitu pelaporan yang benar oleh sistem lapis kedua. Model staking kami mengasumsikan sistem tingkat kedua yang bertindak sebagai sumber kebenaran yang tidak dapat rusak dan dapat diandalkan secara maksimal. Sistem seperti ini mungkin mahal dan lambat tidak cocok untuk digunakan pada kasus-kasus tertentu. Namun dalam kasus keseimbangan, yaitu kapan jika sistem tingkat pertama berfungsi dengan benar, sistem tingkat kedua tidak akan dijalankan. Sebaliknya, keberadaannya meningkatkan keamanan seluruh sistem oracle dengan menyediakan a penghalang dengan jaminan tinggi. Penggunaan lapisan ajudikasi dengan tingkat kepercayaan tinggi dan berbiaya tinggi mirip dengan proses banding di jantung sebagian besar sistem peradilan. Hal ini juga sudah umum pada desain oracle sistem, misalnya, [119, 185]. Kami secara singkat membahas pendekatan realisasi tingkat kedua dalam mekanisme kami di Bagian 9.4.3.Protokol staking kami menggunakan asumsi penilaian yang benar dari sistem tingkat kedua sebagai ancaman yang dapat dipercaya untuk menegakkan pelaporan yang benar oleh oracle node. Protokol menyita sebagian atau seluruh saham oracle node yang menghasilkan laporan yang diidentifikasi oleh sistem tingkat kedua sebagai salah. Dengan demikian, node Oracle terhindar dari perilaku buruk dengan sanksi finansial yang diakibatkannya. Pendekatan ini memiliki rasa yang mirip dengan yang digunakan dalam rollups yang optimis, misalnya, [141, 10]. 9.3.3 Model Permusuhan Mekanisme staking kami dirancang untuk memperoleh informasi yang benar sekaligus mencapai keamanan terhadap kelompok musuh yang luas dan terdefinisi dengan baik. Ini meningkatkan pekerjaan sebelumnya, yang menghilangkan model permusuhan eksplisit atau fokus pada subkelas musuh yang sempit, misalnya musuh p-plus-epsilon yang dibahas di atas. Tujuan kami adalah merancang staking mekanisme dengan keamanan yang terbukti secara formal terhadap kemungkinan besar seluruh spektrum musuh untuk ditemui dalam praktek. Kita memodelkan musuh kita sebagai musuh yang memiliki anggaran tetap (dapat diparameterisasi), yang dilambangkan dengan $B. Musuh dapat berkomunikasi secara individu dan rahasia dengan masing-masing oracle masuk jaringan, dan secara diam-diam dapat menawarkan jaminan pembayaran suap kepada siapa pun oracle bergantung pada hasil mekanisme yang dapat diobservasi secara publik. Penentu hasil suap dapat mencakup, misalnya, nilai yang dilaporkan oleh oracle, pesan publik apa pun dikirim oleh oracle mana pun ke mekanisme (misalnya, peringatan), nilai yang dilaporkan oleh pihak lain oracles, dan nilai yang dihasilkan oleh mekanisme. Tidak ada mekanisme yang dapat mengamankan serangan dari penyerang dengan kemampuan tak terbatas. Oleh karena itu, kami menganggap beberapa perilaku tidak realistis atau di luar jangkauan. Kami menganggap penyerang kami tidak dapat memecahkan primitif kriptografi standar, dan, seperti disebutkan di atas, memiliki nilai tetap (if berpotensi besar) anggaran $B. Kami selanjutnya berasumsi bahwa musuh tidak mengendalikan komunikasi di jaringan oracle, khususnya yang tidak dapat menunda secara signifikan lalu lintas antara node tingkat pertama dan/atau tingkat kedua. (Apakah musuh dapat mengamati komunikasi tersebut bergantung pada mekanisme tertentu, seperti yang kami jelaskan di bawah.) Namun secara informal, seperti disebutkan di atas, kami berasumsi bahwa pihak yang berlawanan dapat: (1) Korupsi sebagian kecil dari oracle node ((1/2 −c)-fraksi untuk beberapa konstanta c), yaitu, kontrol penuh mereka, dan (2) Menawarkan suap ke node mana pun yang diinginkan, dengan jaminan pembayaran kontinjensi pada hasil yang ditentukan oleh musuh, seperti dijelaskan di atas. Meskipun kami tidak menawarkan model formal atau taksonomi lengkap mengenai musuh secara penuh berbagai kemampuan menyuap dalam whitepaper ini, berikut contoh macamnya penyuap yang tercakup dalam model kami. Untuk mempermudah, kami berasumsi bahwa oracles memancarkan Boolean laporan yang nilai benarnya (w.l.o.g.) benar, dan hasil akhirnya dihitung sebagai kumpulan laporan ini untuk digunakan oleh smart contract konsumen. milik si penyuap tujuannya adalah agar hasil akhirnya salah, yaitu salah. • Penyuap tanpa syarat: Penyuap menawarkan suap $b kepada oracle mana pun yang melaporkan kebohongan. • Penyuap probabilistik: Penyuap menawarkan suap $b dengan beberapa kemungkinan q kepada oracle mana pun yang melaporkan palsu.• hasil palsu yang dikondisikan oleh penyuap: Penyuap menawarkan suap $b kepada oracle mana pun yang melaporkan palsu asalkan hasil akhirnya salah. • Penyuap tanpa syarat: Penyuap menawarkan suap $b kepada oracle mana pun yang melapor salah selama tidak ada peringatan yang dimunculkan. • p-plus-epsilon Penyuap: Penyuap menawarkan suap $b kepada oracle mana pun yang melaporkan palsu sebagai selama mayoritas oracle tidak melaporkan kebohongan. • Calon penyuap: Penyuap menawarkan suap $b terlebih dahulu kepada oracle mana pun yang dipilih untuk peran yang diacak dan melaporkan palsu. Dalam protokol staking yang kami usulkan, semuanya node bertindak sebagai pengawas potensial, dan kami dapat menunjukkan pengacakan itu prioritas pengawas tidak memungkinkan terjadinya suap. Banyak sistem proof-of-work, proof-of-stake, dan berizin yang rentan terhadap prospektif akan tetapi, penyuapan menunjukkan pentingnya mempertimbangkannya dalam persaingan kita membuat model dan memastikan bahwa protokol staking kami tahan terhadapnya. Lihat Lampiran E untuk lebih jelasnya. 9.3.4 Berapa Banyak Keamanan Kriptoekonomi yang Cukup? Musuh yang rasional hanya akan mengeluarkan uang untuk menyerang suatu sistem jika sistem tersebut dapat memperoleh keuntungan lebih besar dari pengeluarannya. Jadi untuk model permusuhan kami dan usulan staking mekanismenya, $B dapat dipandang sebagai ukuran potensi keuntungan yang dapat diperoleh musuh untuk mengekstrak dari mengandalkan smart contracts dengan merusak jaringan oracle dan menyebabkannya untuk menghasilkan laporan atau kumpulan laporan yang salah. Dalam memutuskan apakah jaringan oracle menawarkan tingkat keamanan kriptoekonomi yang memadai untuk tujuan mereka, pengguna harus melakukannya menilai jaringan dari perspektif ini. Untuk musuh yang masuk akal dalam situasi praktis, kami memperkirakan $B secara umum akan terjadi jauh lebih kecil dari total aset pada smart contracts yang diandalkan. Dalam kebanyakan kasus, itu tidak mungkin bagi musuh untuk mengekstraksi aset-aset ini secara keseluruhan. 9.4 Mekanisme Staking: Sketsa Berikut kami sajikan gagasan pokok dan struktur umum dari mekanisme staking kami sedang mempertimbangkan. Untuk kemudahan penyajian, kami uraikan secara sederhana namun lambat (multi-putaran) protokol dalam sub-bagian ini. Namun kami mencatat bahwa skema ini cukup baik praktis. Mengingat jaminan ekonomi yang diberikan oleh mekanisme tersebut, misalnya hukuman dan insentif terhadap node yang salah, banyak pengguna mungkin bersedia untuk melakukan hal tersebut. menerima laporan dengan optimis. Dengan kata lain, pengguna tersebut dapat menerima laporan sebelumnya keputusan potensial oleh tingkat kedua. Pengguna yang tidak mau menerima laporan dengan optimis dapat memilih untuk menunggu hingga protokol selesai eksekusi dihentikan, yaitu hingga terjadi potensi eskalasi ke tingkat kedua. Ini, namun, dapat memperlambat waktu konfirmasi laporan secara signifikan. Oleh karena itu kami secara singkatGambar 15: Skema skema staking dengan peringatan. Dalam contoh ini, 1⃝mayoritas node rusak / disuap dan mengeluarkan nilai ˜r yang salah, bukan nilai yang benar nilai laporan r. Node pengawas 2⃝ mengirimkan peringatan ke komite tingkat kedua, yang 3⃝menentukan dan mengeluarkan nilai laporan yang benar r, mengakibatkan node rusak kehilangan deposit mereka—masing-masing $d ke node pengawas 4⃝. menguraikan beberapa optimasi yang menghasilkan lebih cepat (satu putaran) jika lebih desain kompleks di Bagian 9.5. Ingatlah bahwa tingkat pertama dalam mekanisme staking kita terdiri dari oracle dasar jaringan itu sendiri. Struktur utama mekanisme kami, seperti dijelaskan di atas, adalah di setiap putaran, setiap node dapat bertindak sebagai “anjing penjaga” dengan prioritas tertentu, dan dengan demikian node tersebut mempunyai kemampuan untuk melakukan hal tersebut meningkatkan peringatan jika mekanisme menghasilkan keluaran yang salah, bukan keluaran yang benar satu sungai. Peringatan ini menyebabkan resolusi tingkat kedua, yang kami anggap benar laporan. Node dengan laporan yang salah akan dihukum, dalam artian taruhannya juga demikian dipotong dan diberikan kepada pengawas. Struktur dasar ini umum di sistem oracle, seperti pada, misalnya, [119, 185]. Inovasi utama dalam desain kami, yang disebutkan secara singkat di atas, adalah setiap node diberi prioritas tersendiri dalam mengurutkan calon pengawas. Artinya, anjing penjaga diberi kesempatan untuk waspada dalam urutan prioritas. Ingatlah bahwa jika sebuah node memiliki prioritas tertinggi untuk meningkatkan peringatan, ia menerima pemotongan deposit $d untuk setiap perilaku buruk node, dengan total lebih dari \(dn/2 = \)d × n/2, karena laporan yang salah menyiratkan a mayoritas node buruk. Oleh karena itu, musuh harus membayar setidaknya imbalan ini menyuap node sewenang-wenang. Jadi, untuk menyuap mayoritas node, musuh harus membayar a suap yang besar kepada sebagian besar node, yaitu lebih dari $dn2/2. Kami menunjukkan secara skematis cara kerja peningkatan kewaspadaan dan pengawasan pada Gambar 15.9.4.1 Rincian Mekanisme Lebih Lanjut Sistem tahan suap yang sekarang kami uraikan secara lebih rinci adalah sebuah sketsa sederhana konstruksi dua tingkat yang ingin kami bangun. Sebagian besar fokus kami adalah mendeskripsikan jaringan tingkat pertama (selanjutnya disebut “jaringan” jika jelas dari konteksnya). beserta mekanisme insentifnya dan tata cara eskalasinya ke tingkat kedua. Pertimbangkan jaringan Chainlink yang terdiri dari n oracle node yang bertanggung jawab untuk secara teratur (misalnya, sekali dalam satu menit) melaporkan nilai boolean (misalnya, apakah pasar kapitalisasi BTC melebihi ETH). Sebagai bagian dari mekanisme staking, node harus memberikan dua deposit: deposit $d yang dapat dipotong jika terjadi perselisihan dengan mayoritas dan deposit pengawas $dw dapat dipotong jika terjadi kesalahan eskalasi. Kami berasumsi bahwa node tidak dapat menyalin kiriman dari node lain, misalnya, melalui skema komitmen-pengungkapan seperti yang dibahas dalam Bagian 5.3. Di setiap putaran, node terlebih dahulu berkomitmen pada laporannya, dan setelah semua node telah berkomitmen (atau batas waktu telah habis), node mengungkapkan laporan mereka. Untuk setiap laporan yang akan dihasilkan, setiap node juga diberikan prioritas pengawas antara 1 dan n yang dipilih secara acak, dengan 1 sebagai prioritas utama. Prioritas ini memungkinkan konsentrasi imbalan di tangan satu anjing penjaga. Setelah semua laporan bersifat publik, fase peringatan terjadi. Selama urutan n putaran (sinkron), simpul dengan prioritas i mempunyai kesempatan untuk waspada pada putaran i. Mari kita pertimbangkan kemungkinan hasil dari mekanisme tersebut setelah node terungkap laporan mereka. Sekali lagi dengan asumsi laporan biner, misalkan nilai yang benar adalah benar dan yang salah adalah salah. Misalkan juga mekanisme tingkat pertama menghasilkan output nilai mayoritas keluaran oleh node sebagai laporan akhir r. Ada tiga kemungkinan hasil dalam mekanisme ini: • Kesepakatan lengkap: Dalam kasus terbaik, node-node sepenuhnya sepakat: semua node tersedia dan telah memberikan laporan tepat waktu dengan nilai r yang sama (baik benar atau salah). Dalam hal ini, jaringan hanya perlu meneruskan r ke kontrak yang diandalkan dan menghadiahi setiap node dengan pembayaran tetap per putaran $p, yang jauh lebih kecil dari $d. • Kesepakatan sebagian: Ada kemungkinan bahwa beberapa node sedang offline atau terdapat perbedaan pendapat mengenai nilai mana yang benar, namun sebagian besar node melaporkan nilai yang benar dan hanya sebagian kecil yang melaporkan nilai yang benar. minoritas melaporkan palsu. Kasus ini juga sangat mudah. Nilai mayoritas (benar) dihitung, menghasilkan laporan yang benar r. Semua node yang melaporkan r adalah diberi hadiah $p sedangkan oracle yang melaporkan salah mendapatkan depositnya dipotong sedikit, misalnya sebesar $10p. • Peringatan: Jika pengawas yakin bahwa keluaran jaringan salah, itu secara publik memicu peringatan, meningkatkan mekanisme ke jaringan tingkat kedua. Ada dua kemungkinan hasil: – Peringatan yang benar: Jika jaringan lapis kedua mengonfirmasi bahwa output dariGambar 16: Memperbesar kerugian bagi penyuap melalui imbalan peringatan yang terkonsentrasi. Sebuah suap Musuh harus menyuap setiap node dengan lebih dari imbalan yang bisa diperoleh dengan memberikan peringatan (ditampilkan sebagai bilah merah). Jika imbalan peringatan dibagikan, maka imbalan ini mungkin relatif kecil. Imbalan peringatan terkonsentrasi meningkatkan imbalan yang mungkin dimiliki oleh node mana pun dapatkan (bilah merah tinggi). Akibatnya, total pembayaran yang dilakukan musuh untuk suap yang layak (wilayah abu-abu) jauh lebih besar dengan imbalan peringatan yang terkonsentrasi dibandingkan dengan imbalan peringatan bersama. jaringan tingkat pertama salah, node pengawas yang memberi peringatan menerima hadiah terdiri dari semua deposit yang dipotong, dan dengan demikian lebih dari $dn/2. – Peringatan salah: Jika oracle tingkat kedua dan tingkat pertama setuju, eskalasinya adalah dianggap salah dan node peringatan kehilangan deposit $dw-nya. Dalam kasus penerimaan laporan yang optimis, peringatan pengawas tidak menimbulkan setiap perubahan dalam pelaksanaan kontrak yang bergantung. Untuk kontrak yang dirancang untuk menunggu potensi arbitrase oleh komite tingkat kedua, peringatan pengawas tertunda namun jangan membekukan pelaksanaan kontrak. Kontrak juga dapat menunjuk a failover DON untuk periode ajudikasi. 9.4.2 Dampak Taruhan Kuadrat Kemampuan setiap node untuk bertindak sebagai pengawas, dikombinasikan dengan prioritas node yang ketat memastikan imbalan terkonsentrasi, memungkinkan mekanisme mencapai staking kuadrat dampak untuk setiap jenis pelaku penyuapan yang dijelaskan dalam Bagian 9.3.3. Ingatlah bahwa ini berarti secara khusus dalam pengaturan kami bahwa, untuk jaringan dengan n node yang masing-masing memiliki deposit $d, penyuap yang sukses (salah satu jenis di atas) harus memiliki anggaran lebih besar dari $dn2/2. Tepatnya, penyuap harus merusak setidaknya (n+1)/2 node, karena penyuap harus melakukannya merusak sebagian besar n node (untuk n ganjil, dengan asumsi). Oleh karena itu, ada pengawas yang berdiri tegak dapatkan hadiah $d(n + 1)/2. Oleh karena itu, penyuap harus membayar jumlah ini kepada setiap orangsimpul untuk memastikan bahwa tidak ada yang bertindak sebagai anjing penjaga. Kami berupaya untuk menunjukkan secara formal bahwa jika penyuap memiliki anggaran paling banyak $d(n2 + n)/2, maka subgame keseimbangan sempurna permainan antara penyuap dan oracles—dengan kata lain, keseimbangan di titik mana pun selama permainan ini berlangsung—adalah agar si penyuap tidak memberikan suapnya dan untuk itu setiap oracle melaporkan nilai sebenarnya dengan jujur. Kami telah menjelaskan di atas bagaimana mungkin seorang penyuap yang berhasil memerlukan a anggarannya jauh lebih besar daripada jumlah simpanan simpul. Untuk menggambarkan hal ini hasil intuitif, Gambar 16 menunjukkan dampak penghargaan peringatan terkonsentrasi secara grafis. Seperti yang kita lihat di sana, kalau imbalannya bagi pengawas waspada—yakni titipan orang yang disuap node yang melaporkan salah)—dibagi di antara semua peringatan potensial, jumlah totalnya setiap node peringatan yang diharapkan akan berukuran relatif kecil $d. Seorang penyuap, yang mengetahui bahwa pembayaran lebih besar dari $d tidak mungkin dilakukan, dapat menggunakannya suap bersyarat hasil palsu untuk menyuap masing-masing n node dengan sedikit lebih dari $d + ϵ. Secara berlawanan, Gambar 16 menunjukkan bahwa suatu sistem yang mendistribusikan imbalan secara luas di antara node yang memberi sinyal peringatan jauh lebih lemah daripada node yang memusatkan hadiahnya tangan seekor anjing penjaga. Contoh parameter: Pertimbangkan jaringan (tingkat pertama) dengan n = 100 node, masing-masing menyetor \(d = \)20K. Jaringan ini akan memiliki total $2 juta yang disetorkan tetapi akan tetap ada dilindungi dari penyuap dengan anggaran \(100M = \)dn2/2. Meningkatkan jumlah oracles tentu saja lebih efektif daripada menaikkan $d, dan dapat memberikan efek yang dramatis: jaringan dengan n = 300 node dan deposit \(d = \)20K akan dilindungi dari a penyuap dengan anggaran hingga $900 juta. Perhatikan bahwa sistem staking dalam banyak kasus dapat melindungi smart contract yang mewakili nilai lebih dari tingkat perlindungan suap yang ditawarkan. Ini karena musuh menyerang kontrak-kontrak ini tidak dapat memperoleh nilai penuh dalam banyak kasus. Misalnya, a Kontrak bertenaga Chainlink yang mendapatkan nilai $1 miliar mungkin hanya memerlukan jaminan terhadap a penyuap dengan sumber daya sebesar $100 juta karena musuh dapat mengambil keuntungan hanya 10% dari nilai kontrak. Catatan: Gagasan bahwa nilai jaringan dapat tumbuh secara kuadratik diungkapkan dalam Hukum Metcalfe yang terkenal [167, 235], yang menyatakan bahwa nilai jaringan tumbuh secara kuadrat dalam jumlah entitas yang terhubung. Namun, Hukum Metcalfe muncul dari pertumbuhan jumlah koneksi jaringan berpasangan potensial, sebuah fenomena yang berbeda dari dampak kuadratik staking dalam insentif kami mekanisme. 9.4.3 Realisasi Tingkat Kedua Dua fitur operasional memfasilitasi realisasi tingkat kedua dengan keandalan tinggi: (1) Keputusan tingkat kedua seharusnya jarang terjadi di jaringan oracle dan oleh karena itu dapat terjadi menjadi jauh lebih mahal daripada operasi normal tingkat pertama dan (2) Dengan asumsilaporan yang diterima secara optimis—atau kontrak yang pelaksanaannya dapat menunggu arbitrase— tingkat kedua tidak perlu dijalankan secara real time. Fitur-fitur ini menghasilkan beragam opsi konfigurasi untuk tingkat kedua untuk memenuhi persyaratan DON tertentu. Sebagai contoh pendekatan, komite tingkat kedua dapat terdiri dari simpul-simpul yang dipilih oleh a DON (yaitu, tingkat pertama) dari node dengan layanan terlama dan paling andal di Chainlink jaringan. Selain pengalaman operasional yang cukup relevan, operator dari node tersebut memiliki insentif implisit yang cukup besar dalam FFO yang memotivasi keinginan untuk memastikan bahwa jaringan Chainlink tetap dapat diandalkan. Mereka juga melakukannya secara terbuka riwayat kinerja yang tersedia yang memberikan transparansi mengenai keandalannya. Node tingkat kedua, perlu dicatat, tidak perlu menjadi peserta dalam jaringan tingkat pertama, dan dapat memutuskan kesalahan di beberapa jaringan tingkat pertama. Node dalam DON tertentu dapat ditunjuk terlebih dahulu dan berkomitmen secara publik ke himpunan n′ tersebut node sebagai komite tingkat kedua untuk DON itu. Selain itu, DON node menerbitkan parameter k′ ≤n′ yang menentukan jumlah suara tingkat kedua diperlukan untuk menghukum node tingkat pertama. Saat peringatan dibuat untuk laporan tertentu, anggota tingkat kedua memberikan suara pada kebenaran nilai yang diberikan masing-masing dari node tingkat pertama. Setiap node tingkat pertama yang menerima k′ suara negatif akan kehilangan node tersebut deposit ke node pengawas. Karena jarangnya proses peradilan dan adanya kesempatan eksekusi yang memakan waktu lama disebutkan di atas, berbeda dengan tingkat pertama, node di tingkat kedua dapat: 1. Mendapatkan kompensasi yang tinggi untuk melakukan ajudikasi. 2. Memanfaatkan sumber data tambahan, bahkan melebihi beragam sumber data yang digunakan oleh data tingkat pertama. 3. Mengandalkan inspeksi dan intervensi manual dan/atau ahli, misalnya untuk mengidentifikasi dan merekonsiliasi kesalahan dalam data sumber dan membedakan antara penyampaian node yang jujur data yang salah dan node yang berperilaku buruk. Kami menekankan bahwa pendekatan yang baru saja kami jelaskan untuk pemilihan simpul tingkat kedua dan keputusan yang mengatur kebijakan hanya mewakili satu titik dalam rentang yang luas. ruang desain kemungkinan realisasi tingkat kedua. Mekanisme insentif kami menawarkan fleksibilitas penuh mengenai bagaimana tingkat kedua diwujudkan. Dengan demikian, individu DON dapat melakukannya menyusun dan menetapkan aturan untuk tingkat kedua yang memenuhi persyaratan tertentu dan harapan node dan pengguna yang berpartisipasi. DECO dan Town Crier sebagai alat penilaian: Ini penting untuk tingkat kedua dalam mekanisme kami untuk dapat membedakan antara node tingkat pertama yang bermusuhan itu sengaja menghasilkan laporan yang salah dan node tingkat pertama yang jujur secara tidak sengaja menyampaikan data yang salah pada sumbernya. Hanya dengan cara inilah tingkat kedua dapat diimplementasikan pemotongan untuk mendisinsentifkan kecurangan, yang merupakan tujuan dari mekanisme kami. DECO dan Town Crier adalah alat canggih yang memungkinkan node tingkat kedua membuat perbedaan penting ini andal.Node tingkat kedua dalam beberapa kasus mungkin dapat langsung menanyakan sumber data yang digunakan oleh node tingkat pertama atau gunakan ADO Bagian 7.1 untuk memeriksa apakah laporan salah disebabkan oleh sumber data yang salah. Namun dalam kasus lain, node tingkat kedua mungkin kurang akses langsung ke sumber data node tingkat pertama. Dalam kasus seperti ini, keputusan yang tepat akan diperlukan tampaknya tidak layak atau memerlukan ketergantungan pada penilaian subjektif. Sebelumnya oracle sistem perselisihan mengandalkan putaran pemungutan suara yang tidak efisien dan meningkat untuk mengatasi hal tersebut tantangan. Namun, dengan menggunakan DECO atau Town Crier, node tingkat pertama dapat membuktikan perilaku yang benar ke node tingkat kedua. (Lihat Bagian 3.6.2 untuk rincian mengenai kedua sistem tersebut.) Khususnya, jika simpul tingkat kedua mengidentifikasi simpul tingkat pertama yang mempunyai keluaran nilai laporan yang salah ˜r, node tingkat pertama dapat menggunakan DECO atau Town Crier untuk menghasilkan bukti anti kerusakan node tingkat kedua yang di-relay dengan benar dari sumber (yang mendukung TLS). diakui sebagai otoritatif oleh DON. Yang terpenting, node tingkat pertama dapat melakukan hal ini tanpa node tingkat kedua yang memerlukan akses langsung ke sumber data.17 Akibatnya, penilaian yang benar dapat dilakukan di Chainlink untuk sumber data apa pun yang diinginkan. 9.4.4 Asuransi yang Salah Pelaporan Kuatnya penolakan terhadap suap yang dicapai oleh mekanisme staking kami sangat bergantung pada hal ini tentang pemotongan dana yang diberikan kepada pemberi peringatan. Tanpa imbalan uang, pemberi peringatan akan melakukannya tidak mempunyai insentif langsung untuk menolak suap. Namun alhasil, dana yang terpangkas tidak jadi tersedia untuk memberi kompensasi kepada pengguna yang dirugikan oleh laporan yang salah, misalnya pengguna yang kehilangan uang ketika data harga yang salah diteruskan ke smart contract. Diasumsikan bahwa laporan yang salah tidak akan menjadi masalah jika laporan tersebut diterima oleh a kontrak hanya setelah kemungkinan pengambilan keputusan, yaitu tindakan oleh tingkat kedua. Seperti yang dijelaskan Namun, untuk mencapai kinerja terbaik, kontrak dapat diandalkan optimis terhadap mekanisme penegakan pelaporan yang benar, artinya mereka menerima laporan sebelum kemungkinan keputusan tingkat kedua. Memang perilaku optimis seperti itu aman dalam model kami dengan asumsi musuh rasional yang anggarannya tidak melebihi staking dampak mekanisme. Pengguna khawatir tentang kemungkinan terjadinya kegagalan mekanisme akibat, misalnya, musuh yang memiliki sumber daya finansial yang besar, mungkin ingin menerapkan lapisan tambahan keamanan ekonomi dalam bentuk asuransi kesalahan pelaporan. Kami tahu banyak perusahaan asuransi yang berniat menawarkan polis yang didukung kontrak cerdas semacam ini untuk protokol yang diamankan Chainlink dalam waktu dekat, termasuk melalui mekanisme inovatif seperti DAOs, misalnya, [7]. Keberadaan riwayat kinerja untuk Chainlink node dan data lain tentang node seperti jumlah taruhannya memberikan dasar yang sangat kuat untuk penilaian risiko aktuaria, sehingga memungkinkan penetapan harga kebijakan dengan cara yang murah bagi pemegang polis namun berkelanjutan bagi perusahaan asuransi. 17Dengan Town Crier, node tingkat pertama juga dapat menghasilkan pengesahan secara lokal kebenaran laporan yang mereka hasilkan dan memberikan pengesahan ini ke node tingkat kedua di suatu dasar sesuai kebutuhan.Bentuk dasar asuransi misreporting dapat diterapkan dengan cara yang dapat dipercaya dan cara yang efisien menggunakan smart contracts. Sebagai contoh sederhana, asuransi parametrik kontrak SCins dapat memberikan kompensasi kepada pemegang polis secara otomatis jika mekanisme insentif kami sesuai tingkat kedua mengidentifikasi kesalahan dalam laporan yang dihasilkan di tingkat pertama. Pengguna U yang ingin membeli polis asuransi, misalnya pembuat target kontrak SC, dapat mengajukan permintaan ke perusahaan asuransi yang terdesentralisasi untuk sejumlah polis $M pada kontrak. Saat menyetujui U, perusahaan asuransi dapat menetapkan jangka waktu yang berkelanjutan (misalnya, bulanan) premi $P dalam SCins. Meskipun U membayar premi, polisnya tetap aktif. Jika terjadi kegagalan pelaporan pada SC, maka hasilnya adalah emisi pasangan (r1, r2) laporan yang bertentangan untuk SC, di mana r1 ditandatangani oleh tingkat pertama dalam mekanisme kami dan r2, laporan koreksi terkait, ditandatangani oleh tingkat kedua. Jika U melengkapi pasangan yang valid (r1, r2) ke SCins, kontrak secara otomatis membayarnya $M, asalkan pembayaran preminya mutakhir. 9.5 Varian Putaran Tunggal Protokol yang dijelaskan dalam sub-bagian sebelumnya mengharuskan komite tingkat kedua menunggu beberapa putaran untuk menentukan apakah lembaga pengawas telah memberikan peringatan. Ini Persyaratan ini berlaku bahkan dalam kasus yang optimis, yaitu ketika tingkat pertama berfungsi dengan benar. Bagi pengguna yang tidak mau menerima laporan secara optimis, yaitu sebelum potensinya keputusan pengadilan, penundaan yang terkait dengan pendekatan itu tidak akan bisa dijalankan. Oleh karena itu, kami juga menjajaki protokol alternatif yang hanya memerlukan satu protokol bulat. Dalam pendekatan ini, semua node oracle mengirimkan bit rahasia yang menunjukkan apakah atau tidak mereka ingin meningkatkan kewaspadaan. Komite tingkat kedua kemudian memeriksa nilai-nilai ini urutan prioritas. Untuk memberikan gambaran kasar, skema tersebut mungkin melibatkan hal berikut langkah-langkah: 1. Pengiriman bit pengawas: Setiap node rahasia Oi berbagi nilai pengawas satu bit wi ∈{no alert, alert} di antara node di tingkat kedua untuk setiap laporan yang dihasilkannya. 2. Tip anonim: Setiap node oracle dapat mengirimkan tip anonim α ke komite tingkat kedua pada putaran yang sama saat bit pengawas dikirimkan. Tip ini α adalah pesan yang menunjukkan bahwa peringatan telah dimunculkan untuk laporan saat ini. 3. Pemeriksaan bit pengawas: Komite tingkat kedua mengungkapkan oracle pengawas node bit dalam urutan prioritas. Perhatikan bahwa node tidak boleh mengirimkan bit pengawas peringatan ketika mereka tidak memberikan peringatan: jika tidak, analisis lalu lintas akan mengungkapkan semua bit node. Protokol memang mengungkapkan tidak ada peringatan bit pengawas dari node dengan prioritas lebih tinggi daripada pengawas peringatan dengan prioritas tertinggi. Perhatikan bahwa apa yang terungkap identik dengan protokol n-round kita. Imbalan juga didistribusikan secara identik dengan skema tersebut, yaitu pengawas yang pertama kali diidentifikasi menerima potongan simpanan dari node yang telah mengirimkan laporan yang salah.Penggunaan tip anonim memungkinkan komite tingkat kedua untuk tetap non-interaktif jika tidak ada peringatan yang disampaikan, sehingga mengurangi kompleksitas komunikasi dalam kasus umum. Perhatikan bahwa pengawas mana pun yang memberikan peringatan mempunyai insentif ekonomi untuk mengirimkan tip anonim: Jika tidak ada tip yang dikirimkan, tidak ada imbalan yang dibayarkan kepada siapa pun. simpul. Untuk memastikan bahwa pengirim Oi dari tip anonim α tidak dapat diidentifikasi oleh musuh berdasarkan data jaringan, tip anonim dapat dikirim melalui anonim saluran, misalnya melalui Tor, atau, lebih praktisnya, diproksi melalui penyedia layanan cloud. Untuk mengautentikasi ujungnya sebagai berasal dari O, Oi dapat menandatangani α menggunakan tanda tangan cincin [39, 192]. Alternatifnya, untuk mencegah serangan penolakan layanan yang tidak dapat diatribusikan terhadap komite tingkat kedua oleh node oracle yang berbahaya, α dapat berupa kredensial anonim dengan anonimitas yang dapat dibatalkan [73]. Protokol ini, meskipun secara praktis dapat dicapai, memiliki rekayasa kelas berat persyaratan (yang sedang kami cari cara untuk menguranginya). Node tingkat pertama, misalnya, harus berkomunikasi langsung dengan node tingkat kedua, yang memerlukan pemeliharaan direktori. Kebutuhan akan saluran anonim dan tanda tangan dering menambah rekayasa kompleksitas skema. Terakhir, ada persyaratan kepercayaan khusus yang dibahas secara singkat dalam catatan di bawah ini. Oleh karena itu, kami juga menjajaki skema yang lebih sederhana yang masih bisa dicapai dampak super-linier staking, namun mungkin kurang dari dampak kuadrat, di mana penyuap membutuhkan sumber daya minimal $n log n, misalnya. Beberapa skema di bawah ini pertimbangan melibatkan pemilihan acak dari subset node yang ketat untuk bertindak sebagai anjing penjaga, dalam hal ini calon suap menjadi serangan yang sangat kuat. Catatan: Keamanan mekanisme staking putaran tunggal ini tidak dapat dimanfaatkan saluran antara oracle dan node tingkat kedua—sebuah persyaratan standar dalam sistem yang tahan terhadap paksaan, misalnya, pemungutan suara [82, 138], dan merupakan persyaratan yang masuk akal dalam praktiknya. Namun, selain itu, simpul Oi yang berupaya bekerja sama dengan penyuap dapat dibangun bagian rahasianya sedemikian rupa untuk menunjukkan kepada penyuap bahwa ia telah mengkodekan suatu hal tertentu nilai. Misalnya, jika Oi tidak mengetahui node mana yang dikontrol oleh penyuap, maka Oi bisa menyerahkan saham bernilai 0 kepada seluruh anggota komite. Penyuap kemudian dapat memverifikasi milik Oi kepatuhan secara probabilistik. Untuk menghindari masalah ini dalam protokol putaran tunggal mana pun, kami mengharuskan Oi mengetahui identitas setidaknya satu node tingkat kedua yang jujur. Dengan protokol interaktif di mana setiap node tingkat kedua menambahkan pengacakan faktor untuk berbagi, hal terbaik yang dapat dilakukan penyuap adalah memaksakan seleksi oleh Oi secara acak sedikit pengawas. 9.6 Kerangka Insentif Implisit (IIF) FFO adalah bentuk insentif implisit untuk perilaku yang benar di jaringan Chainlink. Itu berfungsi seperti kepemilikan eksplisit, yaitu simpanan, yang membantu menegakkan keamanan ekonomi jaringan. Dengan kata lain, FFO harus dimasukkan sebagai bagian dari deposit (efektif). $d dari sebuah node di jaringan.Pertanyaannya adalah: Bagaimana kita mengukur FFO dan bentuk insentif implisit lainnya dalam jaringan Chainlink? Kerangka Insentif Implisit (IIF) adalah seperangkat prinsip dan teknik yang kami rencanakan untuk dikembangkan untuk tujuan ini. Sistem blockchain memberikan berbagai bentuk transparansi yang belum pernah terjadi sebelumnya, dan catatan node Kinerja yang mereka hasilkan merupakan batu loncatan bagi visi kami mengenai bagaimana IIF akan bekerja. Di sini kami secara singkat menguraikan ide-ide tentang elemen-elemen kunci IIF. IIF sendiri akan terdiri dari serangkaian faktor yang kami anggap penting dalam evaluasi insentif implisit, serta mekanisme untuk mempublikasikan data yang relevan dalam bentuk jaminan tinggi untuk dikonsumsi oleh algoritma analitik. Chainlink pengguna yang berbeda mungkin ingin menggunakan IIF dengan cara yang berbeda, misalnya memberikan bobot yang berbeda pada faktor yang berbeda. Kami berharap layanan analitik muncul di komunitas yang membantu pengguna menerapkan IIF sesuai dengan preferensi evaluasi risiko masing-masing, dan tujuan kami adalah untuk memfasilitasi layanan tersebut dengan memastikan akses mereka terhadap data pendukung yang terjamin dan tepat waktu, seperti yang kita bahas di bawah (Bagian 9.6.4). 9.6.1 Peluang Biaya di Masa Depan Node berpartisipasi dalam ekosistem Chainlink untuk mendapatkan bagian dari biaya yang dibayarkan jaringan untuk berbagai layanan yang telah kami jelaskan dalam makalah ini, mulai dari umpan data biasa ke layanan tingkat lanjut seperti identitas terdesentralisasi, pengurutan yang adil, dan menjaga kerahasiaan DeFi. Biaya dalam biaya operator node dukungan jaringan Chainlink, misalnya, menjalankan server, memperoleh lisensi data yang diperlukan, dan memelihara staf global untuk memastikan waktu kerja yang tinggi. FFO menunjukkan biaya layanan, setelah dikurangi biaya, yang akan diperoleh node di masa depan—atau rugi jika node tersebut menunjukkan perilaku yang salah. FFO adalah bentuk taruhan yang membantu mengamankan jaringan. Fitur yang berguna dari FFO adalah kenyataan bahwa data on-chain (dilengkapi dengan data off-chain data) membuat catatan sejarah node dengan tingkat kepercayaan tinggi, sehingga memungkinkan penghitungan FFO secara transparan dan didorong oleh empiris. Pengukuran FFO tingkat pertama yang sederhana dapat diperoleh dari pendapatan bersih rata-rata a node selama periode waktu tertentu (yaitu, pendapatan kotor dikurangi biaya operasional). FFO mungkin kemudian dihitung sebagai, misalnya, nilai sekarang bersih [114] dari pendapatan bersih kumulatif di masa depan, dengan kata lain, nilai diskon waktu dari semua pendapatan di masa depan. Namun, pendapatan node bisa berubah-ubah, seperti yang ditunjukkan misalnya pada Gambar 17. Yang lebih penting lagi, pendapatan node mungkin tidak mengikuti distribusi yang stasioner seiring berjalannya waktu. Oleh karena itu, faktor-faktor lain yang kami rencanakan untuk dieksplorasi dalam memperkirakan FFO meliputi: • Riwayat kinerja: Riwayat kinerja operator—termasuk kebenaran dan ketepatan waktu laporannya, serta waktu operasionalnya—memberikan suatu tujuan batu ujian bagi pengguna untuk mengevaluasi keandalannya. Riwayat kinerja akan demikian memberikan faktor penting dalam pemilihan oracle node oleh pengguna (atau, dengan munculnya dari DONs, pilihan mereka DONs). Riwayat kinerja yang kuat kemungkinan besar akan terjadi berkorelasi dengan pendapatan berkelanjutan yang tinggi.18 18Pertanyaan penelitian penting yang ingin kami jawab adalah deteksi volume layanan yang dipalsukan.Gambar 17: Pendapatan yang diperoleh Chainlink node pada satu data feed (ETH-USD) selama minggu perwakilan pada bulan Maret 2021. • Akses data: Meskipun oracle dapat memperoleh berbagai bentuk data dari API terbuka, bentuk data tertentu atau sumber tertentu yang berkualitas tinggi mungkin hanya tersedia di a berdasarkan langganan atau melalui perjanjian kontrak. Akses istimewa ke tertentu sumber data dapat berperan dalam menciptakan aliran pendapatan yang stabil. • Partisipasi DON: Dengan munculnya DONs, komunitas node akan datang bersama-sama untuk memberikan layanan tertentu. Kami berharap banyak DON yang akan disertakan operator secara selektif, menetapkan partisipasi dalam DONs yang memiliki reputasi baik sebagai a posisi pasar istimewa yang membantu memastikan sumber pendapatan yang konsisten. • Aktivitas lintas platform: Beberapa operator node mungkin memiliki rekam jejak kehadiran dan kinerja yang baik dalam konteks lain, misalnya, sebagai PoS validators atau penyedia data dalam konteks non-blockchain. Kinerja mereka dalam sistem lain ini (ketika data tersedia dalam bentuk yang dapat dipercaya) dapat menjadi masukan dalam evaluasi sejarah kinerja mereka. Demikian pula, perilaku salah di jaringan Chainlink dapat membahayakan pendapatan di sistem lain ini dengan mengusir pengguna, misalnya FFO dapat meluas ke seluruh platform. 9.6.2 FFO spekulatif Operator node berpartisipasi dalam jaringan Chainlink bukan hanya untuk menghasilkan pendapatan operasi, tetapi untuk menciptakan dan memposisikan diri untuk memanfaatkan peluang baru dalam menjalankan pekerjaan. Dengan kata lain, pengeluaran sebesar oracle node dalam jaringan juga pernyataan positif tentang masa depan DeFi dan aplikasi kontrak pintar lainnya domain serta aplikasi non-blockchain yang muncul dari jaringan oracle. Operator node saat ini mendapatkan biaya yang tersedia di jaringan Chainlink yang ada dan secara bersamaan Hal ini mirip dengan ulasan palsu di situs internet, hanya saja masalahnya lebih mudah di dalamnya oracle pengaturan karena kami memiliki catatan pasti apakah barang, yaitu laporan, dipesan dan dikirimkan—berbeda dengan, misalnya, barang fisik yang dipesan di toko online. Dengan kata lain, di oracle pengaturan, kinerja dapat divalidasi, meskipun kebenaran pelanggan tidak bisa.membangun reputasi, riwayat kinerja, dan keahlian operasional yang akan diposisikan mereka secara menguntungkan untuk mendapatkan biaya yang tersedia di jaringan masa depan (tentu saja bergantung pada pada perilaku jujur). Node yang beroperasi di ekosistem Chainlink saat ini akan melakukan hal ini sense memiliki keuntungan dibandingkan pendatang baru dalam mendapatkan bayaran sebagai tambahan Chainlink layanan menjadi tersedia. Keuntungan ini berlaku untuk operator baru, serta perusahaan teknologi dengan reputasi yang sudah mapan; misalnya, T-Systems, yang tradisional penyedia teknologi (anak perusahaan Deutsche Telekom), dan Kraken, yang terpusat besar pertukaran, telah hadir sejak awal di ekosistem Chainlink [28, 143]. Partisipasi oracle node dalam peluang masa depan dapat dianggap sebagai hal yang tersendiri sebagai semacam FFO spekulatif, dan dengan demikian merupakan suatu bentuk kepemilikan di Chainlink jaringan. 9.6.3 Reputasi Eksternal IIF seperti yang telah kami jelaskan dapat beroperasi dalam jaringan dengan nama samaran operator, yaitu tanpa pengungkapan orang atau entitas dunia nyata yang terlibat. Namun, salah satu faktor yang berpotensi penting dalam pemilihan penyedia layanan adalah faktor eksternal reputasi. Yang kami maksud dengan reputasi eksternal adalah persepsi mengenai kepercayaan yang melekat pada identitas dunia nyata, bukan nama samaran. Risiko reputasi yang melekat pada identitas dunia nyata dapat dipandang sebagai bentuk insentif implisit. Kami memandang reputasi melalui kacamata IIF, yaitu dalam pengertian ekonomi kripto, sebagai sarana untuk membangun aktivitas lintas platform yang dapat dimasukkan ke dalam estimasi FFO. Sebaliknya, manfaat menggunakan reputasi eksternal sebagai faktor dalam memperkirakan FFO dengan hubungan pseudonim, adalah bahwa reputasi eksternal menghubungkan kinerja tidak hanya dengan suatu aktivitas operator saat ini, namun juga aktivitas di masa depan. Kalau misalnya reputasinya buruk jika melekat pada seseorang, hal ini dapat mencemari usaha orang tersebut di masa depan. Dengan kata lain, reputasi eksternal dapat mencakup FFO yang lebih luas dibandingkan nama samaran catatan kinerja, sebagai dampak penyimpangan yang melekat pada diri seseorang atau ditetapkan perusahaan lebih sulit untuk melarikan diri daripada yang terkait dengan operasi nama samaran. Chainlink kompatibel dengan teknologi identitas terdesentralisasi (Bagian 4.3) itu dapat memberikan dukungan untuk penggunaan reputasi eksternal di IIF. Teknologi seperti itu dapat memvalidasi dan dengan demikian membantu memastikan kebenaran pernyataan operator di dunia nyata identitas.19 9.6.4 Buka IIF Analytics IIF, seperti yang telah kami catat, bertujuan untuk menyediakan data dan alat sumber terbuka yang andal analisis insentif implisit. Tujuannya adalah untuk mengaktifkan penyedia dalam komunitas untuk mengembangkan analisis yang disesuaikan dengan kebutuhan penilaian risiko di berbagai bagian dunia Chainlink basis pengguna. 19Kredensial identitas yang terdesentralisasi juga dapat, jika diinginkan, menghiasi nama samaran dengan nama yang divalidasi informasi tambahan. Misalnya, operator node pada prinsipnya dapat menggunakan kredensial tersebut untuk membuktikan bahwa itu adalah perusahaan Fortune 500, tanpa mengungkapkan yang mana.Sejumlah besar data historis mengenai pendapatan dan kinerja node berada pada rantai dalam bentuk kepercayaan tinggi dan tidak dapat diubah. Namun, tujuan kami adalah menyediakan data selengkap mungkin, termasuk data tentang perilaku yang hanya terlihat di luar rantai, seperti Off-Chain Reporting (OCR) atau aktivitas DON. Data tersebut berpotensi menjadi banyak. Cara terbaik untuk menyimpannya dan memastikan integritasnya, yaitu melindunginya dari kami yakin, gangguan akan dilakukan dengan bantuan DONs, menggunakan teknik yang telah dibahas di Bagian 3.3. Beberapa insentif dapat digunakan dalam bentuk pengukuran langsung, seperti staking deposito dan FFO dasar. Lainnya, seperti FFO spekulatif dan reputasi, lebih sulit dilakukan mengukur secara obyektif, namun kami yakin bahwa bentuk data pendukung, termasuk pertumbuhan historis ekosistem Chainlink, metrik reputasi media sosial, dll., dapat mendukung model analitik IIF bahkan untuk elemen-elemen yang sulit diukur. Kita dapat membayangkan bahwa DON khusus muncul secara khusus untuk memantau, memvalidasi, dan mencatat data yang berkaitan dengan catatan kinerja off-chain node, serta data lainnya digunakan di IIF, seperti informasi identitas yang divalidasi. DON ini dapat memberikan data IIF yang seragam dan memiliki tingkat kepercayaan tinggi untuk setiap penyedia analisis yang melayani komunitas Chainlink. Mereka juga akan memberikan catatan emas yang sesuai dengan klaim penyedia analitik dapat diverifikasi secara independen oleh masyarakat. 9.7 Menyatukan Semuanya: Insentif Operator Node Mensintesis diskusi kami di atas mengenai insentif eksplisit dan implisit untuk operator node memberikan pandangan holistik tentang cara operator node berpartisipasi dan mendapatkan manfaatnya jaringan Chainlink. Sebagai panduan konseptual, kita dapat menyatakan total aset yang dipertaruhkan dengan Chainlink tertentu operator simpul $S dalam bentuk kasar dan bergaya seperti: \(S ≈\)D + \(F + \)FS + $R, dimana: • $D adalah agregat dari seluruh saham yang disimpan secara eksplisit di semua jaringan di mana operator berpartisipasi; • $F adalah nilai sekarang bersih dari agregat seluruh FFO di seluruh jaringan di dimana operator berpartisipasi; • $FS adalah nilai sekarang bersih dari FFO spekulatif operator; dan • $R adalah ekuitas reputasi operator di luar ekosistem Chainlink yang mungkin terancam oleh perilaku buruk yang teridentifikasi di node oracle-nya. Meskipun sebagian besar bersifat konseptual, persamaan kasar ini menunjukkan bahwa terdapat beragam faktor ekonomi yang mendukung kinerja keandalan tinggi pada Chainlink node. Semua faktor ini selain $D terdapat di jaringan Chainlink saat ini.9.8 Siklus Kebajikan Keamanan Ekonomi Kombinasi dampak staking super-linear dengan representasi pembayaran biaya karena peluang biaya masa depan (FFO) di IIF dapat mengarah pada apa yang kita sebut sebagai siklus baik (virtuous cycle). keamanan ekonomi dalam jaringan oracle. Hal ini dapat dilihat sebagai suatu bentuk perekonomian skala. Ketika jumlah total yang dijamin oleh jaringan tertentu meningkat, jumlahnya tambahan saham yang diperlukan untuk menambah jumlah keamanan ekonomi yang tetap akan menurun biaya rata-rata per pengguna. Oleh karena itu, dalam hal biaya, lebih murah bagi pengguna untuk bergabung jaringan yang sudah ada daripada mencapai peningkatan ekonomi jaringan yang sama keamanan dengan membuat jaringan baru. Yang penting, penambahan setiap pengguna baru semakin rendah biaya layanan untuk semua pengguna jaringan tersebut sebelumnya. Mengingat struktur biaya tertentu (misalnya tingkat hasil tertentu pada jumlah yang dipertaruhkan), jika total biaya yang diperoleh suatu jaringan meningkat, hal ini akan memberikan insentif terhadap aliran biaya tambahan mempertaruhkannya ke dalam jaringan untuk mengamankannya pada tingkat yang lebih tinggi. Khususnya jika total taruhan node individu mungkin ditahan dalam sistem dibatasi, kemudian ketika pembayaran biaya baru memasuki sistem, menaikkan FFO-nya, jumlah node n akan bertambah. Terima kasih kepada dampak staking super-linear dari desain sistem insentif kami, keamanan ekonomi sistem akan naik lebih cepat dari n, misalnya, seperti n2 dalam mekanisme yang kita buat sketsa di Bagian 9.4. Akibatnya, biaya rata-rata untuk keamanan ekonomi—yaitu jumlah kontribusi saham satu dolar keamanan ekonomi—akan turun. Oleh karena itu, jaringan dapat membebankan biaya kepada penggunanya biaya yang lebih rendah. Dengan asumsi bahwa permintaan untuk layanan oracle bersifat elastis (lihat, misalnya, [31] untuk gambaran singkatnya penjelasannya), permintaan akan meningkat sehingga menimbulkan biaya tambahan dan FFO. Kami mengilustrasikan hal ini dengan contoh berikut. Contoh 5. Karena keamanan ekonomi jaringan oracle dengan insentif kami skemanya adalah \(dn2 for stake \)dn, keamanan ekonomi disumbangkan oleh satu dolar saham adalah n dan dengan demikian biaya rata-rata per dolar keamanan ekonomi—yaitu, jumlah kepemilikan berkontribusi terhadap satu dolar keamanan ekonomi—adalah 1/n. Pertimbangkan sebuah jaringan yang insentif ekonominya seluruhnya terdiri dari FFO dan dibatasi pada \(d ≤\)10K per node. Misalkan jaringan mempunyai n = 3 node. Lalu biaya rata-rata per dolar keamanan ekonomi adalah sekitar $0,33. Misalkan total FFO jaringan naik di atas \(30K (e.g., to \)31K). Diberikan batas FFO per node, jaringan tumbuh menjadi (setidaknya) n = 4. Sekarang biaya rata-rata per dolar keamanan ekonomi turun menjadi sekitar $0,25. Kami mengilustrasikan seluruh siklus baik keamanan ekonomi di jaringan oracle secara skematis pada Gambar 18. Kami menekankan bahwa siklus baik keamanan ekonomi berasal dari dampaknya pengguna mengumpulkan biaya mereka. FFO kolektif merekalah yang menguntungkan perusahaan yang lebih besar ukuran jaringan dan dengan demikian keamanan kolektif yang lebih besar. Kami juga mencatat bahwa siklus yang baik keamanan ekonomi mendukung DON mencapai keberlanjutan finansial. Sekali dibuat, DON yang memenuhi kebutuhan pengguna harus berkembang hingga melampaui titik di mana pendapatan dari biaya melebihi biaya operasional untuk oracle node.
Gambar 18: Skema siklus kebajikan Chainlink staking. Kenaikan biaya pengguna pembayaran ke jaringan oracle 1⃝menyebabkannya tumbuh, sehingga menyebabkan pertumbuhan ekonominya keamanan 2⃝. Pertumbuhan super linier ini mewujudkan skala ekonomi di Chainlink jaringan 3⃝. Secara khusus, hal ini berarti pengurangan biaya rata-rata keamanan ekonomi, yaitu, keamanan ekonomi per dolar yang timbul dari pembayaran biaya atau sumber kepemilikan lainnya meningkat. Biaya yang lebih rendah, yang dibebankan kepada pengguna, merangsang peningkatan permintaan untuk oracle layanan 4⃝. 9.9 Faktor Tambahan yang Mendorong Pertumbuhan Jaringan Seiring dengan berkembangnya ekosistem Chainlink, kami yakin akan daya tariknya bagi pengguna dan pentingnya infrastruktur bagi perekonomian blockchain akan meningkat. Nilai yang diberikan oleh jaringan oracle bersifat super-linear, artinya ia berkembang lebih cepatdaripada ukuran jaringan itu sendiri. Pertumbuhan nilai ini berasal dari keduanya skala ekonomi—efisiensi biaya per pengguna yang lebih besar seiring dengan peningkatan volume layanan—dan efek jaringan—peningkatan utilitas jaringan seiring pengguna mengadopsi DON secara lebih luas. Karena smart contract yang ada terus mendapatkan lebih banyak nilai yang terjamin dan sepenuhnya baru smart contract aplikasi dimungkinkan oleh layanan yang lebih terdesentralisasi, secara total penggunaan dan biaya agregat yang dibayarkan ke DONs akan bertambah. Meningkatkan kumpulan biaya masuk menerjemahkannya menjadi sarana dan insentif untuk menciptakan layanan yang lebih terdesentralisasi, menghasilkan siklus yang baik. Siklus yang baik ini memecahkan masalah ayam-dan-telur yang kritis masalah dalam ekosistem hibrida smart contract: Fitur smart contract yang inovatif seringkali memerlukan layanan terdesentralisasi yang belum ada (misalnya, pasar DeFi baru sering kali memerlukan sumber data baru) namun memerlukan permintaan ekonomi yang memadai agar dapat terwujud. Penggabungan biaya berdasarkan berbagai smart contract untuk DON yang ada akan menandakan permintaan akan layanan terdesentralisasi tambahan dari basis pengguna yang terus bertambah, sehingga memunculkan penciptaannya sebesar DONs dan pemberdayaan berkelanjutan terhadap smart contracts hybrid yang baru dan bervariasi. Singkatnya, kami percaya bahwa pertumbuhan keamanan jaringan didorong oleh kebajikan siklus dalam mekanisme Chainlink staking menunjukkan pola pertumbuhan yang lebih besar yang jaringan Chainlink dapat membantu mewujudkan perekonomian on-chain untuk desentralisasi layanan.
Conclusion
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, confidentialityenhanced oracle functionality. Its oracle networks will offer 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 flexible, 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 flexibility 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 off-chain systems, decentralized identity creation from existing data, priority channels to help ensure timely delivery of infrastructure-critical transactions, and confidentiality-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 financial and legal systems. Acknowledgements Thanks to Julian Alterini and Shawn Lee for rendering the figures in this paper.
Kesimpulan
Dalam makalah ini, kami telah menetapkan visi evolusi Chainlink. Tema utama dalam visi ini adalah kemampuan jaringan oracle untuk menyediakan layanan yang lebih luas smart contracts dari sekedar pengiriman data. Menggunakan DONs sebagai fondasi untuk layanan terdesentralisasi di masa depan, Chainlink bertujuan untuk menyediakan fungsionalitas oracle yang berkinerja tinggi dan meningkatkan kerahasiaan. Jaringan oracle-nya akan menawarkan minimalisasi kepercayaan yang kuat melalui kombinasi mekanisme ekonomi kripto yang berprinsip seperti staking dan pagar pengaman yang disusun dengan cermat dan penegakan tingkat layanan pada rantai utama yang mengandalkan. DONs juga akan membantu sistem lapisan-2 menerapkan kebijakan pemesanan transaksi yang fleksibel dan adil, serta mengurangi biaya bahan bakar untuk transaksi yang dialihkan mempool. Secara bersama-sama, Semua kemampuan ini mengarah ke teknologi hybrid cerdas yang aman dan kaya fungsi kontrak. Fleksibilitas DON akan meningkatkan layanan Chainlink yang ada dan meningkatkan banyak fitur dan aplikasi tambahan smart contract. Di antaranya mulus koneksi ke berbagai sistem off-chain, pembuatan identitas terdesentralisasi dari data yang ada, saluran prioritas untuk membantu memastikan pengiriman infrastruktur penting secara tepat waktu transaksi, dan instrumen DeFi yang menjaga kerahasiaan. Visi yang kami kemukakan di sini adalah visi yang ambisius. Dalam jangka pendek, kami berupaya memberdayakan kontrak hibrida untuk mencapai tujuan di luar jangkauan smart contracts saat ini dalam jangka panjang kami bertujuan untuk mewujudkan lapisan meta yang terdesentralisasi. Untunglah kita bisa menggambar pada alat dan ide baru—mulai dari algoritma konsensus hingga bukti tanpa pengetahuan sistem—yang dikembangkan komunitas sebagai hasil penelitian yang berkembang pesat.
Demikian pula, kami berharap untuk memprioritaskan implementasi ide-ide dalam makalah ini sebagai tanggapannya dengan kebutuhan komunitas pengguna Chainlink. Kita nantikan tahap berikutnya dalam upaya kami untuk memberdayakan smart contracts melalui konektivitas universal dan membangun teknologi terdesentralisasi sebagai tulang punggung generasi keuangan dunia berikutnya dan sistem hukum. Ucapan Terima Kasih Terima kasih kepada Julian Alterini dan Shawn Lee yang telah menyajikan angka-angka dalam makalah ini.